Hi All,

I'm starting this email thread as a way to collect things that came up
during the ICSC panel discussions.  I did not take notes during these
sessions so will do my best to remember what was covered, and
hopefully Michael and others can fill in anything that I miss.  Some
of these things may also come from conversations over meals/walks;
some may also be more relevant for the development process or the user
community.

==================================================================
1. CsoundQT

This was probably the biggest point of discussion that came up during
the Developer panel and one that I think has many facets to it.  As it
is now, the problem that is happening at the moment is that CsoundQT
is often crashing for users. From people I spoke to at the conference,
this is not specific to one platform (i.e., users on Linux, OSX, and
Windows have all mentioned this).  This is a major problem that needs
addressing as CsoundQT was added to OSX and Windows installers as the
default GUI program to work with Csound, and many users are now coming
to Csound to give it a try and getting crashes as their first
impression.  (And older users and getting crashes as part of their
teaching and work...).

Some aspects that came up during discussion:

* Most everyone who develops Csound does not do work on CsoundQT
* Some users think CsoundQT is Csound and thus the reputation of
Csound gets tied to CsoundQT
* Having a installer is beneficial to have as a base Csound experience
that can be used for teaching
* Contrarily, some developers and users do not need CsoundQT, and only
need a minimal release with the core Csound libraries and executables
* Packaging CsoundQT with Csound ends up tying together their release
cycles somewhat
* Packaging Csound with CsoundQT allows CsoundQT to make releases on
their own schedules

One thing I mentioned was taking approaches I had seen elsewhere,
which is two releases, one a minimal release, and one a full-package
build.  Another thought I had since the conference is that we could
maybe have three entities:

1. Core Csound - What the current developers here work on and release
2. CsoundQT - Just the application, what the CsoundQT developers work
on and release
3. "Csound Platform" Distribution - an installer that includes core
csound, CsoundQT, and whatever else others want as a basic platform
for teaching/using.

This arrangement is familiar to me personally from the way Haskell and
LaTeX is developed/distributed.  For example:

https://www.haskell.org/downloads
https://www.latex-project.org/get/

In this arrangement, the Platform distribution would generally be a
"stable" release that may behind in versions of Csound and CsoundQT
but be more thoroughly tested and robust.


==================================================================
2. Package Manager

This was something that came up in thinking about how to empower third
parties to share their work easily and require less things to go into
core Csound. The package manager should:

* work with user-defined code (i.e., UDOs)
* work with native code (binaries and/or compile from source)
* resource files (i.e., audio, IRs, etc.)

There are numerous package manager models from software distributions
(e.g., apt, yum, snap) and general programming languages (e.g. npm for
javascript, pip for python, gem for ruby, cocoapods for swift/obj-c).
More closely related for computer music, PD has deken
(https://github.com/pure-data/deken) and SuperCollider has Quarks
(http://doc.sccode.org/Guides/UsingQuarks.html).

For Csound, I had written a test package manager system called CSPM a
few years ago but it never took off.  Ed Costello is currently working
on one, also called cspm (https://github.com/eddyc/cspm).

A package manager would simplify incorporating others' work, such as
Joachim's UDO repository, into our own projects, by just adding a line
or two to say "this project requires this version of this repo to
operate" and have things download automatically.

There are of course many things to work out (e.g., transitive
dependencies and version conflicts).  Also, there are things from
Csound 7 that would make this more powerful/simpler to integrate into
our projects (in particular, namespaces).

=====================================================================

3. Platforms that do not support plugins

Related to #2, we have platforms that do not deal with plugins so well
(i.e., Android, iOS, Web). Michael and I talked a little about having
build options to statically compile in opcode libs into libcsound as
an option, and I remembered that Roger Dannenberg had some interesting
C++ code to make this easy.

Also related is how to simplify packaging UDOs and includes into files
when building for mobile and web.  I am unsure if we have a tool for
this already?  Either way, some examples would be good for this.

======================================================================

4. Encouraging new developer contributions to Csound

We could certainly use more developers contributing to Csound.  This
is not only for Csound core but also for opcodes and other things.

One thought is to revive efforts to document the system (see
https://github.com/csound/csound/tree/develop/doc/csound_system_documentation).
John has already done some new documentation for Opcode contributions
(https://github.com/csound/csound/blob/develop/Submitting_opcodes).  I
think we need to do a better job of having a starting place to point
users to different areas for development contributions, which is an
organization issue (i.e., adding some text to the README.md with links
to the other documentation).

Another is to produce walk through videos for how to compile/develop
Csound with Xcode on OSX and Visual Studio on Windows.

I seem to remember some other aspects to this topic, but can't recall
them at the moment.  I think this is important to identify issues we
need to improve upon and address.

========================================================================

5. Teaching Csound - Course materials and new book possibility?

There was some interesting discussion about perhaps having some kind
of standard or base set of materials for teaching Csound. My thoughts
were that it would make teachers' life simpler if they were
considering to teach Csound to have a semester plan/syllabus
accessible.  The supporting text could be one of the existing texts
(e.g., the newer Csound book (the one published by Springer), the
FLOSS manual) or perhaps a new text.  Counter arguments for a common
material is that it might not cover some things other would want to
cover in their courses.  (This topic was lightly discussed. If
anything, pedagogy might be an interesting topic to developer further
here.)

=========================================================================

6. Website - Maintenance required

The csound.com / csound.github.io website would benefit by having
further maintainers/contributors.  The site is open source and hosted
on github. Users can contribute either by pull request, filing issues,
or emailng a site maintainer.

One of the things that came up was a desire for a better showcase.
Also, we need to replace the now-defunct SoundCloud group play list as
it's broken.

How to Contribute for the website is explained here:

http://csound.github.io/contribute.html

(which is also a page that needs development/contributions!)

I would suggest two things:

a. Let's audit the csound site together here on the user list and file
all issues on the csound.github.io issue tracker
(https://github.com/csound/csound.github.io/issues)

b. Let's coordinate and try to do the site update together (maybe we
can designate a week where people can volunteer to take on one or
more tasks that get added to the issue tracker)


==========================================================================

7. Video Tutorials

This was brought up in the ICSC 2015 in St. Petersburg and lightly
again at this year's conference.  Dr. B made an important point I
think in the 2015 conference that many people today are using YouTube
and other video sites as the way to learn new information.  We could
probably reach out to a lot more people who might be interested in
Csound by producing more videos.

==========================================================================

8. Csound Web

This is one thing that I discussed a little bit with Joachim. I think
it would be good to have a set of examples for using Web Csound (the
WASM build with Emscripten fallback) to make web applications.  The
idea is to have a set of simple examples that demonstrate different
features, similarly to how the csoundAPI_Examples project is setup
(see https://github.com/csound/csoundAPI_Examples/).  I think this is
an area of Csound use that offers users a lot of neat musical
possibilities, but it could be made easier to get into and use if
there are more models to follow.

I don't know if this would be a good thing to have as a separate
project or just a matter of further developing the existing examples.

I think it would also be good to have templates here.  For example, a
use case might be "I want to build a Web instrument with a visual
interface that uses Csound in the background and works with MIDI". If
we have a template available that has a basic instrument already setup
and comments in files to direct users on what to edit to modify audio
and interface code and so on, it might be useful.


=========================================================================

9. Csound 7/6.10

Regarding Csound 7, most of the people I spoke to seemed excited by
the possibilities and the scope of what is considered for CS7 and that
we will be moving on to working on it.  On the other hand, the
concerns over CsoundQT and stability in general, especially in regards
to the new Visual Studio build for Windows, makes me think that 6.10
should be given a little more time before release and time spent for
testing/hardening and making 6.10 as stable as possible.  (As a
sidenote, there's one are of code I saw while abroad regarding locks
and the API that I think might be beneficial to update before moving
on to CS7).

We need to figure out the scheduling for 6.10 to incorporate the above
and anything that arises from this email thread.  Also to note for the
general user community: 6.10 has important fixes (particularly for
loscil) that we wanted to get out ASAP. The developer plan was to move
on to focusing on implementing Csound 7 after 6.10 goes out, but to
maintain a 6.x branch for any further 6.x releases for bug fixes.

==========================================================================

10. A Personal Reflection on Conference

I missed seeing a lot of friends make it to the conference, but at the
same time, I learned a great deal at the conference and thought it was
both very well produced and important that we had it in Montevideo
this year.  It was great to connect with composers and artists using
Csound in Uruguay, Argentina, and Brazil, to hear their works and get
their input.  I enjoyed the pieces from Csound users from around the
world, and thought there was a great balance of papers, panels, and
concerts.

I think it was important too that we both celebrated the many good
things about Csound and its community, as well as identified and
reflected critically on issues that could be improved

In my opinion, Csound the technology is in a good place: live
processing and performance, composing pieces, live coding,
interactivity via Arduinos and RPi's, web-based works were all
represented to some degree at the conference and workshops.  The
language changes for CS7 look to address a number of concerns, though
I think further issues will be made apparent once we get further into
development.  I think we have a number of things to figure out to make
it easier for new Csound users and students to learn and use, but it
looks like we're aware of it and now just have to do the work.


Looking forward to hearing others' thoughts on all of this!

Thanks,
steven

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I'd just like to add a few things to what Steven has said.

There was a feeling at the ICSC that Csound needs new developers. And
I think it needs new musicians as well.

NEW USERS

I think we need an online showcase for Csound pieces that will
demonstrate to the world the power and breadth of what Csound can do.
Everything should run in Csound for WebAssembly with all source code
available. This should be a blog to which anyone can post pieces, and
should have a rating system. For examples, look at http://gibber.cc/
and especially https://www.shadertoy.com/, just change "shader" to
"piece" and the shader code to Csound code or HTML5 code.

I have looked at the technology and it looks to me like the quickest
start to getting something nice going is to create a WordPress blog
that includes Csound for WebAssembly with some custom buttons for the
pages (play, stop, fork, etc.). We could add Csound for WebAssembly to
the existing csound.github.io site as I already have done for my
gogins.github.io site, but sites based on GitHub pages or Jekyll are
static sites to which one can contribute only by committing and
pushing files. I think something like a blog would be much better for
non-developers. But customizing WordPress generally means paying for
Web hosting (...it's cheap). This showcase also would of course accept
plain soundfiles or videos. There would be a default
Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)
license but individual pieces could have their own licenses.

I am working on a prototype of this showcase.

NEW CONTRIBUTORS

I think the package manager idea is essential and it will serve both
musicians and developers.

I think the continuous integration builds should be the standard
builds for Linux, Windows and OS X. And it should be possible to run
the standard builds on one's local computer. This should greatly lower
the bar to entry for Csound development.

I second the notion of improving the Csound technical documentation.

CSOUNDQT

I'm fine with bringing CsoundQt into the Csound repository. Bringing
it in would make it easier for Csound developers to debug CsoundQt and
produce a stronger release of CsoundQt. But I'm also fine with keeping
the current repository. In either case, I think we need to spend a few
months making sure CsoundQt is stable for newbies on all desktop
platforms.

I think two installers, not three, is the optimal mix. One with all
bells and whistles, one with only the "core." As far as I'm concerned,
the "core" installer can just be a zip file and one should be able to
run Csound without any configuration from the bin directory once it is
unzipped.

Thanks,
Mike


-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, Oct 10, 2017 at 1:58 PM, Steven Yi  wrote:
> Hi All,
>
> I'm starting this email thread as a way to collect things that came up
> during the ICSC panel discussions.  I did not take notes during these
> sessions so will do my best to remember what was covered, and
> hopefully Michael and others can fill in anything that I miss.  Some
> of these things may also come from conversations over meals/walks;
> some may also be more relevant for the development process or the user
> community.
>
> ==================================================================
> 1. CsoundQT
>
> This was probably the biggest point of discussion that came up during
> the Developer panel and one that I think has many facets to it.  As it
> is now, the problem that is happening at the moment is that CsoundQT
> is often crashing for users. From people I spoke to at the conference,
> this is not specific to one platform (i.e., users on Linux, OSX, and
> Windows have all mentioned this).  This is a major problem that needs
> addressing as CsoundQT was added to OSX and Windows installers as the
> default GUI program to work with Csound, and many users are now coming
> to Csound to give it a try and getting crashes as their first
> impression.  (And older users and getting crashes as part of their
> teaching and work...).
>
> Some aspects that came up during discussion:
>
> * Most everyone who develops Csound does not do work on CsoundQT
> * Some users think CsoundQT is Csound and thus the reputation of
> Csound gets tied to CsoundQT
> * Having a installer is beneficial to have as a base Csound experience
> that can be used for teaching
> * Contrarily, some developers and users do not need CsoundQT, and only
> need a minimal release with the core Csound libraries and executables
> * Packaging CsoundQT with Csound ends up tying together their release
> cycles somewhat
> * Packaging Csound with CsoundQT allows CsoundQT to make releases on
> their own schedules
>
> One thing I mentioned was taking approaches I had seen elsewhere,
> which is two releases, one a minimal release, and one a full-package
> build.  Another thought I had since the conference is that we could
> maybe have three entities:
>
> 1. Core Csound - What the current developers here work on and release
> 2. CsoundQT - Just the application, what the CsoundQT developers work
> on and release
> 3. "Csound Platform" Distribution - an installer that includes core
> csound, CsoundQT, and whatever else others want as a basic platform
> for teaching/using.
>
> This arrangement is familiar to me personally from the way Haskell and
> LaTeX is developed/distributed.  For example:
>
> https://www.haskell.org/downloads
> https://www.latex-project.org/get/
>
> In this arrangement, the Platform distribution would generally be a
> "stable" release that may behind in versions of Csound and CsoundQT
> but be more thoroughly tested and robust.
>
>
> ==================================================================
> 2. Package Manager
>
> This was something that came up in thinking about how to empower third
> parties to share their work easily and require less things to go into
> core Csound. The package manager should:
>
> * work with user-defined code (i.e., UDOs)
> * work with native code (binaries and/or compile from source)
> * resource files (i.e., audio, IRs, etc.)
>
> There are numerous package manager models from software distributions
> (e.g., apt, yum, snap) and general programming languages (e.g. npm for
> javascript, pip for python, gem for ruby, cocoapods for swift/obj-c).
> More closely related for computer music, PD has deken
> (https://github.com/pure-data/deken) and SuperCollider has Quarks
> (http://doc.sccode.org/Guides/UsingQuarks.html).
>
> For Csound, I had written a test package manager system called CSPM a
> few years ago but it never took off.  Ed Costello is currently working
> on one, also called cspm (https://github.com/eddyc/cspm).
>
> A package manager would simplify incorporating others' work, such as
> Joachim's UDO repository, into our own projects, by just adding a line
> or two to say "this project requires this version of this repo to
> operate" and have things download automatically.
>
> There are of course many things to work out (e.g., transitive
> dependencies and version conflicts).  Also, there are things from
> Csound 7 that would make this more powerful/simpler to integrate into
> our projects (in particular, namespaces).
>
> =====================================================================
>
> 3. Platforms that do not support plugins
>
> Related to #2, we have platforms that do not deal with plugins so well
> (i.e., Android, iOS, Web). Michael and I talked a little about having
> build options to statically compile in opcode libs into libcsound as
> an option, and I remembered that Roger Dannenberg had some interesting
> C++ code to make this easy.
>
> Also related is how to simplify packaging UDOs and includes into files
> when building for mobile and web.  I am unsure if we have a tool for
> this already?  Either way, some examples would be good for this.
>
> ======================================================================
>
> 4. Encouraging new developer contributions to Csound
>
> We could certainly use more developers contributing to Csound.  This
> is not only for Csound core but also for opcodes and other things.
>
> One thought is to revive efforts to document the system (see
> https://github.com/csound/csound/tree/develop/doc/csound_system_documentation).
> John has already done some new documentation for Opcode contributions
> (https://github.com/csound/csound/blob/develop/Submitting_opcodes).  I
> think we need to do a better job of having a starting place to point
> users to different areas for development contributions, which is an
> organization issue (i.e., adding some text to the README.md with links
> to the other documentation).
>
> Another is to produce walk through videos for how to compile/develop
> Csound with Xcode on OSX and Visual Studio on Windows.
>
> I seem to remember some other aspects to this topic, but can't recall
> them at the moment.  I think this is important to identify issues we
> need to improve upon and address.
>
> ========================================================================
>
> 5. Teaching Csound - Course materials and new book possibility?
>
> There was some interesting discussion about perhaps having some kind
> of standard or base set of materials for teaching Csound. My thoughts
> were that it would make teachers' life simpler if they were
> considering to teach Csound to have a semester plan/syllabus
> accessible.  The supporting text could be one of the existing texts
> (e.g., the newer Csound book (the one published by Springer), the
> FLOSS manual) or perhaps a new text.  Counter arguments for a common
> material is that it might not cover some things other would want to
> cover in their courses.  (This topic was lightly discussed. If
> anything, pedagogy might be an interesting topic to developer further
> here.)
>
> =========================================================================
>
> 6. Website - Maintenance required
>
> The csound.com / csound.github.io website would benefit by having
> further maintainers/contributors.  The site is open source and hosted
> on github. Users can contribute either by pull request, filing issues,
> or emailng a site maintainer.
>
> One of the things that came up was a desire for a better showcase.
> Also, we need to replace the now-defunct SoundCloud group play list as
> it's broken.
>
> How to Contribute for the website is explained here:
>
> http://csound.github.io/contribute.html
>
> (which is also a page that needs development/contributions!)
>
> I would suggest two things:
>
> a. Let's audit the csound site together here on the user list and file
> all issues on the csound.github.io issue tracker
> (https://github.com/csound/csound.github.io/issues)
>
> b. Let's coordinate and try to do the site update together (maybe we
> can designate a week where people can volunteer to take on one or
> more tasks that get added to the issue tracker)
>
>
> ==========================================================================
>
> 7. Video Tutorials
>
> This was brought up in the ICSC 2015 in St. Petersburg and lightly
> again at this year's conference.  Dr. B made an important point I
> think in the 2015 conference that many people today are using YouTube
> and other video sites as the way to learn new information.  We could
> probably reach out to a lot more people who might be interested in
> Csound by producing more videos.
>
> ==========================================================================
>
> 8. Csound Web
>
> This is one thing that I discussed a little bit with Joachim. I think
> it would be good to have a set of examples for using Web Csound (the
> WASM build with Emscripten fallback) to make web applications.  The
> idea is to have a set of simple examples that demonstrate different
> features, similarly to how the csoundAPI_Examples project is setup
> (see https://github.com/csound/csoundAPI_Examples/).  I think this is
> an area of Csound use that offers users a lot of neat musical
> possibilities, but it could be made easier to get into and use if
> there are more models to follow.
>
> I don't know if this would be a good thing to have as a separate
> project or just a matter of further developing the existing examples.
>
> I think it would also be good to have templates here.  For example, a
> use case might be "I want to build a Web instrument with a visual
> interface that uses Csound in the background and works with MIDI". If
> we have a template available that has a basic instrument already setup
> and comments in files to direct users on what to edit to modify audio
> and interface code and so on, it might be useful.
>
>
> =========================================================================
>
> 9. Csound 7/6.10
>
> Regarding Csound 7, most of the people I spoke to seemed excited by
> the possibilities and the scope of what is considered for CS7 and that
> we will be moving on to working on it.  On the other hand, the
> concerns over CsoundQT and stability in general, especially in regards
> to the new Visual Studio build for Windows, makes me think that 6.10
> should be given a little more time before release and time spent for
> testing/hardening and making 6.10 as stable as possible.  (As a
> sidenote, there's one are of code I saw while abroad regarding locks
> and the API that I think might be beneficial to update before moving
> on to CS7).
>
> We need to figure out the scheduling for 6.10 to incorporate the above
> and anything that arises from this email thread.  Also to note for the
> general user community: 6.10 has important fixes (particularly for
> loscil) that we wanted to get out ASAP. The developer plan was to move
> on to focusing on implementing Csound 7 after 6.10 goes out, but to
> maintain a 6.x branch for any further 6.x releases for bug fixes.
>
> ==========================================================================
>
> 10. A Personal Reflection on Conference
>
> I missed seeing a lot of friends make it to the conference, but at the
> same time, I learned a great deal at the conference and thought it was
> both very well produced and important that we had it in Montevideo
> this year.  It was great to connect with composers and artists using
> Csound in Uruguay, Argentina, and Brazil, to hear their works and get
> their input.  I enjoyed the pieces from Csound users from around the
> world, and thought there was a great balance of papers, panels, and
> concerts.
>
> I think it was important too that we both celebrated the many good
> things about Csound and its community, as well as identified and
> reflected critically on issues that could be improved
>
> In my opinion, Csound the technology is in a good place: live
> processing and performance, composing pieces, live coding,
> interactivity via Arduinos and RPi's, web-based works were all
> represented to some degree at the conference and workshops.  The
> language changes for CS7 look to address a number of concerns, though
> I think further issues will be made apparent once we get further into
> development.  I think we have a number of things to figure out to make
> it easier for new Csound users and students to learn and use, but it
> looks like we're aware of it and now just have to do the work.
>
>
> Looking forward to hearing others' thoughts on all of this!
>
> Thanks,
> steven
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I have some short examples of csound code I made for my students some time ago. These are short compositions based on a simple idea. Once I make the code clean and understandable, I would be happy to share with the community if this of interest.
Best,
Luis

I'd just like to add a few things to what Steven has said.

There was a feeling at the ICSC that Csound needs new developers. And
I think it needs new musicians as well.

NEW USERS

I think we need an online showcase for Csound pieces that will
demonstrate to the world the power and breadth of what Csound can do.
Everything should run in Csound for WebAssembly with all source code
available. This should be a blog to which anyone can post pieces, and
should have a rating system. For examples, look at http://gibber.cc/
and especially https://www.shadertoy.com/, just change "shader" to
"piece" and the shader code to Csound code or HTML5 code.

I have looked at the technology and it looks to me like the quickest
start to getting something nice going is to create a WordPress blog
that includes Csound for WebAssembly with some custom buttons for the
pages (play, stop, fork, etc.). We could add Csound for WebAssembly to
the existing csound.github.io site as I already have done for my
gogins.github.io site, but sites based on GitHub pages or Jekyll are
static sites to which one can contribute only by committing and
pushing files. I think something like a blog would be much better for
non-developers. But customizing WordPress generally means paying for
Web hosting (...it's cheap). This showcase also would of course accept
plain soundfiles or videos. There would be a default
Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)
license but individual pieces could have their own licenses.

I am working on a prototype of this showcase.

NEW CONTRIBUTORS

I think the package manager idea is essential and it will serve both
musicians and developers.

I think the continuous integration builds should be the standard
builds for Linux, Windows and OS X. And it should be possible to run
the standard builds on one's local computer. This should greatly lower
the bar to entry for Csound development.

I second the notion of improving the Csound technical documentation.

CSOUNDQT

I'm fine with bringing CsoundQt into the Csound repository. Bringing
it in would make it easier for Csound developers to debug CsoundQt and
produce a stronger release of CsoundQt. But I'm also fine with keeping
the current repository. In either case, I think we need to spend a few
months making sure CsoundQt is stable for newbies on all desktop
platforms.

I think two installers, not three, is the optimal mix. One with all
bells and whistles, one with only the "core." As far as I'm concerned,
the "core" installer can just be a zip file and one should be able to
run Csound without any configuration from the bin directory once it is
unzipped.

Thanks,
Mike


-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, Oct 10, 2017 at 1:58 PM, Steven Yi <stevenyi@gmail.com> wrote:

Hi All,

I'm starting this email thread as a way to collect things that came up
during the ICSC panel discussions.  I did not take notes during these
sessions so will do my best to remember what was covered, and
hopefully Michael and others can fill in anything that I miss.  Some
of these things may also come from conversations over meals/walks;
some may also be more relevant for the development process or the user
community.

==================================================================
1. CsoundQT

This was probably the biggest point of discussion that came up during
the Developer panel and one that I think has many facets to it.  As it
is now, the problem that is happening at the moment is that CsoundQT
is often crashing for users. From people I spoke to at the conference,
this is not specific to one platform (i.e., users on Linux, OSX, and
Windows have all mentioned this).  This is a major problem that needs
addressing as CsoundQT was added to OSX and Windows installers as the
default GUI program to work with Csound, and many users are now coming
to Csound to give it a try and getting crashes as their first
impression.  (And older users and getting crashes as part of their
teaching and work...).

Some aspects that came up during discussion:

* Most everyone who develops Csound does not do work on CsoundQT
* Some users think CsoundQT is Csound and thus the reputation of
Csound gets tied to CsoundQT
* Having a installer is beneficial to have as a base Csound experience
that can be used for teaching
* Contrarily, some developers and users do not need CsoundQT, and only
need a minimal release with the core Csound libraries and executables
* Packaging CsoundQT with Csound ends up tying together their release
cycles somewhat
* Packaging Csound with CsoundQT allows CsoundQT to make releases on
their own schedules

One thing I mentioned was taking approaches I had seen elsewhere,
which is two releases, one a minimal release, and one a full-package
build.  Another thought I had since the conference is that we could
maybe have three entities:

1. Core Csound - What the current developers here work on and release
2. CsoundQT - Just the application, what the CsoundQT developers work
on and release
3. "Csound Platform" Distribution - an installer that includes core
csound, CsoundQT, and whatever else others want as a basic platform
for teaching/using.

This arrangement is familiar to me personally from the way Haskell and
LaTeX is developed/distributed.  For example:

https://www.haskell.org/downloads
https://www.latex-project.org/get/

In this arrangement, the Platform distribution would generally be a
"stable" release that may behind in versions of Csound and CsoundQT
but be more thoroughly tested and robust.


==================================================================
2. Package Manager

This was something that came up in thinking about how to empower third
parties to share their work easily and require less things to go into
core Csound. The package manager should:

* work with user-defined code (i.e., UDOs)
* work with native code (binaries and/or compile from source)
* resource files (i.e., audio, IRs, etc.)

There are numerous package manager models from software distributions
(e.g., apt, yum, snap) and general programming languages (e.g. npm for
javascript, pip for python, gem for ruby, cocoapods for swift/obj-c).
More closely related for computer music, PD has deken
(https://github.com/pure-data/deken) and SuperCollider has Quarks
(http://doc.sccode.org/Guides/UsingQuarks.html).

For Csound, I had written a test package manager system called CSPM a
few years ago but it never took off.  Ed Costello is currently working
on one, also called cspm (https://github.com/eddyc/cspm).

A package manager would simplify incorporating others' work, such as
Joachim's UDO repository, into our own projects, by just adding a line
or two to say "this project requires this version of this repo to
operate" and have things download automatically.

There are of course many things to work out (e.g., transitive
dependencies and version conflicts).  Also, there are things from
Csound 7 that would make this more powerful/simpler to integrate into
our projects (in particular, namespaces).

=====================================================================

3. Platforms that do not support plugins

Related to #2, we have platforms that do not deal with plugins so well
(i.e., Android, iOS, Web). Michael and I talked a little about having
build options to statically compile in opcode libs into libcsound as
an option, and I remembered that Roger Dannenberg had some interesting
C++ code to make this easy.

Also related is how to simplify packaging UDOs and includes into files
when building for mobile and web.  I am unsure if we have a tool for
this already?  Either way, some examples would be good for this.

======================================================================

4. Encouraging new developer contributions to Csound

We could certainly use more developers contributing to Csound.  This
is not only for Csound core but also for opcodes and other things.

One thought is to revive efforts to document the system (see
https://github.com/csound/csound/tree/develop/doc/csound_system_documentation).
John has already done some new documentation for Opcode contributions
(https://github.com/csound/csound/blob/develop/Submitting_opcodes).  I
think we need to do a better job of having a starting place to point
users to different areas for development contributions, which is an
organization issue (i.e., adding some text to the README.md with links
to the other documentation).

Another is to produce walk through videos for how to compile/develop
Csound with Xcode on OSX and Visual Studio on Windows.

I seem to remember some other aspects to this topic, but can't recall
them at the moment.  I think this is important to identify issues we
need to improve upon and address.

========================================================================

5. Teaching Csound - Course materials and new book possibility?

There was some interesting discussion about perhaps having some kind
of standard or base set of materials for teaching Csound. My thoughts
were that it would make teachers' life simpler if they were
considering to teach Csound to have a semester plan/syllabus
accessible.  The supporting text could be one of the existing texts
(e.g., the newer Csound book (the one published by Springer), the
FLOSS manual) or perhaps a new text.  Counter arguments for a common
material is that it might not cover some things other would want to
cover in their courses.  (This topic was lightly discussed. If
anything, pedagogy might be an interesting topic to developer further
here.)

=========================================================================

6. Website - Maintenance required

The csound.com / csound.github.io website would benefit by having
further maintainers/contributors.  The site is open source and hosted
on github. Users can contribute either by pull request, filing issues,
or emailng a site maintainer.

One of the things that came up was a desire for a better showcase.
Also, we need to replace the now-defunct SoundCloud group play list as
it's broken.

How to Contribute for the website is explained here:

http://csound.github.io/contribute.html

(which is also a page that needs development/contributions!)

I would suggest two things:

a. Let's audit the csound site together here on the user list and file
all issues on the csound.github.io issue tracker
(https://github.com/csound/csound.github.io/issues)

b. Let's coordinate and try to do the site update together (maybe we
can designate a week where people can volunteer to take on one or
more tasks that get added to the issue tracker)


==========================================================================

7. Video Tutorials

This was brought up in the ICSC 2015 in St. Petersburg and lightly
again at this year's conference.  Dr. B made an important point I
think in the 2015 conference that many people today are using YouTube
and other video sites as the way to learn new information.  We could
probably reach out to a lot more people who might be interested in
Csound by producing more videos.

==========================================================================

8. Csound Web

This is one thing that I discussed a little bit with Joachim. I think
it would be good to have a set of examples for using Web Csound (the
WASM build with Emscripten fallback) to make web applications.  The
idea is to have a set of simple examples that demonstrate different
features, similarly to how the csoundAPI_Examples project is setup
(see https://github.com/csound/csoundAPI_Examples/).  I think this is
an area of Csound use that offers users a lot of neat musical
possibilities, but it could be made easier to get into and use if
there are more models to follow.

I don't know if this would be a good thing to have as a separate
project or just a matter of further developing the existing examples.

I think it would also be good to have templates here.  For example, a
use case might be "I want to build a Web instrument with a visual
interface that uses Csound in the background and works with MIDI". If
we have a template available that has a basic instrument already setup
and comments in files to direct users on what to edit to modify audio
and interface code and so on, it might be useful.


=========================================================================

9. Csound 7/6.10

Regarding Csound 7, most of the people I spoke to seemed excited by
the possibilities and the scope of what is considered for CS7 and that
we will be moving on to working on it.  On the other hand, the
concerns over CsoundQT and stability in general, especially in regards
to the new Visual Studio build for Windows, makes me think that 6.10
should be given a little more time before release and time spent for
testing/hardening and making 6.10 as stable as possible.  (As a
sidenote, there's one are of code I saw while abroad regarding locks
and the API that I think might be beneficial to update before moving
on to CS7).

We need to figure out the scheduling for 6.10 to incorporate the above
and anything that arises from this email thread.  Also to note for the
general user community: 6.10 has important fixes (particularly for
loscil) that we wanted to get out ASAP. The developer plan was to move
on to focusing on implementing Csound 7 after 6.10 goes out, but to
maintain a 6.x branch for any further 6.x releases for bug fixes.

==========================================================================

10. A Personal Reflection on Conference

I missed seeing a lot of friends make it to the conference, but at the
same time, I learned a great deal at the conference and thought it was
both very well produced and important that we had it in Montevideo
this year.  It was great to connect with composers and artists using
Csound in Uruguay, Argentina, and Brazil, to hear their works and get
their input.  I enjoyed the pieces from Csound users from around the
world, and thought there was a great balance of papers, panels, and
concerts.

I think it was important too that we both celebrated the many good
things about Csound and its community, as well as identified and
reflected critically on issues that could be improved

In my opinion, Csound the technology is in a good place: live
processing and performance, composing pieces, live coding,
interactivity via Arduinos and RPi's, web-based works were all
represented to some degree at the conference and workshops.  The
language changes for CS7 look to address a number of concerns, though
I think further issues will be made apparent once we get further into
development.  I think we have a number of things to figure out to make
it easier for new Csound users and students to learn and use, but it
looks like we're aware of it and now just have to do the work.


Looking forward to hearing others' thoughts on all of this!

Thanks,
steven

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi,

Thanks a lot for formulating and forwarding the ideas, Steven!

What concerns a stable, easy to use front-end for entering level, I feel a 
web-based solution on Csound wasm would be best ( a little like CsoundNotebook 
now), integrated with Michael's interactive manual
https://gogins.github.io/csound/html/indexframes.html
- no download, no library conflicts + available from everywhere.

Due to  html support that is already in CsoundQt (develop branch) but in 
testing/stabilizing phase, it could be possible to bind the work done on the 
web (including html elements or entire html page using Csound-wasm) very well 
with offline work and more powerful usage.  I think we will add also templates 
in CsoundQt to start off easily with Csound-wasm pages (or other html 
solutions like Csound-html-Android or Csound-in-Node.js) so there could be a 
strong bridge. But that in next-next version (0.9.6).

If CsoundQt stays inside of the Csound installer or distributed as independent 
package is up to users. I think there is nothing that really replaces CsoundQt 
for whom have based their workflows on it and I definitely try to keep it in 
development.

I will write another email about the stability issues of CsoundQt and 
collective co-operation soon.

Best greetings!
tarmo


On teisipäev, 10. oktoober 2017 20:58.51 EEST you wrote:
> Hi All,
> 
> I'm starting this email thread as a way to collect things that came up
> during the ICSC panel discussions.  I did not take notes during these
> sessions so will do my best to remember what was covered, and
> hopefully Michael and others can fill in anything that I miss.  Some
> of these things may also come from conversations over meals/walks;
> some may also be more relevant for the development process or the user
> community.
> 
> ==================================================================
> 1. CsoundQT
> 
> This was probably the biggest point of discussion that came up during
> the Developer panel and one that I think has many facets to it.  As it
> is now, the problem that is happening at the moment is that CsoundQT
> is often crashing for users. From people I spoke to at the conference,
> this is not specific to one platform (i.e., users on Linux, OSX, and
> Windows have all mentioned this).  This is a major problem that needs
> addressing as CsoundQT was added to OSX and Windows installers as the
> default GUI program to work with Csound, and many users are now coming
> to Csound to give it a try and getting crashes as their first
> impression.  (And older users and getting crashes as part of their
> teaching and work...).
> 
> Some aspects that came up during discussion:
> 
> * Most everyone who develops Csound does not do work on CsoundQT
> * Some users think CsoundQT is Csound and thus the reputation of
> Csound gets tied to CsoundQT
> * Having a installer is beneficial to have as a base Csound experience
> that can be used for teaching
> * Contrarily, some developers and users do not need CsoundQT, and only
> need a minimal release with the core Csound libraries and executables
> * Packaging CsoundQT with Csound ends up tying together their release
> cycles somewhat
> * Packaging Csound with CsoundQT allows CsoundQT to make releases on
> their own schedules
> 
> One thing I mentioned was taking approaches I had seen elsewhere,
> which is two releases, one a minimal release, and one a full-package
> build.  Another thought I had since the conference is that we could
> maybe have three entities:
> 
> 1. Core Csound - What the current developers here work on and release
> 2. CsoundQT - Just the application, what the CsoundQT developers work
> on and release
> 3. "Csound Platform" Distribution - an installer that includes core
> csound, CsoundQT, and whatever else others want as a basic platform
> for teaching/using.
> 
> This arrangement is familiar to me personally from the way Haskell and
> LaTeX is developed/distributed.  For example:
> 
> https://www.haskell.org/downloads
> https://www.latex-project.org/get/
> 
> In this arrangement, the Platform distribution would generally be a
> "stable" release that may behind in versions of Csound and CsoundQT
> but be more thoroughly tested and robust.
> 
> 
> ==================================================================
> 2. Package Manager
> 
> This was something that came up in thinking about how to empower third
> parties to share their work easily and require less things to go into
> core Csound. The package manager should:
> 
> * work with user-defined code (i.e., UDOs)
> * work with native code (binaries and/or compile from source)
> * resource files (i.e., audio, IRs, etc.)
> 
> There are numerous package manager models from software distributions
> (e.g., apt, yum, snap) and general programming languages (e.g. npm for
> javascript, pip for python, gem for ruby, cocoapods for swift/obj-c).
> More closely related for computer music, PD has deken
> (https://github.com/pure-data/deken) and SuperCollider has Quarks
> (http://doc.sccode.org/Guides/UsingQuarks.html).
> 
> For Csound, I had written a test package manager system called CSPM a
> few years ago but it never took off.  Ed Costello is currently working
> on one, also called cspm (https://github.com/eddyc/cspm).
> 
> A package manager would simplify incorporating others' work, such as
> Joachim's UDO repository, into our own projects, by just adding a line
> or two to say "this project requires this version of this repo to
> operate" and have things download automatically.
> 
> There are of course many things to work out (e.g., transitive
> dependencies and version conflicts).  Also, there are things from
> Csound 7 that would make this more powerful/simpler to integrate into
> our projects (in particular, namespaces).
> 
> =====================================================================
> 
> 3. Platforms that do not support plugins
> 
> Related to #2, we have platforms that do not deal with plugins so well
> (i.e., Android, iOS, Web). Michael and I talked a little about having
> build options to statically compile in opcode libs into libcsound as
> an option, and I remembered that Roger Dannenberg had some interesting
> C++ code to make this easy.
> 
> Also related is how to simplify packaging UDOs and includes into files
> when building for mobile and web.  I am unsure if we have a tool for
> this already?  Either way, some examples would be good for this.
> 
> ======================================================================
> 
> 4. Encouraging new developer contributions to Csound
> 
> We could certainly use more developers contributing to Csound.  This
> is not only for Csound core but also for opcodes and other things.
> 
> One thought is to revive efforts to document the system (see
> https://github.com/csound/csound/tree/develop/doc/csound_system_documentatio
> n). John has already done some new documentation for Opcode contributions
> (https://github.com/csound/csound/blob/develop/Submitting_opcodes).  I
> think we need to do a better job of having a starting place to point users
> to different areas for development contributions, which is an organization
> issue (i.e., adding some text to the README.md with links to the other
> documentation).
> 
> Another is to produce walk through videos for how to compile/develop
> Csound with Xcode on OSX and Visual Studio on Windows.
> 
> I seem to remember some other aspects to this topic, but can't recall
> them at the moment.  I think this is important to identify issues we
> need to improve upon and address.
> 
> ========================================================================
> 
> 5. Teaching Csound - Course materials and new book possibility?
> 
> There was some interesting discussion about perhaps having some kind
> of standard or base set of materials for teaching Csound. My thoughts
> were that it would make teachers' life simpler if they were
> considering to teach Csound to have a semester plan/syllabus
> accessible.  The supporting text could be one of the existing texts
> (e.g., the newer Csound book (the one published by Springer), the
> FLOSS manual) or perhaps a new text.  Counter arguments for a common
> material is that it might not cover some things other would want to
> cover in their courses.  (This topic was lightly discussed. If
> anything, pedagogy might be an interesting topic to developer further
> here.)
> 
> =========================================================================
> 
> 6. Website - Maintenance required
> 
> The csound.com / csound.github.io website would benefit by having
> further maintainers/contributors.  The site is open source and hosted
> on github. Users can contribute either by pull request, filing issues,
> or emailng a site maintainer.
> 
> One of the things that came up was a desire for a better showcase.
> Also, we need to replace the now-defunct SoundCloud group play list as
> it's broken.
> 
> How to Contribute for the website is explained here:
> 
> http://csound.github.io/contribute.html
> 
> (which is also a page that needs development/contributions!)
> 
> I would suggest two things:
> 
> a. Let's audit the csound site together here on the user list and file
> all issues on the csound.github.io issue tracker
> (https://github.com/csound/csound.github.io/issues)
> 
> b. Let's coordinate and try to do the site update together (maybe we
> can designate a week where people can volunteer to take on one or
> more tasks that get added to the issue tracker)
> 
> 
> ==========================================================================
> 
> 7. Video Tutorials
> 
> This was brought up in the ICSC 2015 in St. Petersburg and lightly
> again at this year's conference.  Dr. B made an important point I
> think in the 2015 conference that many people today are using YouTube
> and other video sites as the way to learn new information.  We could
> probably reach out to a lot more people who might be interested in
> Csound by producing more videos.
> 
> ==========================================================================
> 
> 8. Csound Web
> 
> This is one thing that I discussed a little bit with Joachim. I think
> it would be good to have a set of examples for using Web Csound (the
> WASM build with Emscripten fallback) to make web applications.  The
> idea is to have a set of simple examples that demonstrate different
> features, similarly to how the csoundAPI_Examples project is setup
> (see https://github.com/csound/csoundAPI_Examples/).  I think this is
> an area of Csound use that offers users a lot of neat musical
> possibilities, but it could be made easier to get into and use if
> there are more models to follow.
> 
> I don't know if this would be a good thing to have as a separate
> project or just a matter of further developing the existing examples.
> 
> I think it would also be good to have templates here.  For example, a
> use case might be "I want to build a Web instrument with a visual
> interface that uses Csound in the background and works with MIDI". If
> we have a template available that has a basic instrument already setup
> and comments in files to direct users on what to edit to modify audio
> and interface code and so on, it might be useful.
> 
> 
> =========================================================================
> 
> 9. Csound 7/6.10
> 
> Regarding Csound 7, most of the people I spoke to seemed excited by
> the possibilities and the scope of what is considered for CS7 and that
> we will be moving on to working on it.  On the other hand, the
> concerns over CsoundQT and stability in general, especially in regards
> to the new Visual Studio build for Windows, makes me think that 6.10
> should be given a little more time before release and time spent for
> testing/hardening and making 6.10 as stable as possible.  (As a
> sidenote, there's one are of code I saw while abroad regarding locks
> and the API that I think might be beneficial to update before moving
> on to CS7).
> 
> We need to figure out the scheduling for 6.10 to incorporate the above
> and anything that arises from this email thread.  Also to note for the
> general user community: 6.10 has important fixes (particularly for
> loscil) that we wanted to get out ASAP. The developer plan was to move
> on to focusing on implementing Csound 7 after 6.10 goes out, but to
> maintain a 6.x branch for any further 6.x releases for bug fixes.
> 
> ==========================================================================
> 
> 10. A Personal Reflection on Conference
> 
> I missed seeing a lot of friends make it to the conference, but at the
> same time, I learned a great deal at the conference and thought it was
> both very well produced and important that we had it in Montevideo
> this year.  It was great to connect with composers and artists using
> Csound in Uruguay, Argentina, and Brazil, to hear their works and get
> their input.  I enjoyed the pieces from Csound users from around the
> world, and thought there was a great balance of papers, panels, and
> concerts.
> 
> I think it was important too that we both celebrated the many good
> things about Csound and its community, as well as identified and
> reflected critically on issues that could be improved
> 
> In my opinion, Csound the technology is in a good place: live
> processing and performance, composing pieces, live coding,
> interactivity via Arduinos and RPi's, web-based works were all
> represented to some degree at the conference and workshops.  The
> language changes for CS7 look to address a number of concerns, though
> I think further issues will be made apparent once we get further into
> development.  I think we have a number of things to figure out to make
> it easier for new Csound users and students to learn and use, but it
> looks like we're aware of it and now just have to do the work.
> 
> 
> Looking forward to hearing others' thoughts on all of this!
> 
> Thanks,
> steven
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Wrt version 6.10 I think we need to release soon as the bug in loscil is serious aznd is causing problems already.

⁣Sent from TypeApp ​

On Oct 11, 2017, 10:39, at 10:39, Rory Walsh  wrote:
>>
>> 2. Package Manager
>>
>> This was something that came up in thinking about how to empower
>third
>> parties to share their work easily and require less things to go into
>> core Csound. The package manager should:
>
>
>This would be great.
>
>4. Encouraging new developer contributions to Csound
>>
>> We could certainly use more developers contributing to Csound.  This
>> is not only for Csound core but also for opcodes and other things.
>>
>> One thought is to revive efforts to document the system (see
>> https://github.com/csound/csound/tree/develop/doc/
>> csound_system_documentation).
>> John has already done some new documentation for Opcode contributions
>> (https://github.com/csound/csound/blob/develop/Submitting_opcodes). 
>I
>> think we need to do a better job of having a starting place to point
>> users to different areas for development contributions, which is an
>> organization issue (i.e., adding some text to the README.md with
>links
>> to the other documentation).
>>
>> Another is to produce walk through videos for how to compile/develop
>> Csound with Xcode on OSX and Visual Studio on Windows.
>>
>> I seem to remember some other aspects to this topic, but can't recall
>> them at the moment.  I think this is important to identify issues we
>> need to improve upon and address.
>>
>
>Once I get Csound building with MSVC I don't mind preparing some simple
>walk through videos on plugin development. However, I wouldn't be
>comfortable discussing Csound internals.
>
>
>>
>========================================================================
>>
>> 5. Teaching Csound - Course materials and new book possibility?
>>
>> There was some interesting discussion about perhaps having some kind
>> of standard or base set of materials for teaching Csound. My thoughts
>> were that it would make teachers' life simpler if they were
>> considering to teach Csound to have a semester plan/syllabus
>> accessible.  The supporting text could be one of the existing texts
>> (e.g., the newer Csound book (the one published by Springer), the
>> FLOSS manual) or perhaps a new text.  Counter arguments for a common
>> material is that it might not cover some things other would want to
>> cover in their courses.  (This topic was lightly discussed. If
>> anything, pedagogy might be an interesting topic to developer further
>> here.)
>>
>
>I think simply presenting as much resources/information as possible
>through
>the website is the way to go here.
>
>
>
>>
>=========================================================================
>>
>> 6. Website - Maintenance required
>>
>> The csound.com / csound.github.io website would benefit by having
>> further maintainers/contributors.  The site is open source and hosted
>> on github. Users can contribute either by pull request, filing
>issues,
>> or emailng a site maintainer.
>>
>> One of the things that came up was a desire for a better showcase.
>> Also, we need to replace the now-defunct SoundCloud group play list
>as
>> it's broken.
>>
>> How to Contribute for the website is explained here:
>>
>> http://csound.github.io/contribute.html
>>
>> (which is also a page that needs development/contributions!)
>>
>> I would suggest two things:
>>
>> a. Let's audit the csound site together here on the user list and
>file
>> all issues on the csound.github.io issue tracker
>> (https://github.com/csound/csound.github.io/issues)
>>
>> b. Let's coordinate and try to do the site update together (maybe we
>> can designate a week where people can volunteer to take on one or
>> more tasks that get added to the issue tracker)
>>
>
>Both of the suggestions above are great. We could try this in the next
>few
>weeks?
>
>
>
>>
>==========================================================================
>>
>> 7. Video Tutorials
>>
>> This was brought up in the ICSC 2015 in St. Petersburg and lightly
>> again at this year's conference.  Dr. B made an important point I
>> think in the 2015 conference that many people today are using YouTube
>> and other video sites as the way to learn new information.  We could
>> probably reach out to a lot more people who might be interested in
>> Csound by producing more videos.
>>
>
>Agreed. Student tend to go for these much faster than they will any
>text
>based tutorials. I have some posted here:|
>https://www.youtube.com/channel/UCWB8axin-qfcWlMt-8LhrHg/playlists
>Although they are geared towards Cabbage, they do cover the basics too.
>I'm
>in the process of updating my work PC. When it's done I should be able
>to
>create a few more. The more the merrier.
>
>
>
>> 9. Csound 7/6.10
>>
>> Regarding Csound 7, most of the people I spoke to seemed excited by
>> the possibilities and the scope of what is considered for CS7 and
>that
>> we will be moving on to working on it.  On the other hand, the
>> concerns over CsoundQT and stability in general, especially in
>regards
>> to the new Visual Studio build for Windows, makes me think that 6.10
>> should be given a little more time before release and time spent for
>> testing/hardening and making 6.10 as stable as possible.  (As a
>> sidenote, there's one are of code I saw while abroad regarding locks
>> and the API that I think might be beneficial to update before moving
>> on to CS7).
>
>
>> We need to figure out the scheduling for 6.10 to incorporate the
>above
>> and anything that arises from this email thread.  Also to note for
>the
>> general user community: 6.10 has important fixes (particularly for
>> loscil) that we wanted to get out ASAP. The developer plan was to
>move
>> on to focusing on implementing Csound 7 after 6.10 goes out, but to
>> maintain a 6.x branch for any further 6.x releases for bug fixes.
>>
>
>This sounds like a good plan. I haven't gotten around to testing the
>new VS
>build. My last attempt to build failed, but much work has been done
>since.
>I will try to get it going soon and report back.
>
>Csound mailing list
>Csound@listserv.heanet.ie
>https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>Send bugs reports to
>        https://github.com/csound/csound/issues
>Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Steven,

First of all, thanks for taking the time to write such a thorough email.
I'm relatively new to Csound and so I feel a little bit uncomfortable
sharing my opinions as a peer with all of you. But, as an Argentinian, I
feel compelled to give an opinion on things I don't understand anyway as
that is our national hobby. 


On 10/10/17 14:58, Steven Yi wrote:
> Hi All,
>
> I'm starting this email thread as a way to collect things that came up
> during the ICSC panel discussions.  I did not take notes during these
> sessions so will do my best to remember what was covered, and
> hopefully Michael and others can fill in anything that I miss.  Some
> of these things may also come from conversations over meals/walks;
> some may also be more relevant for the development process or the user
> community.
>
> ==================================================================
> 1. CsoundQT
>
> One thing I mentioned was taking approaches I had seen elsewhere,
> which is two releases, one a minimal release, and one a full-package
> build.  Another thought I had since the conference is that we could
> maybe have three entities:
>
> 1. Core Csound - What the current developers here work on and release
> 2. CsoundQT - Just the application, what the CsoundQT developers work
> on and release
> 3. "Csound Platform" Distribution - an installer that includes core
> csound, CsoundQT, and whatever else others want as a basic platform
> for teaching/using.
Couldn't the Package Manager (a completely separate piece of software?)
also be the solution to this point? If what you download from the Csound
Github page is the Package Manager you could then decided what
components of the Csound ecosystem you want to install. You could then
say: "I just want Core Csound" or "I'm a newbie, tell me what should I
install in order to get started", or even "I'm interested in writing
plugins with Csound". That in turn would download and install the
appropriate installers from Csound Github, Tarmo's or Rory's.
>
>
> ==================================================================
> 2. Package Manager
>
> This was something that came up in thinking about how to empower third
> parties to share their work easily and require less things to go into
> core Csound. The package manager should:
>
> * work with user-defined code (i.e., UDOs)
> * work with native code (binaries and/or compile from source)
> * resource files (i.e., audio, IRs, etc.)
And then the same Package Manager that made it possible for you to
install whatever Csound combo you wanted could be the thing that lets
you add third-party resources to your work. Other things in that list
could be (in the future): suggested updates, newly added or corrected
examples and/or documentation and/or pedagogical resources (?). I like
how apt-get works in the debian-based distros, but it should be
something with a GUI if the Package Manager is also the Csound installer.
> ========================================================================
>
> 5. Teaching Csound - Course materials and new book possibility?
>
> There was some interesting discussion about perhaps having some kind
> of standard or base set of materials for teaching Csound. My thoughts
> were that it would make teachers' life simpler if they were
> considering to teach Csound to have a semester plan/syllabus
> accessible.  
and
> ==========================================================================
>
> 7. Video Tutorials
>
> This was brought up in the ICSC 2015 in St. Petersburg and lightly
> again at this year's conference.  Dr. B made an important point I
> think in the 2015 conference that many people today are using YouTube
> and other video sites as the way to learn new information.  We could
> probably reach out to a lot more people who might be interested in
> Csound by producing more videos.
>
> ==========================================================================
This year I have been doing some personal research on this topic
(Project Based Learning, optimal ways of teaching a programming
language, teaching with multimedia, etc). We have the Moodle platform
installed on the faculty's server and only an hour and forty minutes per
week for teaching Electroacoustic Music. I was thinking, why not teach
Csound offline through PBL using Videos and weekly Assignments? If I
manage to start rolling the thing the following year I promise to share
any resources we create (overdubbed in English).

The thing is I still don't know exactly what the right approach should
be. First I thought it would be best to give the fundamentals of the
language and after mastery is achieved move on towards showing coding
recipes for audio programming. This kind of reflects how the Springer
book was structured, although I was planning on using a more visual
approach like the diagrams the Code Graphic Viewer produces in CsoundQt.

But then I read that the "going through working examples" paradigm (I
think it was this paper ->
http://cs.au.dk/~mec/publications/conference/26--icer2007.pdf) seems to
produce better results at not leaving students behind. In conclusion, I
don't know yet what pedagogical paradigm we'll use for structuring our
course and I'm open to any thoughts anyone wants to share with me.

Whatever we end up choosing, if someone wants to collaborate with me on
a project like this we could design a general online course in English
for new Csound users around the globe.

Cheers.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

thanks very much for putting all this together, steven.

i just want to say my opinion about the first point.

i meanwhile think that a good and up-to-release README file is most 
important for a minimal csound installer, telling the one who is willing 
to read (and this is what we should request) which frontends are 
available for this version of csound, including a hint to web, mobile, 
and perhaps even api.

and there can be an additional big package, too, if the maintainers 
(victor and michael) are willing to provide it.

we had a different situation when the maintainers decided to include 
csoundqt in the installer.  we were really missing an easy-to-use 
frontend. now we have three frontends which cover so different ways of 
working with csound, and also vim, emacs and many other nice ways to 
edit and compile.  and we see indeed more that unexperienced users 
cannot distinguish between csound and csoundqt, and i think rory is 
right to address this issue.

so, simply put: if we had either a good description which comes with raw 
csound, or (as guillermo mentioned) a package system which gives the 
appropriate options, i'd say: let csoundqt out of the installer.

	joachim


On 10/10/17 19:58, Steven Yi wrote:
> Hi All,
>
> I'm starting this email thread as a way to collect things that came up
> during the ICSC panel discussions.  I did not take notes during these
> sessions so will do my best to remember what was covered, and
> hopefully Michael and others can fill in anything that I miss.  Some
> of these things may also come from conversations over meals/walks;
> some may also be more relevant for the development process or the user
> community.
>
> ==================================================================
> 1. CsoundQT
>
> This was probably the biggest point of discussion that came up during
> the Developer panel and one that I think has many facets to it.  As it
> is now, the problem that is happening at the moment is that CsoundQT
> is often crashing for users. From people I spoke to at the conference,
> this is not specific to one platform (i.e., users on Linux, OSX, and
> Windows have all mentioned this).  This is a major problem that needs
> addressing as CsoundQT was added to OSX and Windows installers as the
> default GUI program to work with Csound, and many users are now coming
> to Csound to give it a try and getting crashes as their first
> impression.  (And older users and getting crashes as part of their
> teaching and work...).
>
> Some aspects that came up during discussion:
>
> * Most everyone who develops Csound does not do work on CsoundQT
> * Some users think CsoundQT is Csound and thus the reputation of
> Csound gets tied to CsoundQT
> * Having a installer is beneficial to have as a base Csound experience
> that can be used for teaching
> * Contrarily, some developers and users do not need CsoundQT, and only
> need a minimal release with the core Csound libraries and executables
> * Packaging CsoundQT with Csound ends up tying together their release
> cycles somewhat
> * Packaging Csound with CsoundQT allows CsoundQT to make releases on
> their own schedules
>
> One thing I mentioned was taking approaches I had seen elsewhere,
> which is two releases, one a minimal release, and one a full-package
> build.  Another thought I had since the conference is that we could
> maybe have three entities:
>
> 1. Core Csound - What the current developers here work on and release
> 2. CsoundQT - Just the application, what the CsoundQT developers work
> on and release
> 3. "Csound Platform" Distribution - an installer that includes core
> csound, CsoundQT, and whatever else others want as a basic platform
> for teaching/using.
>
> This arrangement is familiar to me personally from the way Haskell and
> LaTeX is developed/distributed.  For example:
>
> https://www.haskell.org/downloads
> https://www.latex-project.org/get/
>
> In this arrangement, the Platform distribution would generally be a
> "stable" release that may behind in versions of Csound and CsoundQT
> but be more thoroughly tested and robust.
>
>
> ==================================================================
> 2. Package Manager
>
> This was something that came up in thinking about how to empower third
> parties to share their work easily and require less things to go into
> core Csound. The package manager should:
>
> * work with user-defined code (i.e., UDOs)
> * work with native code (binaries and/or compile from source)
> * resource files (i.e., audio, IRs, etc.)
>
> There are numerous package manager models from software distributions
> (e.g., apt, yum, snap) and general programming languages (e.g. npm for
> javascript, pip for python, gem for ruby, cocoapods for swift/obj-c).
> More closely related for computer music, PD has deken
> (https://github.com/pure-data/deken) and SuperCollider has Quarks
> (http://doc.sccode.org/Guides/UsingQuarks.html).
>
> For Csound, I had written a test package manager system called CSPM a
> few years ago but it never took off.  Ed Costello is currently working
> on one, also called cspm (https://github.com/eddyc/cspm).
>
> A package manager would simplify incorporating others' work, such as
> Joachim's UDO repository, into our own projects, by just adding a line
> or two to say "this project requires this version of this repo to
> operate" and have things download automatically.
>
> There are of course many things to work out (e.g., transitive
> dependencies and version conflicts).  Also, there are things from
> Csound 7 that would make this more powerful/simpler to integrate into
> our projects (in particular, namespaces).
>
> =====================================================================
>
> 3. Platforms that do not support plugins
>
> Related to #2, we have platforms that do not deal with plugins so well
> (i.e., Android, iOS, Web). Michael and I talked a little about having
> build options to statically compile in opcode libs into libcsound as
> an option, and I remembered that Roger Dannenberg had some interesting
> C++ code to make this easy.
>
> Also related is how to simplify packaging UDOs and includes into files
> when building for mobile and web.  I am unsure if we have a tool for
> this already?  Either way, some examples would be good for this.
>
> ======================================================================
>
> 4. Encouraging new developer contributions to Csound
>
> We could certainly use more developers contributing to Csound.  This
> is not only for Csound core but also for opcodes and other things.
>
> One thought is to revive efforts to document the system (see
> https://github.com/csound/csound/tree/develop/doc/csound_system_documentation).
> John has already done some new documentation for Opcode contributions
> (https://github.com/csound/csound/blob/develop/Submitting_opcodes).  I
> think we need to do a better job of having a starting place to point
> users to different areas for development contributions, which is an
> organization issue (i.e., adding some text to the README.md with links
> to the other documentation).
>
> Another is to produce walk through videos for how to compile/develop
> Csound with Xcode on OSX and Visual Studio on Windows.
>
> I seem to remember some other aspects to this topic, but can't recall
> them at the moment.  I think this is important to identify issues we
> need to improve upon and address.
>
> ========================================================================
>
> 5. Teaching Csound - Course materials and new book possibility?
>
> There was some interesting discussion about perhaps having some kind
> of standard or base set of materials for teaching Csound. My thoughts
> were that it would make teachers' life simpler if they were
> considering to teach Csound to have a semester plan/syllabus
> accessible.  The supporting text could be one of the existing texts
> (e.g., the newer Csound book (the one published by Springer), the
> FLOSS manual) or perhaps a new text.  Counter arguments for a common
> material is that it might not cover some things other would want to
> cover in their courses.  (This topic was lightly discussed. If
> anything, pedagogy might be an interesting topic to developer further
> here.)
>
> =========================================================================
>
> 6. Website - Maintenance required
>
> The csound.com / csound.github.io website would benefit by having
> further maintainers/contributors.  The site is open source and hosted
> on github. Users can contribute either by pull request, filing issues,
> or emailng a site maintainer.
>
> One of the things that came up was a desire for a better showcase.
> Also, we need to replace the now-defunct SoundCloud group play list as
> it's broken.
>
> How to Contribute for the website is explained here:
>
> http://csound.github.io/contribute.html
>
> (which is also a page that needs development/contributions!)
>
> I would suggest two things:
>
> a. Let's audit the csound site together here on the user list and file
> all issues on the csound.github.io issue tracker
> (https://github.com/csound/csound.github.io/issues)
>
> b. Let's coordinate and try to do the site update together (maybe we
> can designate a week where people can volunteer to take on one or
> more tasks that get added to the issue tracker)
>
>
> ==========================================================================
>
> 7. Video Tutorials
>
> This was brought up in the ICSC 2015 in St. Petersburg and lightly
> again at this year's conference.  Dr. B made an important point I
> think in the 2015 conference that many people today are using YouTube
> and other video sites as the way to learn new information.  We could
> probably reach out to a lot more people who might be interested in
> Csound by producing more videos.
>
> ==========================================================================
>
> 8. Csound Web
>
> This is one thing that I discussed a little bit with Joachim. I think
> it would be good to have a set of examples for using Web Csound (the
> WASM build with Emscripten fallback) to make web applications.  The
> idea is to have a set of simple examples that demonstrate different
> features, similarly to how the csoundAPI_Examples project is setup
> (see https://github.com/csound/csoundAPI_Examples/).  I think this is
> an area of Csound use that offers users a lot of neat musical
> possibilities, but it could be made easier to get into and use if
> there are more models to follow.
>
> I don't know if this would be a good thing to have as a separate
> project or just a matter of further developing the existing examples.
>
> I think it would also be good to have templates here.  For example, a
> use case might be "I want to build a Web instrument with a visual
> interface that uses Csound in the background and works with MIDI". If
> we have a template available that has a basic instrument already setup
> and comments in files to direct users on what to edit to modify audio
> and interface code and so on, it might be useful.
>
>
> =========================================================================
>
> 9. Csound 7/6.10
>
> Regarding Csound 7, most of the people I spoke to seemed excited by
> the possibilities and the scope of what is considered for CS7 and that
> we will be moving on to working on it.  On the other hand, the
> concerns over CsoundQT and stability in general, especially in regards
> to the new Visual Studio build for Windows, makes me think that 6.10
> should be given a little more time before release and time spent for
> testing/hardening and making 6.10 as stable as possible.  (As a
> sidenote, there's one are of code I saw while abroad regarding locks
> and the API that I think might be beneficial to update before moving
> on to CS7).
>
> We need to figure out the scheduling for 6.10 to incorporate the above
> and anything that arises from this email thread.  Also to note for the
> general user community: 6.10 has important fixes (particularly for
> loscil) that we wanted to get out ASAP. The developer plan was to move
> on to focusing on implementing Csound 7 after 6.10 goes out, but to
> maintain a 6.x branch for any further 6.x releases for bug fixes.
>
> ==========================================================================
>
> 10. A Personal Reflection on Conference
>
> I missed seeing a lot of friends make it to the conference, but at the
> same time, I learned a great deal at the conference and thought it was
> both very well produced and important that we had it in Montevideo
> this year.  It was great to connect with composers and artists using
> Csound in Uruguay, Argentina, and Brazil, to hear their works and get
> their input.  I enjoyed the pieces from Csound users from around the
> world, and thought there was a great balance of papers, panels, and
> concerts.
>
> I think it was important too that we both celebrated the many good
> things about Csound and its community, as well as identified and
> reflected critically on issues that could be improved
>
> In my opinion, Csound the technology is in a good place: live
> processing and performance, composing pieces, live coding,
> interactivity via Arduinos and RPi's, web-based works were all
> represented to some degree at the conference and workshops.  The
> language changes for CS7 look to address a number of concerns, though
> I think further issues will be made apparent once we get further into
> development.  I think we have a number of things to figure out to make
> it easier for new Csound users and students to learn and use, but it
> looks like we're aware of it and now just have to do the work.
>
>
> Looking forward to hearing others' thoughts on all of this!
>
> Thanks,
> steven
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Luis,

I've always enjoyed listening to pieces and studying the Csound code
used to produce them.  So, at least you have one person of interest.
:) (And I suspect others would be interested too!)

steven

On Wed, Oct 11, 2017 at 3:47 AM, luis antunes pena  wrote:
> I have some short examples of csound code I made for my students some time
> ago. These are short compositions based on a simple idea. Once I make the
> code clean and understandable, I would be happy to share with the community
> if this of interest.
> Best,
> Luis
>
> Am 10.10.17 um 22:13 schrieb Michael Gogins:
>
> I'd just like to add a few things to what Steven has said.
>
> There was a feeling at the ICSC that Csound needs new developers. And
> I think it needs new musicians as well.
>
> NEW USERS
>
> I think we need an online showcase for Csound pieces that will
> demonstrate to the world the power and breadth of what Csound can do.
> Everything should run in Csound for WebAssembly with all source code
> available. This should be a blog to which anyone can post pieces, and
> should have a rating system. For examples, look at http://gibber.cc/
> and especially https://www.shadertoy.com/, just change "shader" to
> "piece" and the shader code to Csound code or HTML5 code.
>
> I have looked at the technology and it looks to me like the quickest
> start to getting something nice going is to create a WordPress blog
> that includes Csound for WebAssembly with some custom buttons for the
> pages (play, stop, fork, etc.). We could add Csound for WebAssembly to
> the existing csound.github.io site as I already have done for my
> gogins.github.io site, but sites based on GitHub pages or Jekyll are
> static sites to which one can contribute only by committing and
> pushing files. I think something like a blog would be much better for
> non-developers. But customizing WordPress generally means paying for
> Web hosting (...it's cheap). This showcase also would of course accept
> plain soundfiles or videos. There would be a default
> Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)
> license but individual pieces could have their own licenses.
>
> I am working on a prototype of this showcase.
>
> NEW CONTRIBUTORS
>
> I think the package manager idea is essential and it will serve both
> musicians and developers.
>
> I think the continuous integration builds should be the standard
> builds for Linux, Windows and OS X. And it should be possible to run
> the standard builds on one's local computer. This should greatly lower
> the bar to entry for Csound development.
>
> I second the notion of improving the Csound technical documentation.
>
> CSOUNDQT
>
> I'm fine with bringing CsoundQt into the Csound repository. Bringing
> it in would make it easier for Csound developers to debug CsoundQt and
> produce a stronger release of CsoundQt. But I'm also fine with keeping
> the current repository. In either case, I think we need to spend a few
> months making sure CsoundQt is stable for newbies on all desktop
> platforms.
>
> I think two installers, not three, is the optimal mix. One with all
> bells and whistles, one with only the "core." As far as I'm concerned,
> the "core" installer can just be a zip file and one should be able to
> run Csound without any configuration from the bin directory once it is
> unzipped.
>
> Thanks,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Oct 10, 2017 at 1:58 PM, Steven Yi  wrote:
>
> Hi All,
>
> I'm starting this email thread as a way to collect things that came up
> during the ICSC panel discussions.  I did not take notes during these
> sessions so will do my best to remember what was covered, and
> hopefully Michael and others can fill in anything that I miss.  Some
> of these things may also come from conversations over meals/walks;
> some may also be more relevant for the development process or the user
> community.
>
> ==================================================================
> 1. CsoundQT
>
> This was probably the biggest point of discussion that came up during
> the Developer panel and one that I think has many facets to it.  As it
> is now, the problem that is happening at the moment is that CsoundQT
> is often crashing for users. From people I spoke to at the conference,
> this is not specific to one platform (i.e., users on Linux, OSX, and
> Windows have all mentioned this).  This is a major problem that needs
> addressing as CsoundQT was added to OSX and Windows installers as the
> default GUI program to work with Csound, and many users are now coming
> to Csound to give it a try and getting crashes as their first
> impression.  (And older users and getting crashes as part of their
> teaching and work...).
>
> Some aspects that came up during discussion:
>
> * Most everyone who develops Csound does not do work on CsoundQT
> * Some users think CsoundQT is Csound and thus the reputation of
> Csound gets tied to CsoundQT
> * Having a installer is beneficial to have as a base Csound experience
> that can be used for teaching
> * Contrarily, some developers and users do not need CsoundQT, and only
> need a minimal release with the core Csound libraries and executables
> * Packaging CsoundQT with Csound ends up tying together their release
> cycles somewhat
> * Packaging Csound with CsoundQT allows CsoundQT to make releases on
> their own schedules
>
> One thing I mentioned was taking approaches I had seen elsewhere,
> which is two releases, one a minimal release, and one a full-package
> build.  Another thought I had since the conference is that we could
> maybe have three entities:
>
> 1. Core Csound - What the current developers here work on and release
> 2. CsoundQT - Just the application, what the CsoundQT developers work
> on and release
> 3. "Csound Platform" Distribution - an installer that includes core
> csound, CsoundQT, and whatever else others want as a basic platform
> for teaching/using.
>
> This arrangement is familiar to me personally from the way Haskell and
> LaTeX is developed/distributed.  For example:
>
> https://www.haskell.org/downloads
> https://www.latex-project.org/get/
>
> In this arrangement, the Platform distribution would generally be a
> "stable" release that may behind in versions of Csound and CsoundQT
> but be more thoroughly tested and robust.
>
>
> ==================================================================
> 2. Package Manager
>
> This was something that came up in thinking about how to empower third
> parties to share their work easily and require less things to go into
> core Csound. The package manager should:
>
> * work with user-defined code (i.e., UDOs)
> * work with native code (binaries and/or compile from source)
> * resource files (i.e., audio, IRs, etc.)
>
> There are numerous package manager models from software distributions
> (e.g., apt, yum, snap) and general programming languages (e.g. npm for
> javascript, pip for python, gem for ruby, cocoapods for swift/obj-c).
> More closely related for computer music, PD has deken
> (https://github.com/pure-data/deken) and SuperCollider has Quarks
> (http://doc.sccode.org/Guides/UsingQuarks.html).
>
> For Csound, I had written a test package manager system called CSPM a
> few years ago but it never took off.  Ed Costello is currently working
> on one, also called cspm (https://github.com/eddyc/cspm).
>
> A package manager would simplify incorporating others' work, such as
> Joachim's UDO repository, into our own projects, by just adding a line
> or two to say "this project requires this version of this repo to
> operate" and have things download automatically.
>
> There are of course many things to work out (e.g., transitive
> dependencies and version conflicts).  Also, there are things from
> Csound 7 that would make this more powerful/simpler to integrate into
> our projects (in particular, namespaces).
>
> =====================================================================
>
> 3. Platforms that do not support plugins
>
> Related to #2, we have platforms that do not deal with plugins so well
> (i.e., Android, iOS, Web). Michael and I talked a little about having
> build options to statically compile in opcode libs into libcsound as
> an option, and I remembered that Roger Dannenberg had some interesting
> C++ code to make this easy.
>
> Also related is how to simplify packaging UDOs and includes into files
> when building for mobile and web.  I am unsure if we have a tool for
> this already?  Either way, some examples would be good for this.
>
> ======================================================================
>
> 4. Encouraging new developer contributions to Csound
>
> We could certainly use more developers contributing to Csound.  This
> is not only for Csound core but also for opcodes and other things.
>
> One thought is to revive efforts to document the system (see
> https://github.com/csound/csound/tree/develop/doc/csound_system_documentation).
> John has already done some new documentation for Opcode contributions
> (https://github.com/csound/csound/blob/develop/Submitting_opcodes).  I
> think we need to do a better job of having a starting place to point
> users to different areas for development contributions, which is an
> organization issue (i.e., adding some text to the README.md with links
> to the other documentation).
>
> Another is to produce walk through videos for how to compile/develop
> Csound with Xcode on OSX and Visual Studio on Windows.
>
> I seem to remember some other aspects to this topic, but can't recall
> them at the moment.  I think this is important to identify issues we
> need to improve upon and address.
>
> ========================================================================
>
> 5. Teaching Csound - Course materials and new book possibility?
>
> There was some interesting discussion about perhaps having some kind
> of standard or base set of materials for teaching Csound. My thoughts
> were that it would make teachers' life simpler if they were
> considering to teach Csound to have a semester plan/syllabus
> accessible.  The supporting text could be one of the existing texts
> (e.g., the newer Csound book (the one published by Springer), the
> FLOSS manual) or perhaps a new text.  Counter arguments for a common
> material is that it might not cover some things other would want to
> cover in their courses.  (This topic was lightly discussed. If
> anything, pedagogy might be an interesting topic to developer further
> here.)
>
> =========================================================================
>
> 6. Website - Maintenance required
>
> The csound.com / csound.github.io website would benefit by having
> further maintainers/contributors.  The site is open source and hosted
> on github. Users can contribute either by pull request, filing issues,
> or emailng a site maintainer.
>
> One of the things that came up was a desire for a better showcase.
> Also, we need to replace the now-defunct SoundCloud group play list as
> it's broken.
>
> How to Contribute for the website is explained here:
>
> http://csound.github.io/contribute.html
>
> (which is also a page that needs development/contributions!)
>
> I would suggest two things:
>
> a. Let's audit the csound site together here on the user list and file
> all issues on the csound.github.io issue tracker
> (https://github.com/csound/csound.github.io/issues)
>
> b. Let's coordinate and try to do the site update together (maybe we
> can designate a week where people can volunteer to take on one or
> more tasks that get added to the issue tracker)
>
>
> ==========================================================================
>
> 7. Video Tutorials
>
> This was brought up in the ICSC 2015 in St. Petersburg and lightly
> again at this year's conference.  Dr. B made an important point I
> think in the 2015 conference that many people today are using YouTube
> and other video sites as the way to learn new information.  We could
> probably reach out to a lot more people who might be interested in
> Csound by producing more videos.
>
> ==========================================================================
>
> 8. Csound Web
>
> This is one thing that I discussed a little bit with Joachim. I think
> it would be good to have a set of examples for using Web Csound (the
> WASM build with Emscripten fallback) to make web applications.  The
> idea is to have a set of simple examples that demonstrate different
> features, similarly to how the csoundAPI_Examples project is setup
> (see https://github.com/csound/csoundAPI_Examples/).  I think this is
> an area of Csound use that offers users a lot of neat musical
> possibilities, but it could be made easier to get into and use if
> there are more models to follow.
>
> I don't know if this would be a good thing to have as a separate
> project or just a matter of further developing the existing examples.
>
> I think it would also be good to have templates here.  For example, a
> use case might be "I want to build a Web instrument with a visual
> interface that uses Csound in the background and works with MIDI". If
> we have a template available that has a basic instrument already setup
> and comments in files to direct users on what to edit to modify audio
> and interface code and so on, it might be useful.
>
>
> =========================================================================
>
> 9. Csound 7/6.10
>
> Regarding Csound 7, most of the people I spoke to seemed excited by
> the possibilities and the scope of what is considered for CS7 and that
> we will be moving on to working on it.  On the other hand, the
> concerns over CsoundQT and stability in general, especially in regards
> to the new Visual Studio build for Windows, makes me think that 6.10
> should be given a little more time before release and time spent for
> testing/hardening and making 6.10 as stable as possible.  (As a
> sidenote, there's one are of code I saw while abroad regarding locks
> and the API that I think might be beneficial to update before moving
> on to CS7).
>
> We need to figure out the scheduling for 6.10 to incorporate the above
> and anything that arises from this email thread.  Also to note for the
> general user community: 6.10 has important fixes (particularly for
> loscil) that we wanted to get out ASAP. The developer plan was to move
> on to focusing on implementing Csound 7 after 6.10 goes out, but to
> maintain a 6.x branch for any further 6.x releases for bug fixes.
>
> ==========================================================================
>
> 10. A Personal Reflection on Conference
>
> I missed seeing a lot of friends make it to the conference, but at the
> same time, I learned a great deal at the conference and thought it was
> both very well produced and important that we had it in Montevideo
> this year.  It was great to connect with composers and artists using
> Csound in Uruguay, Argentina, and Brazil, to hear their works and get
> their input.  I enjoyed the pieces from Csound users from around the
> world, and thought there was a great balance of papers, panels, and
> concerts.
>
> I think it was important too that we both celebrated the many good
> things about Csound and its community, as well as identified and
> reflected critically on issues that could be improved
>
> In my opinion, Csound the technology is in a good place: live
> processing and performance, composing pieces, live coding,
> interactivity via Arduinos and RPi's, web-based works were all
> represented to some degree at the conference and workshops.  The
> language changes for CS7 look to address a number of concerns, though
> I think further issues will be made apparent once we get further into
> development.  I think we have a number of things to figure out to make
> it easier for new Csound users and students to learn and use, but it
> looks like we're aware of it and now just have to do the work.
>
>
> Looking forward to hearing others' thoughts on all of this!
>
> Thanks,
> steven
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
>
>
> --
> http://luisantunespena.eu
> http://sumtone.com
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I'm not quite sure that a "platform installer" would be something that
grabs new versions of frontends.  Really, it'd be sort of what we have
now with the existing Windows and OSX installers, but I think would be
done more in a 3rd party location, and with a different release
schedule.

I think the idea here too is not to emphasize the latest and greatest
but rather to emphasize stability.  The goal would be to have as
reliable and consistent an install as possible.

Perhaps having some kind of network installer would be sort of nice
that chose versions to install, but I'm not sure what would be
involved and I suppose it's a slightly different model than what I
first mentioned.  Might be interesting if you had a Csound Platform
manager program that you ran, saw updates and clicked to install, as
well as had separate categories for stable and rolling releases. In a
way, this is already possible if using something like Homebrew or
Linux package manager like apt, but something more end-user friendly
for OSX and Windows would be necessary.

On Wed, Oct 11, 2017 at 4:03 AM, Rory Walsh  wrote:
> Thanks for this Steven. It's great to get a run down of things that popped
> up over the course of the conference.
>
> With regards to 1, I would be very much in favour of a core Csound
> installer, (including the manual) and a platform installer. It would be nice
> if the platform installer downloaded and installed frontends from their
> respective sites rather than bundle them into the installer (nobody wants to
> download 2gigs of of package when they only install a fraction of that).
>
> If this was the possible then users using the "platform installer" would
> always get the most up to date frontends. I'd be more than happy to have
> Cabbage available through an installer like this.If this platform installer
> also downloaded the latest release of Csound from github then there wouldn't
> be any need to maintain or update it for each release. That would make life
> easier right?
>
> I've got to head to class now, but I'll post back on the other points made a
> little later on.
>
> On 11 October 2017 at 08:47, luis antunes pena  wrote:
>>
>> I have some short examples of csound code I made for my students some time
>> ago. These are short compositions based on a simple idea. Once I make the
>> code clean and understandable, I would be happy to share with the community
>> if this of interest.
>> Best,
>> Luis
>>
>> Am 10.10.17 um 22:13 schrieb Michael Gogins:
>>
>> I'd just like to add a few things to what Steven has said.
>>
>> There was a feeling at the ICSC that Csound needs new developers. And
>> I think it needs new musicians as well.
>>
>> NEW USERS
>>
>> I think we need an online showcase for Csound pieces that will
>> demonstrate to the world the power and breadth of what Csound can do.
>> Everything should run in Csound for WebAssembly with all source code
>> available. This should be a blog to which anyone can post pieces, and
>> should have a rating system. For examples, look at http://gibber.cc/
>> and especially https://www.shadertoy.com/, just change "shader" to
>> "piece" and the shader code to Csound code or HTML5 code.
>>
>> I have looked at the technology and it looks to me like the quickest
>> start to getting something nice going is to create a WordPress blog
>> that includes Csound for WebAssembly with some custom buttons for the
>> pages (play, stop, fork, etc.). We could add Csound for WebAssembly to
>> the existing csound.github.io site as I already have done for my
>> gogins.github.io site, but sites based on GitHub pages or Jekyll are
>> static sites to which one can contribute only by committing and
>> pushing files. I think something like a blog would be much better for
>> non-developers. But customizing WordPress generally means paying for
>> Web hosting (...it's cheap). This showcase also would of course accept
>> plain soundfiles or videos. There would be a default
>> Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)
>> license but individual pieces could have their own licenses.
>>
>> I am working on a prototype of this showcase.
>>
>> NEW CONTRIBUTORS
>>
>> I think the package manager idea is essential and it will serve both
>> musicians and developers.
>>
>> I think the continuous integration builds should be the standard
>> builds for Linux, Windows and OS X. And it should be possible to run
>> the standard builds on one's local computer. This should greatly lower
>> the bar to entry for Csound development.
>>
>> I second the notion of improving the Csound technical documentation.
>>
>> CSOUNDQT
>>
>> I'm fine with bringing CsoundQt into the Csound repository. Bringing
>> it in would make it easier for Csound developers to debug CsoundQt and
>> produce a stronger release of CsoundQt. But I'm also fine with keeping
>> the current repository. In either case, I think we need to spend a few
>> months making sure CsoundQt is stable for newbies on all desktop
>> platforms.
>>
>> I think two installers, not three, is the optimal mix. One with all
>> bells and whistles, one with only the "core." As far as I'm concerned,
>> the "core" installer can just be a zip file and one should be able to
>> run Csound without any configuration from the bin directory once it is
>> unzipped.
>>
>> Thanks,
>> Mike
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Tue, Oct 10, 2017 at 1:58 PM, Steven Yi  wrote:
>>
>> Hi All,
>>
>> I'm starting this email thread as a way to collect things that came up
>> during the ICSC panel discussions.  I did not take notes during these
>> sessions so will do my best to remember what was covered, and
>> hopefully Michael and others can fill in anything that I miss.  Some
>> of these things may also come from conversations over meals/walks;
>> some may also be more relevant for the development process or the user
>> community.
>>
>> ==================================================================
>> 1. CsoundQT
>>
>> This was probably the biggest point of discussion that came up during
>> the Developer panel and one that I think has many facets to it.  As it
>> is now, the problem that is happening at the moment is that CsoundQT
>> is often crashing for users. From people I spoke to at the conference,
>> this is not specific to one platform (i.e., users on Linux, OSX, and
>> Windows have all mentioned this).  This is a major problem that needs
>> addressing as CsoundQT was added to OSX and Windows installers as the
>> default GUI program to work with Csound, and many users are now coming
>> to Csound to give it a try and getting crashes as their first
>> impression.  (And older users and getting crashes as part of their
>> teaching and work...).
>>
>> Some aspects that came up during discussion:
>>
>> * Most everyone who develops Csound does not do work on CsoundQT
>> * Some users think CsoundQT is Csound and thus the reputation of
>> Csound gets tied to CsoundQT
>> * Having a installer is beneficial to have as a base Csound experience
>> that can be used for teaching
>> * Contrarily, some developers and users do not need CsoundQT, and only
>> need a minimal release with the core Csound libraries and executables
>> * Packaging CsoundQT with Csound ends up tying together their release
>> cycles somewhat
>> * Packaging Csound with CsoundQT allows CsoundQT to make releases on
>> their own schedules
>>
>> One thing I mentioned was taking approaches I had seen elsewhere,
>> which is two releases, one a minimal release, and one a full-package
>> build.  Another thought I had since the conference is that we could
>> maybe have three entities:
>>
>> 1. Core Csound - What the current developers here work on and release
>> 2. CsoundQT - Just the application, what the CsoundQT developers work
>> on and release
>> 3. "Csound Platform" Distribution - an installer that includes core
>> csound, CsoundQT, and whatever else others want as a basic platform
>> for teaching/using.
>>
>> This arrangement is familiar to me personally from the way Haskell and
>> LaTeX is developed/distributed.  For example:
>>
>> https://www.haskell.org/downloads
>> https://www.latex-project.org/get/
>>
>> In this arrangement, the Platform distribution would generally be a
>> "stable" release that may behind in versions of Csound and CsoundQT
>> but be more thoroughly tested and robust.
>>
>>
>> ==================================================================
>> 2. Package Manager
>>
>> This was something that came up in thinking about how to empower third
>> parties to share their work easily and require less things to go into
>> core Csound. The package manager should:
>>
>> * work with user-defined code (i.e., UDOs)
>> * work with native code (binaries and/or compile from source)
>> * resource files (i.e., audio, IRs, etc.)
>>
>> There are numerous package manager models from software distributions
>> (e.g., apt, yum, snap) and general programming languages (e.g. npm for
>> javascript, pip for python, gem for ruby, cocoapods for swift/obj-c).
>> More closely related for computer music, PD has deken
>> (https://github.com/pure-data/deken) and SuperCollider has Quarks
>> (http://doc.sccode.org/Guides/UsingQuarks.html).
>>
>> For Csound, I had written a test package manager system called CSPM a
>> few years ago but it never took off.  Ed Costello is currently working
>> on one, also called cspm (https://github.com/eddyc/cspm).
>>
>> A package manager would simplify incorporating others' work, such as
>> Joachim's UDO repository, into our own projects, by just adding a line
>> or two to say "this project requires this version of this repo to
>> operate" and have things download automatically.
>>
>> There are of course many things to work out (e.g., transitive
>> dependencies and version conflicts).  Also, there are things from
>> Csound 7 that would make this more powerful/simpler to integrate into
>> our projects (in particular, namespaces).
>>
>> =====================================================================
>>
>> 3. Platforms that do not support plugins
>>
>> Related to #2, we have platforms that do not deal with plugins so well
>> (i.e., Android, iOS, Web). Michael and I talked a little about having
>> build options to statically compile in opcode libs into libcsound as
>> an option, and I remembered that Roger Dannenberg had some interesting
>> C++ code to make this easy.
>>
>> Also related is how to simplify packaging UDOs and includes into files
>> when building for mobile and web.  I am unsure if we have a tool for
>> this already?  Either way, some examples would be good for this.
>>
>> ======================================================================
>>
>> 4. Encouraging new developer contributions to Csound
>>
>> We could certainly use more developers contributing to Csound.  This
>> is not only for Csound core but also for opcodes and other things.
>>
>> One thought is to revive efforts to document the system (see
>>
>> https://github.com/csound/csound/tree/develop/doc/csound_system_documentation).
>> John has already done some new documentation for Opcode contributions
>> (https://github.com/csound/csound/blob/develop/Submitting_opcodes).  I
>> think we need to do a better job of having a starting place to point
>> users to different areas for development contributions, which is an
>> organization issue (i.e., adding some text to the README.md with links
>> to the other documentation).
>>
>> Another is to produce walk through videos for how to compile/develop
>> Csound with Xcode on OSX and Visual Studio on Windows.
>>
>> I seem to remember some other aspects to this topic, but can't recall
>> them at the moment.  I think this is important to identify issues we
>> need to improve upon and address.
>>
>> ========================================================================
>>
>> 5. Teaching Csound - Course materials and new book possibility?
>>
>> There was some interesting discussion about perhaps having some kind
>> of standard or base set of materials for teaching Csound. My thoughts
>> were that it would make teachers' life simpler if they were
>> considering to teach Csound to have a semester plan/syllabus
>> accessible.  The supporting text could be one of the existing texts
>> (e.g., the newer Csound book (the one published by Springer), the
>> FLOSS manual) or perhaps a new text.  Counter arguments for a common
>> material is that it might not cover some things other would want to
>> cover in their courses.  (This topic was lightly discussed. If
>> anything, pedagogy might be an interesting topic to developer further
>> here.)
>>
>> =========================================================================
>>
>> 6. Website - Maintenance required
>>
>> The csound.com / csound.github.io website would benefit by having
>> further maintainers/contributors.  The site is open source and hosted
>> on github. Users can contribute either by pull request, filing issues,
>> or emailng a site maintainer.
>>
>> One of the things that came up was a desire for a better showcase.
>> Also, we need to replace the now-defunct SoundCloud group play list as
>> it's broken.
>>
>> How to Contribute for the website is explained here:
>>
>> http://csound.github.io/contribute.html
>>
>> (which is also a page that needs development/contributions!)
>>
>> I would suggest two things:
>>
>> a. Let's audit the csound site together here on the user list and file
>> all issues on the csound.github.io issue tracker
>> (https://github.com/csound/csound.github.io/issues)
>>
>> b. Let's coordinate and try to do the site update together (maybe we
>> can designate a week where people can volunteer to take on one or
>> more tasks that get added to the issue tracker)
>>
>>
>> ==========================================================================
>>
>> 7. Video Tutorials
>>
>> This was brought up in the ICSC 2015 in St. Petersburg and lightly
>> again at this year's conference.  Dr. B made an important point I
>> think in the 2015 conference that many people today are using YouTube
>> and other video sites as the way to learn new information.  We could
>> probably reach out to a lot more people who might be interested in
>> Csound by producing more videos.
>>
>> ==========================================================================
>>
>> 8. Csound Web
>>
>> This is one thing that I discussed a little bit with Joachim. I think
>> it would be good to have a set of examples for using Web Csound (the
>> WASM build with Emscripten fallback) to make web applications.  The
>> idea is to have a set of simple examples that demonstrate different
>> features, similarly to how the csoundAPI_Examples project is setup
>> (see https://github.com/csound/csoundAPI_Examples/).  I think this is
>> an area of Csound use that offers users a lot of neat musical
>> possibilities, but it could be made easier to get into and use if
>> there are more models to follow.
>>
>> I don't know if this would be a good thing to have as a separate
>> project or just a matter of further developing the existing examples.
>>
>> I think it would also be good to have templates here.  For example, a
>> use case might be "I want to build a Web instrument with a visual
>> interface that uses Csound in the background and works with MIDI". If
>> we have a template available that has a basic instrument already setup
>> and comments in files to direct users on what to edit to modify audio
>> and interface code and so on, it might be useful.
>>
>>
>> =========================================================================
>>
>> 9. Csound 7/6.10
>>
>> Regarding Csound 7, most of the people I spoke to seemed excited by
>> the possibilities and the scope of what is considered for CS7 and that
>> we will be moving on to working on it.  On the other hand, the
>> concerns over CsoundQT and stability in general, especially in regards
>> to the new Visual Studio build for Windows, makes me think that 6.10
>> should be given a little more time before release and time spent for
>> testing/hardening and making 6.10 as stable as possible.  (As a
>> sidenote, there's one are of code I saw while abroad regarding locks
>> and the API that I think might be beneficial to update before moving
>> on to CS7).
>>
>> We need to figure out the scheduling for 6.10 to incorporate the above
>> and anything that arises from this email thread.  Also to note for the
>> general user community: 6.10 has important fixes (particularly for
>> loscil) that we wanted to get out ASAP. The developer plan was to move
>> on to focusing on implementing Csound 7 after 6.10 goes out, but to
>> maintain a 6.x branch for any further 6.x releases for bug fixes.
>>
>> ==========================================================================
>>
>> 10. A Personal Reflection on Conference
>>
>> I missed seeing a lot of friends make it to the conference, but at the
>> same time, I learned a great deal at the conference and thought it was
>> both very well produced and important that we had it in Montevideo
>> this year.  It was great to connect with composers and artists using
>> Csound in Uruguay, Argentina, and Brazil, to hear their works and get
>> their input.  I enjoyed the pieces from Csound users from around the
>> world, and thought there was a great balance of papers, panels, and
>> concerts.
>>
>> I think it was important too that we both celebrated the many good
>> things about Csound and its community, as well as identified and
>> reflected critically on issues that could be improved
>>
>> In my opinion, Csound the technology is in a good place: live
>> processing and performance, composing pieces, live coding,
>> interactivity via Arduinos and RPi's, web-based works were all
>> represented to some degree at the conference and workshops.  The
>> language changes for CS7 look to address a number of concerns, though
>> I think further issues will be made apparent once we get further into
>> development.  I think we have a number of things to figure out to make
>> it easier for new Csound users and students to learn and use, but it
>> looks like we're aware of it and now just have to do the work.
>>
>>
>> Looking forward to hearing others' thoughts on all of this!
>>
>> Thanks,
>> steven
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>>
>>
>>
>> --
>> http://luisantunespena.eu
>> http://sumtone.com
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I was reworking the Csound Notebook earlier this summer and perhaps I
should get back to it.  The problem I see is that, like audio programs
for the web in general, I don't see a good way to use it for
teaching/using it to work with audio files / analyses.  Learning the
language, synthesis, realtime processing and live coding would be
possible.  (I have not explored much with dealing with Audio Files and
web Csound though, so perhaps others might have suggestions around
this.)

As related to CsoundQt and Csound installer, maybe we just need to
have a "stable" version so that we can teach/use it.  (Just
speculating out loud here.)

On Wed, Oct 11, 2017 at 4:15 AM, Tarmo Johannes  wrote:
> Hi,
>
> Thanks a lot for formulating and forwarding the ideas, Steven!
>
> What concerns a stable, easy to use front-end for entering level, I feel a
> web-based solution on Csound wasm would be best ( a little like CsoundNotebook
> now), integrated with Michael's interactive manual
> https://gogins.github.io/csound/html/indexframes.html
> - no download, no library conflicts + available from everywhere.
>
> Due to  html support that is already in CsoundQt (develop branch) but in
> testing/stabilizing phase, it could be possible to bind the work done on the
> web (including html elements or entire html page using Csound-wasm) very well
> with offline work and more powerful usage.  I think we will add also templates
> in CsoundQt to start off easily with Csound-wasm pages (or other html
> solutions like Csound-html-Android or Csound-in-Node.js) so there could be a
> strong bridge. But that in next-next version (0.9.6).
>
> If CsoundQt stays inside of the Csound installer or distributed as independent
> package is up to users. I think there is nothing that really replaces CsoundQt
> for whom have based their workflows on it and I definitely try to keep it in
> development.
>
> I will write another email about the stability issues of CsoundQt and
> collective co-operation soon.
>
> Best greetings!
> tarmo
>
>
> On teisipäev, 10. oktoober 2017 20:58.51 EEST you wrote:
>> Hi All,
>>
>> I'm starting this email thread as a way to collect things that came up
>> during the ICSC panel discussions.  I did not take notes during these
>> sessions so will do my best to remember what was covered, and
>> hopefully Michael and others can fill in anything that I miss.  Some
>> of these things may also come from conversations over meals/walks;
>> some may also be more relevant for the development process or the user
>> community.
>>
>> ==================================================================
>> 1. CsoundQT
>>
>> This was probably the biggest point of discussion that came up during
>> the Developer panel and one that I think has many facets to it.  As it
>> is now, the problem that is happening at the moment is that CsoundQT
>> is often crashing for users. From people I spoke to at the conference,
>> this is not specific to one platform (i.e., users on Linux, OSX, and
>> Windows have all mentioned this).  This is a major problem that needs
>> addressing as CsoundQT was added to OSX and Windows installers as the
>> default GUI program to work with Csound, and many users are now coming
>> to Csound to give it a try and getting crashes as their first
>> impression.  (And older users and getting crashes as part of their
>> teaching and work...).
>>
>> Some aspects that came up during discussion:
>>
>> * Most everyone who develops Csound does not do work on CsoundQT
>> * Some users think CsoundQT is Csound and thus the reputation of
>> Csound gets tied to CsoundQT
>> * Having a installer is beneficial to have as a base Csound experience
>> that can be used for teaching
>> * Contrarily, some developers and users do not need CsoundQT, and only
>> need a minimal release with the core Csound libraries and executables
>> * Packaging CsoundQT with Csound ends up tying together their release
>> cycles somewhat
>> * Packaging Csound with CsoundQT allows CsoundQT to make releases on
>> their own schedules
>>
>> One thing I mentioned was taking approaches I had seen elsewhere,
>> which is two releases, one a minimal release, and one a full-package
>> build.  Another thought I had since the conference is that we could
>> maybe have three entities:
>>
>> 1. Core Csound - What the current developers here work on and release
>> 2. CsoundQT - Just the application, what the CsoundQT developers work
>> on and release
>> 3. "Csound Platform" Distribution - an installer that includes core
>> csound, CsoundQT, and whatever else others want as a basic platform
>> for teaching/using.
>>
>> This arrangement is familiar to me personally from the way Haskell and
>> LaTeX is developed/distributed.  For example:
>>
>> https://www.haskell.org/downloads
>> https://www.latex-project.org/get/
>>
>> In this arrangement, the Platform distribution would generally be a
>> "stable" release that may behind in versions of Csound and CsoundQT
>> but be more thoroughly tested and robust.
>>
>>
>> ==================================================================
>> 2. Package Manager
>>
>> This was something that came up in thinking about how to empower third
>> parties to share their work easily and require less things to go into
>> core Csound. The package manager should:
>>
>> * work with user-defined code (i.e., UDOs)
>> * work with native code (binaries and/or compile from source)
>> * resource files (i.e., audio, IRs, etc.)
>>
>> There are numerous package manager models from software distributions
>> (e.g., apt, yum, snap) and general programming languages (e.g. npm for
>> javascript, pip for python, gem for ruby, cocoapods for swift/obj-c).
>> More closely related for computer music, PD has deken
>> (https://github.com/pure-data/deken) and SuperCollider has Quarks
>> (http://doc.sccode.org/Guides/UsingQuarks.html).
>>
>> For Csound, I had written a test package manager system called CSPM a
>> few years ago but it never took off.  Ed Costello is currently working
>> on one, also called cspm (https://github.com/eddyc/cspm).
>>
>> A package manager would simplify incorporating others' work, such as
>> Joachim's UDO repository, into our own projects, by just adding a line
>> or two to say "this project requires this version of this repo to
>> operate" and have things download automatically.
>>
>> There are of course many things to work out (e.g., transitive
>> dependencies and version conflicts).  Also, there are things from
>> Csound 7 that would make this more powerful/simpler to integrate into
>> our projects (in particular, namespaces).
>>
>> =====================================================================
>>
>> 3. Platforms that do not support plugins
>>
>> Related to #2, we have platforms that do not deal with plugins so well
>> (i.e., Android, iOS, Web). Michael and I talked a little about having
>> build options to statically compile in opcode libs into libcsound as
>> an option, and I remembered that Roger Dannenberg had some interesting
>> C++ code to make this easy.
>>
>> Also related is how to simplify packaging UDOs and includes into files
>> when building for mobile and web.  I am unsure if we have a tool for
>> this already?  Either way, some examples would be good for this.
>>
>> ======================================================================
>>
>> 4. Encouraging new developer contributions to Csound
>>
>> We could certainly use more developers contributing to Csound.  This
>> is not only for Csound core but also for opcodes and other things.
>>
>> One thought is to revive efforts to document the system (see
>> https://github.com/csound/csound/tree/develop/doc/csound_system_documentatio
>> n). John has already done some new documentation for Opcode contributions
>> (https://github.com/csound/csound/blob/develop/Submitting_opcodes).  I
>> think we need to do a better job of having a starting place to point users
>> to different areas for development contributions, which is an organization
>> issue (i.e., adding some text to the README.md with links to the other
>> documentation).
>>
>> Another is to produce walk through videos for how to compile/develop
>> Csound with Xcode on OSX and Visual Studio on Windows.
>>
>> I seem to remember some other aspects to this topic, but can't recall
>> them at the moment.  I think this is important to identify issues we
>> need to improve upon and address.
>>
>> ========================================================================
>>
>> 5. Teaching Csound - Course materials and new book possibility?
>>
>> There was some interesting discussion about perhaps having some kind
>> of standard or base set of materials for teaching Csound. My thoughts
>> were that it would make teachers' life simpler if they were
>> considering to teach Csound to have a semester plan/syllabus
>> accessible.  The supporting text could be one of the existing texts
>> (e.g., the newer Csound book (the one published by Springer), the
>> FLOSS manual) or perhaps a new text.  Counter arguments for a common
>> material is that it might not cover some things other would want to
>> cover in their courses.  (This topic was lightly discussed. If
>> anything, pedagogy might be an interesting topic to developer further
>> here.)
>>
>> =========================================================================
>>
>> 6. Website - Maintenance required
>>
>> The csound.com / csound.github.io website would benefit by having
>> further maintainers/contributors.  The site is open source and hosted
>> on github. Users can contribute either by pull request, filing issues,
>> or emailng a site maintainer.
>>
>> One of the things that came up was a desire for a better showcase.
>> Also, we need to replace the now-defunct SoundCloud group play list as
>> it's broken.
>>
>> How to Contribute for the website is explained here:
>>
>> http://csound.github.io/contribute.html
>>
>> (which is also a page that needs development/contributions!)
>>
>> I would suggest two things:
>>
>> a. Let's audit the csound site together here on the user list and file
>> all issues on the csound.github.io issue tracker
>> (https://github.com/csound/csound.github.io/issues)
>>
>> b. Let's coordinate and try to do the site update together (maybe we
>> can designate a week where people can volunteer to take on one or
>> more tasks that get added to the issue tracker)
>>
>>
>> ==========================================================================
>>
>> 7. Video Tutorials
>>
>> This was brought up in the ICSC 2015 in St. Petersburg and lightly
>> again at this year's conference.  Dr. B made an important point I
>> think in the 2015 conference that many people today are using YouTube
>> and other video sites as the way to learn new information.  We could
>> probably reach out to a lot more people who might be interested in
>> Csound by producing more videos.
>>
>> ==========================================================================
>>
>> 8. Csound Web
>>
>> This is one thing that I discussed a little bit with Joachim. I think
>> it would be good to have a set of examples for using Web Csound (the
>> WASM build with Emscripten fallback) to make web applications.  The
>> idea is to have a set of simple examples that demonstrate different
>> features, similarly to how the csoundAPI_Examples project is setup
>> (see https://github.com/csound/csoundAPI_Examples/).  I think this is
>> an area of Csound use that offers users a lot of neat musical
>> possibilities, but it could be made easier to get into and use if
>> there are more models to follow.
>>
>> I don't know if this would be a good thing to have as a separate
>> project or just a matter of further developing the existing examples.
>>
>> I think it would also be good to have templates here.  For example, a
>> use case might be "I want to build a Web instrument with a visual
>> interface that uses Csound in the background and works with MIDI". If
>> we have a template available that has a basic instrument already setup
>> and comments in files to direct users on what to edit to modify audio
>> and interface code and so on, it might be useful.
>>
>>
>> =========================================================================
>>
>> 9. Csound 7/6.10
>>
>> Regarding Csound 7, most of the people I spoke to seemed excited by
>> the possibilities and the scope of what is considered for CS7 and that
>> we will be moving on to working on it.  On the other hand, the
>> concerns over CsoundQT and stability in general, especially in regards
>> to the new Visual Studio build for Windows, makes me think that 6.10
>> should be given a little more time before release and time spent for
>> testing/hardening and making 6.10 as stable as possible.  (As a
>> sidenote, there's one are of code I saw while abroad regarding locks
>> and the API that I think might be beneficial to update before moving
>> on to CS7).
>>
>> We need to figure out the scheduling for 6.10 to incorporate the above
>> and anything that arises from this email thread.  Also to note for the
>> general user community: 6.10 has important fixes (particularly for
>> loscil) that we wanted to get out ASAP. The developer plan was to move
>> on to focusing on implementing Csound 7 after 6.10 goes out, but to
>> maintain a 6.x branch for any further 6.x releases for bug fixes.
>>
>> ==========================================================================
>>
>> 10. A Personal Reflection on Conference
>>
>> I missed seeing a lot of friends make it to the conference, but at the
>> same time, I learned a great deal at the conference and thought it was
>> both very well produced and important that we had it in Montevideo
>> this year.  It was great to connect with composers and artists using
>> Csound in Uruguay, Argentina, and Brazil, to hear their works and get
>> their input.  I enjoyed the pieces from Csound users from around the
>> world, and thought there was a great balance of papers, panels, and
>> concerts.
>>
>> I think it was important too that we both celebrated the many good
>> things about Csound and its community, as well as identified and
>> reflected critically on issues that could be improved
>>
>> In my opinion, Csound the technology is in a good place: live
>> processing and performance, composing pieces, live coding,
>> interactivity via Arduinos and RPi's, web-based works were all
>> represented to some degree at the conference and workshops.  The
>> language changes for CS7 look to address a number of concerns, though
>> I think further issues will be made apparent once we get further into
>> development.  I think we have a number of things to figure out to make
>> it easier for new Csound users and students to learn and use, but it
>> looks like we're aware of it and now just have to do the work.
>>
>>
>> Looking forward to hearing others' thoughts on all of this!
>>
>> Thanks,
>> steven
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

For the website: we need to just get this kickstarted, IMO.  Maybe an
online chat on Slack in the #csound_github_io channel would be a way
to get going?

For the Videos, I took a look at the playlists and it's great.  The
issue I see is how do we get something like this advertised on the
Csound website?  I think one of Dr. B's students used to aggregate
things in a Youtube Playlist, but that seems to put the burden on one
person.  Should we consider making video links a new kind of news post
where users can post one link per page?  (It'd also then work for all
videos on any website, e.g. YouTube and Vimeo). It'd also centralize
information to one portal (csound.github.io / csound.com).



On Wed, Oct 11, 2017 at 5:38 AM, Rory Walsh  wrote:
>> 2. Package Manager
>>
>> This was something that came up in thinking about how to empower third
>> parties to share their work easily and require less things to go into
>> core Csound. The package manager should:
>
>
> This would be great.
>
>> 4. Encouraging new developer contributions to Csound
>>
>> We could certainly use more developers contributing to Csound.  This
>> is not only for Csound core but also for opcodes and other things.
>>
>> One thought is to revive efforts to document the system (see
>>
>> https://github.com/csound/csound/tree/develop/doc/csound_system_documentation).
>> John has already done some new documentation for Opcode contributions
>> (https://github.com/csound/csound/blob/develop/Submitting_opcodes).  I
>> think we need to do a better job of having a starting place to point
>> users to different areas for development contributions, which is an
>> organization issue (i.e., adding some text to the README.md with links
>> to the other documentation).
>>
>> Another is to produce walk through videos for how to compile/develop
>> Csound with Xcode on OSX and Visual Studio on Windows.
>>
>> I seem to remember some other aspects to this topic, but can't recall
>> them at the moment.  I think this is important to identify issues we
>> need to improve upon and address.
>
>
> Once I get Csound building with MSVC I don't mind preparing some simple walk
> through videos on plugin development. However, I wouldn't be comfortable
> discussing Csound internals.
>
>>
>> ========================================================================
>>
>> 5. Teaching Csound - Course materials and new book possibility?
>>
>> There was some interesting discussion about perhaps having some kind
>> of standard or base set of materials for teaching Csound. My thoughts
>> were that it would make teachers' life simpler if they were
>> considering to teach Csound to have a semester plan/syllabus
>> accessible.  The supporting text could be one of the existing texts
>> (e.g., the newer Csound book (the one published by Springer), the
>> FLOSS manual) or perhaps a new text.  Counter arguments for a common
>> material is that it might not cover some things other would want to
>> cover in their courses.  (This topic was lightly discussed. If
>> anything, pedagogy might be an interesting topic to developer further
>> here.)
>
>
> I think simply presenting as much resources/information as possible through
> the website is the way to go here.
>
>
>>
>> =========================================================================
>>
>> 6. Website - Maintenance required
>>
>> The csound.com / csound.github.io website would benefit by having
>> further maintainers/contributors.  The site is open source and hosted
>> on github. Users can contribute either by pull request, filing issues,
>> or emailng a site maintainer.
>>
>> One of the things that came up was a desire for a better showcase.
>> Also, we need to replace the now-defunct SoundCloud group play list as
>> it's broken.
>>
>> How to Contribute for the website is explained here:
>>
>> http://csound.github.io/contribute.html
>>
>> (which is also a page that needs development/contributions!)
>>
>> I would suggest two things:
>>
>> a. Let's audit the csound site together here on the user list and file
>> all issues on the csound.github.io issue tracker
>> (https://github.com/csound/csound.github.io/issues)
>>
>> b. Let's coordinate and try to do the site update together (maybe we
>> can designate a week where people can volunteer to take on one or
>> more tasks that get added to the issue tracker)
>
>
> Both of the suggestions above are great. We could try this in the next few
> weeks?
>
>
>>
>> ==========================================================================
>>
>> 7. Video Tutorials
>>
>> This was brought up in the ICSC 2015 in St. Petersburg and lightly
>> again at this year's conference.  Dr. B made an important point I
>> think in the 2015 conference that many people today are using YouTube
>> and other video sites as the way to learn new information.  We could
>> probably reach out to a lot more people who might be interested in
>> Csound by producing more videos.
>
>
> Agreed. Student tend to go for these much faster than they will any text
> based tutorials. I have some posted here:|
> https://www.youtube.com/channel/UCWB8axin-qfcWlMt-8LhrHg/playlists
> Although they are geared towards Cabbage, they do cover the basics too. I'm
> in the process of updating my work PC. When it's done I should be able to
> create a few more. The more the merrier.
>
>
>>
>> 9. Csound 7/6.10
>>
>> Regarding Csound 7, most of the people I spoke to seemed excited by
>> the possibilities and the scope of what is considered for CS7 and that
>> we will be moving on to working on it.  On the other hand, the
>> concerns over CsoundQT and stability in general, especially in regards
>> to the new Visual Studio build for Windows, makes me think that 6.10
>> should be given a little more time before release and time spent for
>> testing/hardening and making 6.10 as stable as possible.  (As a
>> sidenote, there's one are of code I saw while abroad regarding locks
>> and the API that I think might be beneficial to update before moving
>> on to CS7).
>>
>>
>> We need to figure out the scheduling for 6.10 to incorporate the above
>> and anything that arises from this email thread.  Also to note for the
>> general user community: 6.10 has important fixes (particularly for
>> loscil) that we wanted to get out ASAP. The developer plan was to move
>> on to focusing on implementing Csound 7 after 6.10 goes out, but to
>> maintain a 6.x branch for any further 6.x releases for bug fixes.
>
>
> This sounds like a good plan. I haven't gotten around to testing the new VS
> build. My last attempt to build failed, but much work has been done since. I
> will try to get it going soon and report back.
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi John,

I'll start a separate thread on csound-dev mailing list about 6.10
release planning.

steven

On Wed, Oct 11, 2017 at 8:07 AM, John ff  wrote:
> Wrt version 6.10 I think we need to release soon as the bug in loscil is serious aznd is causing problems already.
>
> ⁣Sent from TypeApp
>
> On Oct 11, 2017, 10:39, at 10:39, Rory Walsh  wrote:
>>>
>>> 2. Package Manager
>>>
>>> This was something that came up in thinking about how to empower
>>third
>>> parties to share their work easily and require less things to go into
>>> core Csound. The package manager should:
>>
>>
>>This would be great.
>>
>>4. Encouraging new developer contributions to Csound
>>>
>>> We could certainly use more developers contributing to Csound.  This
>>> is not only for Csound core but also for opcodes and other things.
>>>
>>> One thought is to revive efforts to document the system (see
>>> https://github.com/csound/csound/tree/develop/doc/
>>> csound_system_documentation).
>>> John has already done some new documentation for Opcode contributions
>>> (https://github.com/csound/csound/blob/develop/Submitting_opcodes).
>>I
>>> think we need to do a better job of having a starting place to point
>>> users to different areas for development contributions, which is an
>>> organization issue (i.e., adding some text to the README.md with
>>links
>>> to the other documentation).
>>>
>>> Another is to produce walk through videos for how to compile/develop
>>> Csound with Xcode on OSX and Visual Studio on Windows.
>>>
>>> I seem to remember some other aspects to this topic, but can't recall
>>> them at the moment.  I think this is important to identify issues we
>>> need to improve upon and address.
>>>
>>
>>Once I get Csound building with MSVC I don't mind preparing some simple
>>walk through videos on plugin development. However, I wouldn't be
>>comfortable discussing Csound internals.
>>
>>
>>>
>>========================================================================
>>>
>>> 5. Teaching Csound - Course materials and new book possibility?
>>>
>>> There was some interesting discussion about perhaps having some kind
>>> of standard or base set of materials for teaching Csound. My thoughts
>>> were that it would make teachers' life simpler if they were
>>> considering to teach Csound to have a semester plan/syllabus
>>> accessible.  The supporting text could be one of the existing texts
>>> (e.g., the newer Csound book (the one published by Springer), the
>>> FLOSS manual) or perhaps a new text.  Counter arguments for a common
>>> material is that it might not cover some things other would want to
>>> cover in their courses.  (This topic was lightly discussed. If
>>> anything, pedagogy might be an interesting topic to developer further
>>> here.)
>>>
>>
>>I think simply presenting as much resources/information as possible
>>through
>>the website is the way to go here.
>>
>>
>>
>>>
>>=========================================================================
>>>
>>> 6. Website - Maintenance required
>>>
>>> The csound.com / csound.github.io website would benefit by having
>>> further maintainers/contributors.  The site is open source and hosted
>>> on github. Users can contribute either by pull request, filing
>>issues,
>>> or emailng a site maintainer.
>>>
>>> One of the things that came up was a desire for a better showcase.
>>> Also, we need to replace the now-defunct SoundCloud group play list
>>as
>>> it's broken.
>>>
>>> How to Contribute for the website is explained here:
>>>
>>> http://csound.github.io/contribute.html
>>>
>>> (which is also a page that needs development/contributions!)
>>>
>>> I would suggest two things:
>>>
>>> a. Let's audit the csound site together here on the user list and
>>file
>>> all issues on the csound.github.io issue tracker
>>> (https://github.com/csound/csound.github.io/issues)
>>>
>>> b. Let's coordinate and try to do the site update together (maybe we
>>> can designate a week where people can volunteer to take on one or
>>> more tasks that get added to the issue tracker)
>>>
>>
>>Both of the suggestions above are great. We could try this in the next
>>few
>>weeks?
>>
>>
>>
>>>
>>==========================================================================
>>>
>>> 7. Video Tutorials
>>>
>>> This was brought up in the ICSC 2015 in St. Petersburg and lightly
>>> again at this year's conference.  Dr. B made an important point I
>>> think in the 2015 conference that many people today are using YouTube
>>> and other video sites as the way to learn new information.  We could
>>> probably reach out to a lot more people who might be interested in
>>> Csound by producing more videos.
>>>
>>
>>Agreed. Student tend to go for these much faster than they will any
>>text
>>based tutorials. I have some posted here:|
>>https://www.youtube.com/channel/UCWB8axin-qfcWlMt-8LhrHg/playlists
>>Although they are geared towards Cabbage, they do cover the basics too.
>>I'm
>>in the process of updating my work PC. When it's done I should be able
>>to
>>create a few more. The more the merrier.
>>
>>
>>
>>> 9. Csound 7/6.10
>>>
>>> Regarding Csound 7, most of the people I spoke to seemed excited by
>>> the possibilities and the scope of what is considered for CS7 and
>>that
>>> we will be moving on to working on it.  On the other hand, the
>>> concerns over CsoundQT and stability in general, especially in
>>regards
>>> to the new Visual Studio build for Windows, makes me think that 6.10
>>> should be given a little more time before release and time spent for
>>> testing/hardening and making 6.10 as stable as possible.  (As a
>>> sidenote, there's one are of code I saw while abroad regarding locks
>>> and the API that I think might be beneficial to update before moving
>>> on to CS7).
>>
>>
>>> We need to figure out the scheduling for 6.10 to incorporate the
>>above
>>> and anything that arises from this email thread.  Also to note for
>>the
>>> general user community: 6.10 has important fixes (particularly for
>>> loscil) that we wanted to get out ASAP. The developer plan was to
>>move
>>> on to focusing on implementing Csound 7 after 6.10 goes out, but to
>>> maintain a 6.x branch for any further 6.x releases for bug fixes.
>>>
>>
>>This sounds like a good plan. I haven't gotten around to testing the
>>new VS
>>build. My last attempt to build failed, but much work has been done
>>since.
>>I will try to get it going soon and report back.
>>
>>Csound mailing list
>>Csound@listserv.heanet.ie
>>https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>Send bugs reports to
>>        https://github.com/csound/csound/issues
>>Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Guillermo,

Thanks for chiming in!

Regarding 1. and 2., I think we may need to get ideas sorted out
between wanting an installer, platform manager, package manager, etc.
and what systems are available per platform already (apt, yum, etc.).
I did not think a Csound package manager would be used to install
Csound or frontend.  For example, in the Ruby world, I might use RVM
to install different versions of the ruby interpreter, but I would use
Gem to install different packages.  I think maybe it might be good to
have the package system and Csound application ecosystem be dealt with
separately?

As for pedagogy, thanks for sharing that paper (looks interesting but
haven't gotten through it quite yet!).  Perhaps an online Github
repository to house materials and discussion here could be good for
developing an online course?

Sidenote: I started a project and demoed it at a conference (can't
remember which one...) for learning Csound that used Web Csound.  The
project is still there:

https://github.com/csound/learn-csound-site

and can be viewed at:

http://csound.github.io/learn-csound-site/

At the time, people here seemed enthusiastic to help but it sort of
fizzled out.  This site used PNaCl csound and should probably be
updated to use WASM csound.  But maybe this could be what we use as a
basis to get going on a shared, online Csound learning site?  (We
could incorporate a frame for the manual as Tarmo suggested, amongst
other things)

Cheers!
steven

On Wed, Oct 11, 2017 at 1:45 PM, Guillermo Senna  wrote:
> Hi Steven,
>
> First of all, thanks for taking the time to write such a thorough email.
> I'm relatively new to Csound and so I feel a little bit uncomfortable
> sharing my opinions as a peer with all of you. But, as an Argentinian, I
> feel compelled to give an opinion on things I don't understand anyway as
> that is our national hobby.
>
>
> On 10/10/17 14:58, Steven Yi wrote:
>> Hi All,
>>
>> I'm starting this email thread as a way to collect things that came up
>> during the ICSC panel discussions.  I did not take notes during these
>> sessions so will do my best to remember what was covered, and
>> hopefully Michael and others can fill in anything that I miss.  Some
>> of these things may also come from conversations over meals/walks;
>> some may also be more relevant for the development process or the user
>> community.
>>
>> ==================================================================
>> 1. CsoundQT
>>
>> One thing I mentioned was taking approaches I had seen elsewhere,
>> which is two releases, one a minimal release, and one a full-package
>> build.  Another thought I had since the conference is that we could
>> maybe have three entities:
>>
>> 1. Core Csound - What the current developers here work on and release
>> 2. CsoundQT - Just the application, what the CsoundQT developers work
>> on and release
>> 3. "Csound Platform" Distribution - an installer that includes core
>> csound, CsoundQT, and whatever else others want as a basic platform
>> for teaching/using.
> Couldn't the Package Manager (a completely separate piece of software?)
> also be the solution to this point? If what you download from the Csound
> Github page is the Package Manager you could then decided what
> components of the Csound ecosystem you want to install. You could then
> say: "I just want Core Csound" or "I'm a newbie, tell me what should I
> install in order to get started", or even "I'm interested in writing
> plugins with Csound". That in turn would download and install the
> appropriate installers from Csound Github, Tarmo's or Rory's.
>>
>>
>> ==================================================================
>> 2. Package Manager
>>
>> This was something that came up in thinking about how to empower third
>> parties to share their work easily and require less things to go into
>> core Csound. The package manager should:
>>
>> * work with user-defined code (i.e., UDOs)
>> * work with native code (binaries and/or compile from source)
>> * resource files (i.e., audio, IRs, etc.)
> And then the same Package Manager that made it possible for you to
> install whatever Csound combo you wanted could be the thing that lets
> you add third-party resources to your work. Other things in that list
> could be (in the future): suggested updates, newly added or corrected
> examples and/or documentation and/or pedagogical resources (?). I like
> how apt-get works in the debian-based distros, but it should be
> something with a GUI if the Package Manager is also the Csound installer.
>> ========================================================================
>>
>> 5. Teaching Csound - Course materials and new book possibility?
>>
>> There was some interesting discussion about perhaps having some kind
>> of standard or base set of materials for teaching Csound. My thoughts
>> were that it would make teachers' life simpler if they were
>> considering to teach Csound to have a semester plan/syllabus
>> accessible.
> and
>> ==========================================================================
>>
>> 7. Video Tutorials
>>
>> This was brought up in the ICSC 2015 in St. Petersburg and lightly
>> again at this year's conference.  Dr. B made an important point I
>> think in the 2015 conference that many people today are using YouTube
>> and other video sites as the way to learn new information.  We could
>> probably reach out to a lot more people who might be interested in
>> Csound by producing more videos.
>>
>> ==========================================================================
> This year I have been doing some personal research on this topic
> (Project Based Learning, optimal ways of teaching a programming
> language, teaching with multimedia, etc). We have the Moodle platform
> installed on the faculty's server and only an hour and forty minutes per
> week for teaching Electroacoustic Music. I was thinking, why not teach
> Csound offline through PBL using Videos and weekly Assignments? If I
> manage to start rolling the thing the following year I promise to share
> any resources we create (overdubbed in English).
>
> The thing is I still don't know exactly what the right approach should
> be. First I thought it would be best to give the fundamentals of the
> language and after mastery is achieved move on towards showing coding
> recipes for audio programming. This kind of reflects how the Springer
> book was structured, although I was planning on using a more visual
> approach like the diagrams the Code Graphic Viewer produces in CsoundQt.
>
> But then I read that the "going through working examples" paradigm (I
> think it was this paper ->
> http://cs.au.dk/~mec/publications/conference/26--icer2007.pdf) seems to
> produce better results at not leaving students behind. In conclusion, I
> don't know yet what pedagogical paradigm we'll use for structuring our
> course and I'm open to any thoughts anyone wants to share with me.
>
> Whatever we end up choosing, if someone wants to collaborate with me on
> a project like this we could design a general online course in English
> for new Csound users around the globe.
>
> Cheers.
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Yes, I think you're right. Having separate things for the installer and
package manager could be better and actually simplify things. How about:

A) a meta installer: When you run it, it pulls a file from the Csound
Github repo that contains URLs, version numbers and a "depends on" field
for each different installer of the Csound ecosystem, which you then can
choose to download and run. AND it should also tell you if you want to
update (pull/uninstall old/install new) the software you currently have
on your machine.

B) some sort of package manager for the things you listed in 2). But
should it be a new executable, a library for frontends to use, new code
inside libcsound or some other thing?

For the online course I think we need to answer a lot of questions that
in turn are going to shape what we end up doing. I will start writing up
a list of questions and possible answers and then put it to a vote. Why?
I personally don't have much experience teaching yet and I think I would
need feedback about what every experienced Csound teacher in this
mailing list is doing and thinks that works or not.

But your project (later ported to WASM) looks great! I didn't know
something like that existed. I'm envisioning a github.io site with a
base on your project, but also with embedded youtube videos. Actually,
one of the questions I have is what won't we be able to do with Csound
running on the browser. What would we need to teach Csound and MIDI?
Audio input? GEN 01? I tried to modify the .js on the fly to enable
audio input, but chrome said that the site wasn't https and getmedia()
was deprecated for untrusted origins.

Even as an online course at some point we will have to abandon the
browser and transition to using an IDE. When? That's a question for my
list I think.


On 12/10/17 15:22, Steven Yi wrote:
> Hi Guillermo,
>
> Thanks for chiming in!
>
> Regarding 1. and 2., I think we may need to get ideas sorted out
> between wanting an installer, platform manager, package manager, etc.
> and what systems are available per platform already (apt, yum, etc.).
> I did not think a Csound package manager would be used to install
> Csound or frontend.  For example, in the Ruby world, I might use RVM
> to install different versions of the ruby interpreter, but I would use
> Gem to install different packages.  I think maybe it might be good to
> have the package system and Csound application ecosystem be dealt with
> separately?
>
> As for pedagogy, thanks for sharing that paper (looks interesting but
> haven't gotten through it quite yet!).  Perhaps an online Github
> repository to house materials and discussion here could be good for
> developing an online course?
>
> Sidenote: I started a project and demoed it at a conference (can't
> remember which one...) for learning Csound that used Web Csound.  The
> project is still there:
>
> https://github.com/csound/learn-csound-site
>
> and can be viewed at:
>
> http://csound.github.io/learn-csound-site/
>
> At the time, people here seemed enthusiastic to help but it sort of
> fizzled out.  This site used PNaCl csound and should probably be
> updated to use WASM csound.  But maybe this could be what we use as a
> basis to get going on a shared, online Csound learning site?  (We
> could incorporate a frame for the manual as Tarmo suggested, amongst
> other things)
>
> Cheers!
> steven
>
> On Wed, Oct 11, 2017 at 1:45 PM, Guillermo Senna  wrote:
>> Hi Steven,
>>
>> First of all, thanks for taking the time to write such a thorough email.
>> I'm relatively new to Csound and so I feel a little bit uncomfortable
>> sharing my opinions as a peer with all of you. But, as an Argentinian, I
>> feel compelled to give an opinion on things I don't understand anyway as
>> that is our national hobby.
>>
>>
>> On 10/10/17 14:58, Steven Yi wrote:
>>> Hi All,
>>>
>>> I'm starting this email thread as a way to collect things that came up
>>> during the ICSC panel discussions.  I did not take notes during these
>>> sessions so will do my best to remember what was covered, and
>>> hopefully Michael and others can fill in anything that I miss.  Some
>>> of these things may also come from conversations over meals/walks;
>>> some may also be more relevant for the development process or the user
>>> community.
>>>
>>> ==================================================================
>>> 1. CsoundQT
>>>
>>> One thing I mentioned was taking approaches I had seen elsewhere,
>>> which is two releases, one a minimal release, and one a full-package
>>> build.  Another thought I had since the conference is that we could
>>> maybe have three entities:
>>>
>>> 1. Core Csound - What the current developers here work on and release
>>> 2. CsoundQT - Just the application, what the CsoundQT developers work
>>> on and release
>>> 3. "Csound Platform" Distribution - an installer that includes core
>>> csound, CsoundQT, and whatever else others want as a basic platform
>>> for teaching/using.
>> Couldn't the Package Manager (a completely separate piece of software?)
>> also be the solution to this point? If what you download from the Csound
>> Github page is the Package Manager you could then decided what
>> components of the Csound ecosystem you want to install. You could then
>> say: "I just want Core Csound" or "I'm a newbie, tell me what should I
>> install in order to get started", or even "I'm interested in writing
>> plugins with Csound". That in turn would download and install the
>> appropriate installers from Csound Github, Tarmo's or Rory's.
>>>
>>> ==================================================================
>>> 2. Package Manager
>>>
>>> This was something that came up in thinking about how to empower third
>>> parties to share their work easily and require less things to go into
>>> core Csound. The package manager should:
>>>
>>> * work with user-defined code (i.e., UDOs)
>>> * work with native code (binaries and/or compile from source)
>>> * resource files (i.e., audio, IRs, etc.)
>> And then the same Package Manager that made it possible for you to
>> install whatever Csound combo you wanted could be the thing that lets
>> you add third-party resources to your work. Other things in that list
>> could be (in the future): suggested updates, newly added or corrected
>> examples and/or documentation and/or pedagogical resources (?). I like
>> how apt-get works in the debian-based distros, but it should be
>> something with a GUI if the Package Manager is also the Csound installer.
>>> ========================================================================
>>>
>>> 5. Teaching Csound - Course materials and new book possibility?
>>>
>>> There was some interesting discussion about perhaps having some kind
>>> of standard or base set of materials for teaching Csound. My thoughts
>>> were that it would make teachers' life simpler if they were
>>> considering to teach Csound to have a semester plan/syllabus
>>> accessible.
>> and
>>> ==========================================================================
>>>
>>> 7. Video Tutorials
>>>
>>> This was brought up in the ICSC 2015 in St. Petersburg and lightly
>>> again at this year's conference.  Dr. B made an important point I
>>> think in the 2015 conference that many people today are using YouTube
>>> and other video sites as the way to learn new information.  We could
>>> probably reach out to a lot more people who might be interested in
>>> Csound by producing more videos.
>>>
>>> ==========================================================================
>> This year I have been doing some personal research on this topic
>> (Project Based Learning, optimal ways of teaching a programming
>> language, teaching with multimedia, etc). We have the Moodle platform
>> installed on the faculty's server and only an hour and forty minutes per
>> week for teaching Electroacoustic Music. I was thinking, why not teach
>> Csound offline through PBL using Videos and weekly Assignments? If I
>> manage to start rolling the thing the following year I promise to share
>> any resources we create (overdubbed in English).
>>
>> The thing is I still don't know exactly what the right approach should
>> be. First I thought it would be best to give the fundamentals of the
>> language and after mastery is achieved move on towards showing coding
>> recipes for audio programming. This kind of reflects how the Springer
>> book was structured, although I was planning on using a more visual
>> approach like the diagrams the Code Graphic Viewer produces in CsoundQt.
>>
>> But then I read that the "going through working examples" paradigm (I
>> think it was this paper ->
>> http://cs.au.dk/~mec/publications/conference/26--icer2007.pdf) seems to
>> produce better results at not leaving students behind. In conclusion, I
>> don't know yet what pedagogical paradigm we'll use for structuring our
>> course and I'm open to any thoughts anyone wants to share with me.
>>
>> Whatever we end up choosing, if someone wants to collaborate with me on
>> a project like this we could design a general online course in English
>> for new Csound users around the globe.
>>
>> Cheers.
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Guillermo:


> A) a meta installer: When you run it, it pulls a file from the Csound
> Github repo that contains URLs, version numbers and a "depends on" field
> for each different installer of the Csound ecosystem, which you then can
> choose to download and run. AND it should also tell you if you want to
> update (pull/uninstall old/install new) the software you currently have
> on your machine.

This sounds good, but I have no idea what technologies would be
available for creating an installer like this.  (It seems something
like Adobe Creative Cloud's installer.) Does anyone know of an
installer technology like this for Windows and OSX?


> B) some sort of package manager for the things you listed in 2). But
> should it be a new executable, a library for frontends to use, new code
> inside libcsound or some other thing?

I think some kind of executable and managed in its own project.

> For the online course I think we need to answer a lot of questions that
> in turn are going to shape what we end up doing. I will start writing up
> a list of questions and possible answers and then put it to a vote. Why?
> I personally don't have much experience teaching yet and I think I would
> need feedback about what every experienced Csound teacher in this
> mailing list is doing and thinks that works or not.

Thanks for starting the other thread, I'm enjoying reading what others
are sharing regarding teaching!

> But your project (later ported to WASM) looks great! I didn't know
> something like that existed. I'm envisioning a github.io site with a
> base on your project, but also with embedded youtube videos. Actually,
> one of the questions I have is what won't we be able to do with Csound
> running on the browser. What would we need to teach Csound and MIDI?
> Audio input? GEN 01? I tried to modify the .js on the fly to enable
> audio input, but chrome said that the site wasn't https and getmedia()
> was deprecated for untrusted origins.

I was planning to do some research and start to develop some templates
for Web Csound and MIDI/Audio this week.  BTW, github does provide to
serve the site via https, so that should work okay when visiting
through there.  (The limitation for https and Web Audio was also
something that was added after that site was developed.)  I'll see if
I can get the Learn Csound site updated for WASM Csound this week and
will report back here in a separate thread.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

On 15/10/17 20:32, Steven Yi wrote:
> Hi Guillermo:
>
>
>> A) a meta installer: When you run it, it pulls a file from the Csound
>> Github repo that contains URLs, version numbers and a "depends on" field
>> for each different installer of the Csound ecosystem, which you then can
>> choose to download and run. AND it should also tell you if you want to
>> update (pull/uninstall old/install new) the software you currently have
>> on your machine.
> This sounds good, but I have no idea what technologies would be
> available for creating an installer like this.  (It seems something
> like Adobe Creative Cloud's installer.) Does anyone know of an
> installer technology like this for Windows and OSX?

I've seen many references to InstallBuilder in places like
StackOverflow. Apparently, the company provides a free license for Open
Source software. But I don't think it's free software per se, so I
wouldn't choose it. Has anyone used the Qt Installer Framework
(http://doc.qt.io/qtinstallerframework/ifw-overview.html) by any chance?
It seems to support updates and add-ons. It might be a solution provided
we can link against the Qt libraries statically in order to build the
installer itself.



>
>
>> B) some sort of package manager for the things you listed in 2). But
>> should it be a new executable, a library for frontends to use, new code
>> inside libcsound or some other thing?
> I think some kind of executable and managed in its own project.

I was leaning towards a library because I imagined it would be nice if
frontends could independently know if, for example, I include an UDO
that's not installed in the system to check and offer the possibility to
install it; also to have syntax highlighting and code completion. 
Although it might be very difficult to get the frontends developers on
the same page about the details.


>
>> For the online course I think we need to answer a lot of questions that
>> in turn are going to shape what we end up doing. I will start writing up
>> a list of questions and possible answers and then put it to a vote. Why?
>> I personally don't have much experience teaching yet and I think I would
>> need feedback about what every experienced Csound teacher in this
>> mailing list is doing and thinks that works or not.
> Thanks for starting the other thread, I'm enjoying reading what others
> are sharing regarding teaching!

Me too! I'm going to wait a little bit longer and then summarize and
make a proposal based on what I can learn from the replies.

>
>> But your project (later ported to WASM) looks great! I didn't know
>> something like that existed. I'm envisioning a github.io site with a
>> base on your project, but also with embedded youtube videos. Actually,
>> one of the questions I have is what won't we be able to do with Csound
>> running on the browser. What would we need to teach Csound and MIDI?
>> Audio input? GEN 01? I tried to modify the .js on the fly to enable
>> audio input, but chrome said that the site wasn't https and getmedia()
>> was deprecated for untrusted origins.
> I was planning to do some research and start to develop some templates
> for Web Csound and MIDI/Audio this week.  BTW, github does provide to
> serve the site via https, so that should work okay when visiting
> through there.  (The limitation for https and Web Audio was also
> something that was added after that site was developed.)  I'll see if
> I can get the Learn Csound site updated for WASM Csound this week and
> will report back here in a separate thread.

Excellent! Looking forward to seeing it.

Cheers.


>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here