A few responses from me.
> 	• The official site is not so pretty. it has this yet another open-source trash feel to it
> Can we create a better design for the site? Any web-designers out there?
> Can we reuse by any chance the ICSC 20015 website design
> to make the official site more attractive.

I am very happy for someone to improve the visual look of the site. However I must point
out that along the years we had sites that were improved that way but never maintained
properly. The current github page might not look great, but it is kept up-to-date.

> 	• Taking responsibilities
> Joachim has mentioned that it’s good to talk but to change things
> we need to do smth concrete. We need to take the responsibility
> to support ideas with actions.

I think that is the most important thing in this discussion. It is great that people
want to improve things and make everything better, but it is no good if it does
not translate into a certain level of commitment. The website thing above is
an example of this. Someone might come up with a snazzy site and then
disappear. That is not going to work. The current site is easy and clean
to maintain. Likewise with discussion fora etc, maintenance is needed.

> 
> 	• Make Cabbage built in UI for Csound. Switching the FLTK with Cabbage
> Cabbage is much nicer than FLTK. Can we ship the csound with cabbage support?
> Steven says that he wants to separate the csound as audio engine from
> front ends. There is no best front end and we should let the users
> choose the right front end.
> Also front ends can ship with Csound not other ways.

Replacing FLTK by Cabbage or anything else will not solve anything. It was a
mistake (mine actually) to bring FLTK as opcodes into canonical Csound (from
Maldonado’s version). I don’t think it should be repeated.
Frontends are a clean solution. We need to support them as best as we can,
by making the API work well. 

> 	• OSC based Csound API
> Can we make explicit support for OSC in the Csound API.
> With support for livecoding. So that we can use OSC to send the
> new instruments to Csound object (not just messages).

Two comments regarding this:
1) you can already send new instruments via UDP to Csound. 
2) You can write a lightweight Csound orchestra to take in
OSC and add instruments to a running Csound using the
compilestr and compileorc opcodes.

Finally adding OSC to the engine would bring another dependency
(liblo) to the core library. We could write our own code for it, but that would be
a waste of our meagre development team resources (reinventing
the wheel). I am against this, unless it can be shown to be a
real deficiency.

> 	• Creating opcodes out of Csd files. Emulating PD-abstractions in Csound
> The primary tool of abstraction for Csound is UDO. With UDO’s we can
> create a musical algorithm. It’s like defining a function in the Python with def.
> But UDO are restricted. We can use only opcodes in the UDOs.
> We can put into UDO only things that can be put into an instrument definition.
> But what if we could create a UDO out of complete Csound file.
> Just like we can do it in the PD or Max. Then the UDO can contain
> an Orchestra and the Score. it becomes very powerful audio generator.
> Imagine that you want to use the existing Csound composition in your own.
> Then tyou can use it as an opcode and trigger it in your code.
> The Csound already has the proper interface for it.
> We can treat the ins as input and outs as outputs for the UDO.
> That way we don’t need to change anything in the existent Csound code (csd).
> we can use old csd’s. But this limits us with using only signals.
> What if we want to have CSD that takes in ftable as parameter or a string.

While I see the point that is being made here, there is a fundamental difference
between PD and Csound. PD is based on single instances of patches, whereas
Csound has instruments that need to be instantiated. So when we, as you will
need to have events to instantiate things in that CSD. We can bring the
whole thing in, and get the audio out, but that’s not very flexible (we
may as well run it somewhere else and pipe it through jack/soundflower). This needs
to be thought through very carefully so that a more general interface can
be discussed.






------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I agree with Victor here on each point.

I have one comment on the site appearance. Changes that involve
changes to the style sheet (assuming there is one, I haven't looked)
would probably not require much maintenance. They should also be easy
to revert, if the names of styles are not changed, but just the
contents of the styles.

Regards,
Mike

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


On Tue, Oct 6, 2015 at 8:35 AM, Victor Lazzarini
 wrote:
> A few responses from me.
>>       • The official site is not so pretty. it has this yet another open-source trash feel to it
>> Can we create a better design for the site? Any web-designers out there?
>> Can we reuse by any chance the ICSC 20015 website design
>> to make the official site more attractive.
>
> I am very happy for someone to improve the visual look of the site. However I must point
> out that along the years we had sites that were improved that way but never maintained
> properly. The current github page might not look great, but it is kept up-to-date.
>
>>       • Taking responsibilities
>> Joachim has mentioned that it’s good to talk but to change things
>> we need to do smth concrete. We need to take the responsibility
>> to support ideas with actions.
>
> I think that is the most important thing in this discussion. It is great that people
> want to improve things and make everything better, but it is no good if it does
> not translate into a certain level of commitment. The website thing above is
> an example of this. Someone might come up with a snazzy site and then
> disappear. That is not going to work. The current site is easy and clean
> to maintain. Likewise with discussion fora etc, maintenance is needed.
>
>>
>>       • Make Cabbage built in UI for Csound. Switching the FLTK with Cabbage
>> Cabbage is much nicer than FLTK. Can we ship the csound with cabbage support?
>> Steven says that he wants to separate the csound as audio engine from
>> front ends. There is no best front end and we should let the users
>> choose the right front end.
>> Also front ends can ship with Csound not other ways.
>
> Replacing FLTK by Cabbage or anything else will not solve anything. It was a
> mistake (mine actually) to bring FLTK as opcodes into canonical Csound (from
> Maldonado’s version). I don’t think it should be repeated.
> Frontends are a clean solution. We need to support them as best as we can,
> by making the API work well.
>
>>       • OSC based Csound API
>> Can we make explicit support for OSC in the Csound API.
>> With support for livecoding. So that we can use OSC to send the
>> new instruments to Csound object (not just messages).
>
> Two comments regarding this:
> 1) you can already send new instruments via UDP to Csound.
> 2) You can write a lightweight Csound orchestra to take in
> OSC and add instruments to a running Csound using the
> compilestr and compileorc opcodes.
>
> Finally adding OSC to the engine would bring another dependency
> (liblo) to the core library. We could write our own code for it, but that would be
> a waste of our meagre development team resources (reinventing
> the wheel). I am against this, unless it can be shown to be a
> real deficiency.
>
>>       • Creating opcodes out of Csd files. Emulating PD-abstractions in Csound
>> The primary tool of abstraction for Csound is UDO. With UDO’s we can
>> create a musical algorithm. It’s like defining a function in the Python with def.
>> But UDO are restricted. We can use only opcodes in the UDOs.
>> We can put into UDO only things that can be put into an instrument definition.
>> But what if we could create a UDO out of complete Csound file.
>> Just like we can do it in the PD or Max. Then the UDO can contain
>> an Orchestra and the Score. it becomes very powerful audio generator.
>> Imagine that you want to use the existing Csound composition in your own.
>> Then tyou can use it as an opcode and trigger it in your code.
>> The Csound already has the proper interface for it.
>> We can treat the ins as input and outs as outputs for the UDO.
>> That way we don’t need to change anything in the existent Csound code (csd).
>> we can use old csd’s. But this limits us with using only signals.
>> What if we want to have CSD that takes in ftable as parameter or a string.
>
> While I see the point that is being made here, there is a fundamental difference
> between PD and Csound. PD is based on single instances of patches, whereas
> Csound has instruments that need to be instantiated. So when we, as you will
> need to have events to instantiate things in that CSD. We can bring the
> whole thing in, and get the audio out, but that’s not very flexible (we
> may as well run it somewhere else and pipe it through jack/soundflower). This needs
> to be thought through very carefully so that a more general interface can
> be discussed.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

On the point of "Learn by Listening", I have suggested that we need to make an online version of the manual that uses the current web implementations of Csound (pNaCl and Emscripten). I'd imagine a project like that could be generalised and could also be used to write online tutorials where each step of the tutorial could be played and controlled in real time, and also for an instrument and UDO database. This would be a large but ultimately very worthwhile project, and as other have echoed would require a lot of commitment. I would love to do this, but at the moment I am busy trying to finish my PhD, so maybe that could be planned as a project in the future.

On Tue, 6 Oct 2015 at 15:34 Michael Gogins <michael.gogins@gmail.com> wrote:

I agree with Victor here on each point.

I have one comment on the site appearance. Changes that involve
changes to the style sheet (assuming there is one, I haven't looked)
would probably not require much maintenance. They should also be easy
to revert, if the names of styles are not changed, but just the
contents of the styles.

Regards,
Mike

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


On Tue, Oct 6, 2015 at 8:35 AM, Victor Lazzarini
<Victor.Lazzarini@nuim.ie> wrote:
> A few responses from me.
>>       • The official site is not so pretty. it has this yet another open-source trash feel to it
>> Can we create a better design for the site? Any web-designers out there?
>> Can we reuse by any chance the ICSC 20015 website design
>> to make the official site more attractive.
>
> I am very happy for someone to improve the visual look of the site. However I must point
> out that along the years we had sites that were improved that way but never maintained
> properly. The current github page might not look great, but it is kept up-to-date.
>
>>       • Taking responsibilities
>> Joachim has mentioned that it’s good to talk but to change things
>> we need to do smth concrete. We need to take the responsibility
>> to support ideas with actions.
>
> I think that is the most important thing in this discussion. It is great that people
> want to improve things and make everything better, but it is no good if it does
> not translate into a certain level of commitment. The website thing above is
> an example of this. Someone might come up with a snazzy site and then
> disappear. That is not going to work. The current site is easy and clean
> to maintain. Likewise with discussion fora etc, maintenance is needed.
>
>>
>>       • Make Cabbage built in UI for Csound. Switching the FLTK with Cabbage
>> Cabbage is much nicer than FLTK. Can we ship the csound with cabbage support?
>> Steven says that he wants to separate the csound as audio engine from
>> front ends. There is no best front end and we should let the users
>> choose the right front end.
>> Also front ends can ship with Csound not other ways.
>
> Replacing FLTK by Cabbage or anything else will not solve anything. It was a
> mistake (mine actually) to bring FLTK as opcodes into canonical Csound (from
> Maldonado’s version). I don’t think it should be repeated.
> Frontends are a clean solution. We need to support them as best as we can,
> by making the API work well.
>
>>       • OSC based Csound API
>> Can we make explicit support for OSC in the Csound API.
>> With support for livecoding. So that we can use OSC to send the
>> new instruments to Csound object (not just messages).
>
> Two comments regarding this:
> 1) you can already send new instruments via UDP to Csound.
> 2) You can write a lightweight Csound orchestra to take in
> OSC and add instruments to a running Csound using the
> compilestr and compileorc opcodes.
>
> Finally adding OSC to the engine would bring another dependency
> (liblo) to the core library. We could write our own code for it, but that would be
> a waste of our meagre development team resources (reinventing
> the wheel). I am against this, unless it can be shown to be a
> real deficiency.
>
>>       • Creating opcodes out of Csd files. Emulating PD-abstractions in Csound
>> The primary tool of abstraction for Csound is UDO. With UDO’s we can
>> create a musical algorithm. It’s like defining a function in the Python with def.
>> But UDO are restricted. We can use only opcodes in the UDOs.
>> We can put into UDO only things that can be put into an instrument definition.
>> But what if we could create a UDO out of complete Csound file.
>> Just like we can do it in the PD or Max. Then the UDO can contain
>> an Orchestra and the Score. it becomes very powerful audio generator.
>> Imagine that you want to use the existing Csound composition in your own.
>> Then tyou can use it as an opcode and trigger it in your code.
>> The Csound already has the proper interface for it.
>> We can treat the ins as input and outs as outputs for the UDO.
>> That way we don’t need to change anything in the existent Csound code (csd).
>> we can use old csd’s. But this limits us with using only signals.
>> What if we want to have CSD that takes in ftable as parameter or a string.
>
> While I see the point that is being made here, there is a fundamental difference
> between PD and Csound. PD is based on single instances of patches, whereas
> Csound has instruments that need to be instantiated. So when we, as you will
> need to have events to instantiate things in that CSD. We can bring the
> whole thing in, and get the audio out, but that’s not very flexible (we
> may as well run it somewhere else and pipe it through jack/soundflower). This needs
> to be thought through very carefully so that a more general interface can
> be discussed.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

--

Edward Costello

------------------------------------------------------------------------------

_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I have suggested this previously, but I have put off doing it myself
until the different JavaScript APIs are unified, which I think is
essential.

Regards,
Mike

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


On Tue, Oct 6, 2015 at 10:04 AM, Victor Lazzarini
 wrote:
> yes, that is a great idea. Ideally we could devise a way in which the JS
> Csound implementations could be automatically integrated in the HTML manual
> build, rather than added by hand to a customised manual.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
> On 6 Oct 2015, at 14:53, Ed Costello  wrote:
>
> On the point of "Learn by Listening", I have suggested that we need to make
> an online version of the manual that uses the current web implementations of
> Csound (pNaCl and Emscripten). I'd imagine a project like that could be
> generalised and could also be used to write online tutorials where each step
> of the tutorial could be played and controlled in real time, and also for an
> instrument and UDO database. This would be a large but ultimately very
> worthwhile project, and as other have echoed would require a lot of
> commitment. I would love to do this, but at the moment I am busy trying to
> finish my PhD, so maybe that could be planned as a project in the future.
>
> On Tue, 6 Oct 2015 at 15:34 Michael Gogins  wrote:
>>
>> I agree with Victor here on each point.
>>
>> I have one comment on the site appearance. Changes that involve
>> changes to the style sheet (assuming there is one, I haven't looked)
>> would probably not require much maintenance. They should also be easy
>> to revert, if the names of styles are not changed, but just the
>> contents of the styles.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Tue, Oct 6, 2015 at 8:35 AM, Victor Lazzarini
>>  wrote:
>> > A few responses from me.
>> >>       • The official site is not so pretty. it has this yet another
>> >> open-source trash feel to it
>> >> Can we create a better design for the site? Any web-designers out
>> >> there?
>> >> Can we reuse by any chance the ICSC 20015 website design
>> >> to make the official site more attractive.
>> >
>> > I am very happy for someone to improve the visual look of the site.
>> > However I must point
>> > out that along the years we had sites that were improved that way but
>> > never maintained
>> > properly. The current github page might not look great, but it is kept
>> > up-to-date.
>> >
>> >>       • Taking responsibilities
>> >> Joachim has mentioned that it’s good to talk but to change things
>> >> we need to do smth concrete. We need to take the responsibility
>> >> to support ideas with actions.
>> >
>> > I think that is the most important thing in this discussion. It is great
>> > that people
>> > want to improve things and make everything better, but it is no good if
>> > it does
>> > not translate into a certain level of commitment. The website thing
>> > above is
>> > an example of this. Someone might come up with a snazzy site and then
>> > disappear. That is not going to work. The current site is easy and clean
>> > to maintain. Likewise with discussion fora etc, maintenance is needed.
>> >
>> >>
>> >>       • Make Cabbage built in UI for Csound. Switching the FLTK with
>> >> Cabbage
>> >> Cabbage is much nicer than FLTK. Can we ship the csound with cabbage
>> >> support?
>> >> Steven says that he wants to separate the csound as audio engine from
>> >> front ends. There is no best front end and we should let the users
>> >> choose the right front end.
>> >> Also front ends can ship with Csound not other ways.
>> >
>> > Replacing FLTK by Cabbage or anything else will not solve anything. It
>> > was a
>> > mistake (mine actually) to bring FLTK as opcodes into canonical Csound
>> > (from
>> > Maldonado’s version). I don’t think it should be repeated.
>> > Frontends are a clean solution. We need to support them as best as we
>> > can,
>> > by making the API work well.
>> >
>> >>       • OSC based Csound API
>> >> Can we make explicit support for OSC in the Csound API.
>> >> With support for livecoding. So that we can use OSC to send the
>> >> new instruments to Csound object (not just messages).
>> >
>> > Two comments regarding this:
>> > 1) you can already send new instruments via UDP to Csound.
>> > 2) You can write a lightweight Csound orchestra to take in
>> > OSC and add instruments to a running Csound using the
>> > compilestr and compileorc opcodes.
>> >
>> > Finally adding OSC to the engine would bring another dependency
>> > (liblo) to the core library. We could write our own code for it, but
>> > that would be
>> > a waste of our meagre development team resources (reinventing
>> > the wheel). I am against this, unless it can be shown to be a
>> > real deficiency.
>> >
>> >>       • Creating opcodes out of Csd files. Emulating PD-abstractions in
>> >> Csound
>> >> The primary tool of abstraction for Csound is UDO. With UDO’s we can
>> >> create a musical algorithm. It’s like defining a function in the Python
>> >> with def.
>> >> But UDO are restricted. We can use only opcodes in the UDOs.
>> >> We can put into UDO only things that can be put into an instrument
>> >> definition.
>> >> But what if we could create a UDO out of complete Csound file.
>> >> Just like we can do it in the PD or Max. Then the UDO can contain
>> >> an Orchestra and the Score. it becomes very powerful audio generator.
>> >> Imagine that you want to use the existing Csound composition in your
>> >> own.
>> >> Then tyou can use it as an opcode and trigger it in your code.
>> >> The Csound already has the proper interface for it.
>> >> We can treat the ins as input and outs as outputs for the UDO.
>> >> That way we don’t need to change anything in the existent Csound code
>> >> (csd).
>> >> we can use old csd’s. But this limits us with using only signals.
>> >> What if we want to have CSD that takes in ftable as parameter or a
>> >> string.
>> >
>> > While I see the point that is being made here, there is a fundamental
>> > difference
>> > between PD and Csound. PD is based on single instances of patches,
>> > whereas
>> > Csound has instruments that need to be instantiated. So when we, as you
>> > will
>> > need to have events to instantiate things in that CSD. We can bring the
>> > whole thing in, and get the audio out, but that’s not very flexible (we
>> > may as well run it somewhere else and pipe it through jack/soundflower).
>> > This needs
>> > to be thought through very carefully so that a more general interface
>> > can
>> > be discussed.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > _______________________________________________
>> > Csound-users mailing list
>> > Csound-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-users
>> > Send bugs reports to
>> >         https://github.com/csound/csound/issues
>> > Discussions of bugs and features can be posted here
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Csound-users mailing list
>> Csound-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-users
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> --
> Edward Costello
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Anton,

(Moving this to the new user's mailing list from the Sourceforge list)

Thanks very much for posting these here as well as on the issues
tracker, it's incredibly valuable.  I think our next steps for this
should be to figure out some actionable tasks that we can record as
issues in the csound and csound.github.io trackers. From there, we
should be able to refine the ideas as well as work towards addressing
each of them separately.

For the website, I've gotten started on a couple of things to help
make it a bit easier.  I will write about that in a moment in a
separate thread.

Thanks!
steven

On Tue, Oct 6, 2015 at 7:41 AM, Anton Kholomiov
 wrote:
> Topics at the round table ICSC 2015
>
> The main theme for the round table was the attraction of newcomers.
> The Csound is magic and we know it but how can we explain it to others.
>
> There is confusion in learning resources, no showcases, no links to video
> tutorials.
> The thing that can capture the attention is portability. Lots of systems
> can interact with Csound. we can catch the eye of newcomer with it.
>
> terms: the site - is official Csound’s github site
>
> Csound strong points: Portability
>
> I think that to attract the novices we need to advertise the things
> that nobody can do better than Csound. My impression of the conference
> is that right now the killer feature of Csound is the Portability.
> Csound can run anywhere and used with anything.
> iOS, Android, any desktop, web-browser, ipython spread sheets, Haskell,
> Clojure,
> RPi, custom effect processors, creating distributed audio systems
> or environments for collaborative composition — csound can create sound
> for them all. We need to explain it to newcommers and catch their attention
> with it.
> I think it would be nice to have Carusel widget on the web site that
> higlights
> this point. Smth like:
>
> http://audiokit.io/
>
> http://snapframework.com/
>
> Challenge for non-programmer users to update the info on the official Csound
> site.
> We need a guide for non-programmers to submit github pull requests.
>
> Steven said that the site is hosted on github
> and everyone can update it (add news, articles, learning resources).
> But nobody seems to do it.
>
> Tarmo replied that the procedure is unclear to him.
>
> The site is updated with pull requests the procedure
> is pretty obvious for the programmer since the
> git is a modern standard for collaborative coding.
>
> So we need to explain to non-programmers how to use the Github
> pull requests process. DrB mentions that he wants to learn
> by watching the video of it.
>
> Confusion with two sites
>
> We’ve got csounds.com and also github site which is official one.
> Students that learn Csound are often confused with the two sites.
> Where should I learn the Csound?
>
> DrB says that he wants to keep the csounds.com alive since
> he can loose so many information on Csound (17 Gb of Csound resouces, maybe
> I’m wrong with the figure).
> But we can host it on github and make redirects. It’s no that hard
> and eliminates the confusion.
>
> The official site is not so pretty. it has this yet another open-source
> trash feel to it
>
> Can we create a better design for the site? Any web-designers out there?
> Can we reuse by any chance the ICSC 20015 website design
> to make the official site more attractive.
>
> Confusion with Csound releases
>
> It’s not clear for the users where and how to install the Csound.
>
> Showcases of Csound on the site. Csound in Action approach
>
> There were so many cool projects going with Csound
> that I’m unaware of. It would be nice to be able to
> see what people are doing with Csound at the site.
>
> That’s how we can attract the newcomers. That’s how
> they can appreciate the powers of csound.
>
> Learning resources.
>
> For newcomer it’s hard to guess where should (s)he learn
> the Csound. I think it’s better to promote the FLOSS manual
> as the best place to learn (we need to have a link at the official site)
> and also we can provide links to the books or online materials and examples.
>
> Learn by video
>
> Is it possible to create screencasts of what can be done with Csound.
> Actually there is online video tutorial on Csound
>
> http://www.youtube.com/watch?v=KxyBTr0eamQ
>
> Maybe we should link to it on the site or even better to
> integrate to the site. So that users are not distracted by other things
> that they can see on youtube. So that they can see only
> original 12 or more video posts.
>
> We need more musical examples
>
> Sine waves are great but it’s hard to convince the novice with them.
> We need a book or a learning material that can explain the user
> how to create drums, pads, bases, leads with Csound. Smth like
> manuals for Circle and Thor synths
>
> http://www.futureaudioworkshop.com/circle/tutorials/tutorial1
>
> https://www.propellerheads.se/substance/discovering-reason/index.cfm?article=part19&fuseaction=get_article
>
> like csound demystified
>
> Learn by interaction
>
> It would be nice to have the Csound playground.
> Some web-page where users can edit and listen to Csound without
> the need to install compiler.
>
> Steven says that there is such a site. He has created
> a first example and wanted people to collaborate but nobody
> seems to did a thing.
>
> Anton says that’s the thing doesn’t works for him
> I need to install or activate pNaCl which he couldn’t
> figure out how to do it.
>
> The Rory says that there is JavaScript csound without
> any dependencies. Maybe it’s better to move the
> learning material to pure JS solution.
>
> Learn by listening
>
> It would be nice if learning resources could be played online.
> There is a text of the example and near the text we can see the
> play/stop button trigger the playing.
>
> Often users have not so much time to copy things
> into editor, download possible dependent audio files
> to execute the csound example.
>
> It’s nice to supply FLOSS manual and the Reference manual with
> this facility.
>
> It can be done with rendered audio files or it can be done
> with pure JS. The rendered audio requires a lot of routine work (and space
> on the server)
> the pure JS can be done with creating a Csound example widget
> and adding global css info. Maybe it’s better to do it with JS.
>
> Here is an example:
>
> http://www.futureaudioworkshop.com/circle/tutorials/tutorial1
>
> It’s really helps to see the reason (or to see no reason)
> in diving deeper into the thing that is explained.
>
> Taking responsibilities
>
> Joachim has mentioned that it’s good to talk but to change things
> we need to do smth concrete. We need to take the responsibility
> to support ideas with actions.
>
> Online forums with categories.
>
> It’s hard to use the mailing list because the questions on
> different topics are mixed up.
>
> If I’m novice it’s hard to ask for me when I see all the
> stuff about implementing a new feature or parallel execution
> performance. My question seems to be unrelated to the thing.
> But it is related and John Ff sends the reminder on it.
>
> It would be nice to have categories for discussion
>
> Csound for developers
>
> Csound for Newcomers
>
> Csound’s showcases (music, installations, performances)
>
> Csound for DSP engineers
>
> Csound for musicians/performers
>
> Csound and other tech stuff (Mobiles, Game engines, other languages)
>
> Possible solution is Goolge groups.
> But there can be reaction from the users (also Victor L, John F) that like
> to
> use the mailing list (no need to go to a separate site, and check it out).
> But we can explain that google-groups can also be used that way
>
> Stackoverflow tag for Csound
>
> Every language has it so why do we need to ignore this opportunity to help
> people.
>
> Make Cabbage built in UI for Csound. Switching the FLTK with Cabbage
>
> Cabbage is much nicer than FLTK. Can we ship the csound with cabbage
> support?
> Steven says that he wants to separate the csound as audio engine from
> front ends. There is no best front end and we should let the users
> choose the right front end.
>
> Also front ends can ship with Csound not other ways.
>
> CsoundQt built-in editor problem
>
> CsoundQt is such a great thing to use. But there is one thing that
> annoys many users. The CsoundQt forces the musicians to use it’s own editor.
> But there are much better ways to edit the text (Sublime text, Vim, Emacs,
> Idea IntelliJ).
> Can we separate the concepts? Use CsoundQt for it’s great widgets and
> let the musician to use his own favorite editor.
>
> Right now there is no other way than to copy and paste the text
> to CsoundQt. But it becomes harder to edit it.
>
> Issue tracker
>
> There are better ways than Github to do it. Can we use them?
> Do we need it?
>
> trac (http://trac.edgewall.org/) or
>
> Attlassian Confluence JIRA
>
> OSC based Csound API
>
> Can we make explicit support for OSC in the Csound API.
> With support for livecoding. So that we can use OSC to send the
> new instruments to Csound object (not just messages).
>
> Opcodes with named parameters
>
> It would be nice to be able to use named parameters.
> The python things like:
>
> filter(q = 0.5, centerFrequency = 1500, asig)
>
> Namespaces/modules for Csound
>
> The namespaces can help the user safely share their code.
> With modules we can import someone elses instruments.
> There is a Macro solution with include. But it can break the
> code by exposing the global names/tables. So it would be
> great to have the local instrmnets or UDOs that can be safely
> imported to the Csound code.
>
> With modules people can create and distribute they instruments/UDOs.
>
> Csound packages distribution standard
>
> The next question is to define Csound distribution standard (Csound
> packages).
> It’s very complicated question I guess.
> There is a collection of UDOs on the Csound site. It would be nice to be
> able
> to install the Csound functionality in the way Node packages are
> distributed.
> If we have the namespaces and modules in Csound. Is it poossible to create
> a tool like npm in the node or sbt in scala or leiningen in Clojure.
> That gives the user ability to reuse Csound code.
>
> Creating opcodes out of Csd files. Emulating PD-abstractions in Csound
>
> The primary tool of abstraction for Csound is UDO. With UDO’s we can
> create a musical algorithm. It’s like defining a function in the Python with
> def.
> But UDO are restricted. We can use only opcodes in the UDOs.
> We can put into UDO only things that can be put into an instrument
> definition.
>
> But what if we could create a UDO out of complete Csound file.
> Just like we can do it in the PD or Max. Then the UDO can contain
> an Orchestra and the Score. it becomes very powerful audio generator.
> Imagine that you want to use the existing Csound composition in your own.
> Then tyou can use it as an opcode and trigger it in your code.
>
> The Csound already has the proper interface for it.
> We can treat the ins as input and outs as outputs for the UDO.
> That way we don’t need to change anything in the existent Csound code (csd).
> we can use old csd’s. But this limits us with using only signals.
> What if we want to have CSD that takes in ftable as parameter or a string.
>
> Welcome to Montevideo for the next Csound Conference 2017
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

What is it pure JS that can run Csound (as alternative to pNaCl)? I'm interested to know about it

2015-10-07 20:06 GMT+03:00 Rory Walsh <rorywalsh@ear.ie>:

And I'm investigating the setting up of an online forum for all things Csound. I'll report back when things have progressed a little more.

On 7 October 2015 at 17:00, Steven Yi <stevenyi@gmail.com> wrote:

Hi Anton,

(Moving this to the new user's mailing list from the Sourceforge list)

Thanks very much for posting these here as well as on the issues
tracker, it's incredibly valuable.  I think our next steps for this
should be to figure out some actionable tasks that we can record as
issues in the csound and csound.github.io trackers. From there, we
should be able to refine the ideas as well as work towards addressing
each of them separately.

For the website, I've gotten started on a couple of things to help
make it a bit easier.  I will write about that in a moment in a
separate thread.

Thanks!
steven

On Tue, Oct 6, 2015 at 7:41 AM, Anton Kholomiov
<anton.kholomiov@gmail.com> wrote:
> Topics at the round table ICSC 2015
>
> The main theme for the round table was the attraction of newcomers.
> The Csound is magic and we know it but how can we explain it to others.
>
> There is confusion in learning resources, no showcases, no links to video
> tutorials.
> The thing that can capture the attention is portability. Lots of systems
> can interact with Csound. we can catch the eye of newcomer with it.
>
> terms: the site - is official Csound’s github site
>
> Csound strong points: Portability
>
> I think that to attract the novices we need to advertise the things
> that nobody can do better than Csound. My impression of the conference
> is that right now the killer feature of Csound is the Portability.
> Csound can run anywhere and used with anything.
> iOS, Android, any desktop, web-browser, ipython spread sheets, Haskell,
> Clojure,
> RPi, custom effect processors, creating distributed audio systems
> or environments for collaborative composition — csound can create sound
> for them all. We need to explain it to newcommers and catch their attention
> with it.
> I think it would be nice to have Carusel widget on the web site that
> higlights
> this point. Smth like:
>
> http://audiokit.io/
>
> http://snapframework.com/
>
> Challenge for non-programmer users to update the info on the official Csound
> site.
> We need a guide for non-programmers to submit github pull requests.
>
> Steven said that the site is hosted on github
> and everyone can update it (add news, articles, learning resources).
> But nobody seems to do it.
>
> Tarmo replied that the procedure is unclear to him.
>
> The site is updated with pull requests the procedure
> is pretty obvious for the programmer since the
> git is a modern standard for collaborative coding.
>
> So we need to explain to non-programmers how to use the Github
> pull requests process. DrB mentions that he wants to learn
> by watching the video of it.
>
> Confusion with two sites
>
> We’ve got csounds.com and also github site which is official one.
> Students that learn Csound are often confused with the two sites.
> Where should I learn the Csound?
>
> DrB says that he wants to keep the csounds.com alive since
> he can loose so many information on Csound (17 Gb of Csound resouces, maybe
> I’m wrong with the figure).
> But we can host it on github and make redirects. It’s no that hard
> and eliminates the confusion.
>
> The official site is not so pretty. it has this yet another open-source
> trash feel to it
>
> Can we create a better design for the site? Any web-designers out there?
> Can we reuse by any chance the ICSC 20015 website design
> to make the official site more attractive.
>
> Confusion with Csound releases
>
> It’s not clear for the users where and how to install the Csound.
>
> Showcases of Csound on the site. Csound in Action approach
>
> There were so many cool projects going with Csound
> that I’m unaware of. It would be nice to be able to
> see what people are doing with Csound at the site.
>
> That’s how we can attract the newcomers. That’s how
> they can appreciate the powers of csound.
>
> Learning resources.
>
> For newcomer it’s hard to guess where should (s)he learn
> the Csound. I think it’s better to promote the FLOSS manual
> as the best place to learn (we need to have a link at the official site)
> and also we can provide links to the books or online materials and examples.
>
> Learn by video
>
> Is it possible to create screencasts of what can be done with Csound.
> Actually there is online video tutorial on Csound
>
> http://www.youtube.com/watch?v=KxyBTr0eamQ
>
> Maybe we should link to it on the site or even better to
> integrate to the site. So that users are not distracted by other things
> that they can see on youtube. So that they can see only
> original 12 or more video posts.
>
> We need more musical examples
>
> Sine waves are great but it’s hard to convince the novice with them.
> We need a book or a learning material that can explain the user
> how to create drums, pads, bases, leads with Csound. Smth like
> manuals for Circle and Thor synths
>
> http://www.futureaudioworkshop.com/circle/tutorials/tutorial1
>
> https://www.propellerheads.se/substance/discovering-reason/index.cfm?article=part19&fuseaction=get_article
>
> like csound demystified
>
> Learn by interaction
>
> It would be nice to have the Csound playground.
> Some web-page where users can edit and listen to Csound without
> the need to install compiler.
>
> Steven says that there is such a site. He has created
> a first example and wanted people to collaborate but nobody
> seems to did a thing.
>
> Anton says that’s the thing doesn’t works for him
> I need to install or activate pNaCl which he couldn’t
> figure out how to do it.
>
> The Rory says that there is JavaScript csound without
> any dependencies. Maybe it’s better to move the
> learning material to pure JS solution.
>
> Learn by listening
>
> It would be nice if learning resources could be played online.
> There is a text of the example and near the text we can see the
> play/stop button trigger the playing.
>
> Often users have not so much time to copy things
> into editor, download possible dependent audio files
> to execute the csound example.
>
> It’s nice to supply FLOSS manual and the Reference manual with
> this facility.
>
> It can be done with rendered audio files or it can be done
> with pure JS. The rendered audio requires a lot of routine work (and space
> on the server)
> the pure JS can be done with creating a Csound example widget
> and adding global css info. Maybe it’s better to do it with JS.
>
> Here is an example:
>
> http://www.futureaudioworkshop.com/circle/tutorials/tutorial1
>
> It’s really helps to see the reason (or to see no reason)
> in diving deeper into the thing that is explained.
>
> Taking responsibilities
>
> Joachim has mentioned that it’s good to talk but to change things
> we need to do smth concrete. We need to take the responsibility
> to support ideas with actions.
>
> Online forums with categories.
>
> It’s hard to use the mailing list because the questions on
> different topics are mixed up.
>
> If I’m novice it’s hard to ask for me when I see all the
> stuff about implementing a new feature or parallel execution
> performance. My question seems to be unrelated to the thing.
> But it is related and John Ff sends the reminder on it.
>
> It would be nice to have categories for discussion
>
> Csound for developers
>
> Csound for Newcomers
>
> Csound’s showcases (music, installations, performances)
>
> Csound for DSP engineers
>
> Csound for musicians/performers
>
> Csound and other tech stuff (Mobiles, Game engines, other languages)
>
> Possible solution is Goolge groups.
> But there can be reaction from the users (also Victor L, John F) that like
> to
> use the mailing list (no need to go to a separate site, and check it out).
> But we can explain that google-groups can also be used that way
>
> Stackoverflow tag for Csound
>
> Every language has it so why do we need to ignore this opportunity to help
> people.
>
> Make Cabbage built in UI for Csound. Switching the FLTK with Cabbage
>
> Cabbage is much nicer than FLTK. Can we ship the csound with cabbage
> support?
> Steven says that he wants to separate the csound as audio engine from
> front ends. There is no best front end and we should let the users
> choose the right front end.
>
> Also front ends can ship with Csound not other ways.
>
> CsoundQt built-in editor problem
>
> CsoundQt is such a great thing to use. But there is one thing that
> annoys many users. The CsoundQt forces the musicians to use it’s own editor.
> But there are much better ways to edit the text (Sublime text, Vim, Emacs,
> Idea IntelliJ).
> Can we separate the concepts? Use CsoundQt for it’s great widgets and
> let the musician to use his own favorite editor.
>
> Right now there is no other way than to copy and paste the text
> to CsoundQt. But it becomes harder to edit it.
>
> Issue tracker
>
> There are better ways than Github to do it. Can we use them?
> Do we need it?
>
> trac (http://trac.edgewall.org/) or
>
> Attlassian Confluence JIRA
>
> OSC based Csound API
>
> Can we make explicit support for OSC in the Csound API.
> With support for livecoding. So that we can use OSC to send the
> new instruments to Csound object (not just messages).
>
> Opcodes with named parameters
>
> It would be nice to be able to use named parameters.
> The python things like:
>
> filter(q = 0.5, centerFrequency = 1500, asig)
>
> Namespaces/modules for Csound
>
> The namespaces can help the user safely share their code.
> With modules we can import someone elses instruments.
> There is a Macro solution with include. But it can break the
> code by exposing the global names/tables. So it would be
> great to have the local instrmnets or UDOs that can be safely
> imported to the Csound code.
>
> With modules people can create and distribute they instruments/UDOs.
>
> Csound packages distribution standard
>
> The next question is to define Csound distribution standard (Csound
> packages).
> It’s very complicated question I guess.
> There is a collection of UDOs on the Csound site. It would be nice to be
> able
> to install the Csound functionality in the way Node packages are
> distributed.
> If we have the namespaces and modules in Csound. Is it poossible to create
> a tool like npm in the node or sbt in scala or leiningen in Clojure.
> That gives the user ability to reuse Csound code.
>
> Creating opcodes out of Csd files. Emulating PD-abstractions in Csound
>
> The primary tool of abstraction for Csound is UDO. With UDO’s we can
> create a musical algorithm. It’s like defining a function in the Python with
> def.
> But UDO are restricted. We can use only opcodes in the UDOs.
> We can put into UDO only things that can be put into an instrument
> definition.
>
> But what if we could create a UDO out of complete Csound file.
> Just like we can do it in the PD or Max. Then the UDO can contain
> an Orchestra and the Score. it becomes very powerful audio generator.
> Imagine that you want to use the existing Csound composition in your own.
> Then tyou can use it as an opcode and trigger it in your code.
>
> The Csound already has the proper interface for it.
> We can treat the ins as input and outs as outputs for the UDO.
> That way we don’t need to change anything in the existent Csound code (csd).
> we can use old csd’s. But this limits us with using only signals.
> What if we want to have CSD that takes in ftable as parameter or a string.
>
> Welcome to Montevideo for the next Csound Conference 2017
>
>

> ------------------------------------------------------------------------------
>
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

This version uses pure JS:
http://eddyc.github.io/CsoundEmscripten/

Give it a moment to load properly.

On 7 October 2015 at 22:15, Anton Kholomiov <anton.kholomiov@gmail.com> wrote:

What is it pure JS that can run Csound (as alternative to pNaCl)? I'm interested to know about it

2015-10-07 20:06 GMT+03:00 Rory Walsh <rorywalsh@ear.ie>:

And I'm investigating the setting up of an online forum for all things Csound. I'll report back when things have progressed a little more.

On 7 October 2015 at 17:00, Steven Yi <stevenyi@gmail.com> wrote:

Hi Anton,

(Moving this to the new user's mailing list from the Sourceforge list)

Thanks very much for posting these here as well as on the issues
tracker, it's incredibly valuable.  I think our next steps for this
should be to figure out some actionable tasks that we can record as
issues in the csound and csound.github.io trackers. From there, we
should be able to refine the ideas as well as work towards addressing
each of them separately.

For the website, I've gotten started on a couple of things to help
make it a bit easier.  I will write about that in a moment in a
separate thread.

Thanks!
steven

On Tue, Oct 6, 2015 at 7:41 AM, Anton Kholomiov
<anton.kholomiov@gmail.com> wrote:
> Topics at the round table ICSC 2015
>
> The main theme for the round table was the attraction of newcomers.
> The Csound is magic and we know it but how can we explain it to others.
>
> There is confusion in learning resources, no showcases, no links to video
> tutorials.
> The thing that can capture the attention is portability. Lots of systems
> can interact with Csound. we can catch the eye of newcomer with it.
>
> terms: the site - is official Csound’s github site
>
> Csound strong points: Portability
>
> I think that to attract the novices we need to advertise the things
> that nobody can do better than Csound. My impression of the conference
> is that right now the killer feature of Csound is the Portability.
> Csound can run anywhere and used with anything.
> iOS, Android, any desktop, web-browser, ipython spread sheets, Haskell,
> Clojure,
> RPi, custom effect processors, creating distributed audio systems
> or environments for collaborative composition — csound can create sound
> for them all. We need to explain it to newcommers and catch their attention
> with it.
> I think it would be nice to have Carusel widget on the web site that
> higlights
> this point. Smth like:
>
> http://audiokit.io/
>
> http://snapframework.com/
>
> Challenge for non-programmer users to update the info on the official Csound
> site.
> We need a guide for non-programmers to submit github pull requests.
>
> Steven said that the site is hosted on github
> and everyone can update it (add news, articles, learning resources).
> But nobody seems to do it.
>
> Tarmo replied that the procedure is unclear to him.
>
> The site is updated with pull requests the procedure
> is pretty obvious for the programmer since the
> git is a modern standard for collaborative coding.
>
> So we need to explain to non-programmers how to use the Github
> pull requests process. DrB mentions that he wants to learn
> by watching the video of it.
>
> Confusion with two sites
>
> We’ve got csounds.com and also github site which is official one.
> Students that learn Csound are often confused with the two sites.
> Where should I learn the Csound?
>
> DrB says that he wants to keep the csounds.com alive since
> he can loose so many information on Csound (17 Gb of Csound resouces, maybe
> I’m wrong with the figure).
> But we can host it on github and make redirects. It’s no that hard
> and eliminates the confusion.
>
> The official site is not so pretty. it has this yet another open-source
> trash feel to it
>
> Can we create a better design for the site? Any web-designers out there?
> Can we reuse by any chance the ICSC 20015 website design
> to make the official site more attractive.
>
> Confusion with Csound releases
>
> It’s not clear for the users where and how to install the Csound.
>
> Showcases of Csound on the site. Csound in Action approach
>
> There were so many cool projects going with Csound
> that I’m unaware of. It would be nice to be able to
> see what people are doing with Csound at the site.
>
> That’s how we can attract the newcomers. That’s how
> they can appreciate the powers of csound.
>
> Learning resources.
>
> For newcomer it’s hard to guess where should (s)he learn
> the Csound. I think it’s better to promote the FLOSS manual
> as the best place to learn (we need to have a link at the official site)
> and also we can provide links to the books or online materials and examples.
>
> Learn by video
>
> Is it possible to create screencasts of what can be done with Csound.
> Actually there is online video tutorial on Csound
>
> http://www.youtube.com/watch?v=KxyBTr0eamQ
>
> Maybe we should link to it on the site or even better to
> integrate to the site. So that users are not distracted by other things
> that they can see on youtube. So that they can see only
> original 12 or more video posts.
>
> We need more musical examples
>
> Sine waves are great but it’s hard to convince the novice with them.
> We need a book or a learning material that can explain the user
> how to create drums, pads, bases, leads with Csound. Smth like
> manuals for Circle and Thor synths
>
> http://www.futureaudioworkshop.com/circle/tutorials/tutorial1
>
> https://www.propellerheads.se/substance/discovering-reason/index.cfm?article=part19&fuseaction=get_article
>
> like csound demystified
>
> Learn by interaction
>
> It would be nice to have the Csound playground.
> Some web-page where users can edit and listen to Csound without
> the need to install compiler.
>
> Steven says that there is such a site. He has created
> a first example and wanted people to collaborate but nobody
> seems to did a thing.
>
> Anton says that’s the thing doesn’t works for him
> I need to install or activate pNaCl which he couldn’t
> figure out how to do it.
>
> The Rory says that there is JavaScript csound without
> any dependencies. Maybe it’s better to move the
> learning material to pure JS solution.
>
> Learn by listening
>
> It would be nice if learning resources could be played online.
> There is a text of the example and near the text we can see the
> play/stop button trigger the playing.
>
> Often users have not so much time to copy things
> into editor, download possible dependent audio files
> to execute the csound example.
>
> It’s nice to supply FLOSS manual and the Reference manual with
> this facility.
>
> It can be done with rendered audio files or it can be done
> with pure JS. The rendered audio requires a lot of routine work (and space
> on the server)
> the pure JS can be done with creating a Csound example widget
> and adding global css info. Maybe it’s better to do it with JS.
>
> Here is an example:
>
> http://www.futureaudioworkshop.com/circle/tutorials/tutorial1
>
> It’s really helps to see the reason (or to see no reason)
> in diving deeper into the thing that is explained.
>
> Taking responsibilities
>
> Joachim has mentioned that it’s good to talk but to change things
> we need to do smth concrete. We need to take the responsibility
> to support ideas with actions.
>
> Online forums with categories.
>
> It’s hard to use the mailing list because the questions on
> different topics are mixed up.
>
> If I’m novice it’s hard to ask for me when I see all the
> stuff about implementing a new feature or parallel execution
> performance. My question seems to be unrelated to the thing.
> But it is related and John Ff sends the reminder on it.
>
> It would be nice to have categories for discussion
>
> Csound for developers
>
> Csound for Newcomers
>
> Csound’s showcases (music, installations, performances)
>
> Csound for DSP engineers
>
> Csound for musicians/performers
>
> Csound and other tech stuff (Mobiles, Game engines, other languages)
>
> Possible solution is Goolge groups.
> But there can be reaction from the users (also Victor L, John F) that like
> to
> use the mailing list (no need to go to a separate site, and check it out).
> But we can explain that google-groups can also be used that way
>
> Stackoverflow tag for Csound
>
> Every language has it so why do we need to ignore this opportunity to help
> people.
>
> Make Cabbage built in UI for Csound. Switching the FLTK with Cabbage
>
> Cabbage is much nicer than FLTK. Can we ship the csound with cabbage
> support?
> Steven says that he wants to separate the csound as audio engine from
> front ends. There is no best front end and we should let the users
> choose the right front end.
>
> Also front ends can ship with Csound not other ways.
>
> CsoundQt built-in editor problem
>
> CsoundQt is such a great thing to use. But there is one thing that
> annoys many users. The CsoundQt forces the musicians to use it’s own editor.
> But there are much better ways to edit the text (Sublime text, Vim, Emacs,
> Idea IntelliJ).
> Can we separate the concepts? Use CsoundQt for it’s great widgets and
> let the musician to use his own favorite editor.
>
> Right now there is no other way than to copy and paste the text
> to CsoundQt. But it becomes harder to edit it.
>
> Issue tracker
>
> There are better ways than Github to do it. Can we use them?
> Do we need it?
>
> trac (http://trac.edgewall.org/) or
>
> Attlassian Confluence JIRA
>
> OSC based Csound API
>
> Can we make explicit support for OSC in the Csound API.
> With support for livecoding. So that we can use OSC to send the
> new instruments to Csound object (not just messages).
>
> Opcodes with named parameters
>
> It would be nice to be able to use named parameters.
> The python things like:
>
> filter(q = 0.5, centerFrequency = 1500, asig)
>
> Namespaces/modules for Csound
>
> The namespaces can help the user safely share their code.
> With modules we can import someone elses instruments.
> There is a Macro solution with include. But it can break the
> code by exposing the global names/tables. So it would be
> great to have the local instrmnets or UDOs that can be safely
> imported to the Csound code.
>
> With modules people can create and distribute they instruments/UDOs.
>
> Csound packages distribution standard
>
> The next question is to define Csound distribution standard (Csound
> packages).
> It’s very complicated question I guess.
> There is a collection of UDOs on the Csound site. It would be nice to be
> able
> to install the Csound functionality in the way Node packages are
> distributed.
> If we have the namespaces and modules in Csound. Is it poossible to create
> a tool like npm in the node or sbt in scala or leiningen in Clojure.
> That gives the user ability to reuse Csound code.
>
> Creating opcodes out of Csd files. Emulating PD-abstractions in Csound
>
> The primary tool of abstraction for Csound is UDO. With UDO’s we can
> create a musical algorithm. It’s like defining a function in the Python with
> def.
> But UDO are restricted. We can use only opcodes in the UDOs.
> We can put into UDO only things that can be put into an instrument
> definition.
>
> But what if we could create a UDO out of complete Csound file.
> Just like we can do it in the PD or Max. Then the UDO can contain
> an Orchestra and the Score. it becomes very powerful audio generator.
> Imagine that you want to use the existing Csound composition in your own.
> Then tyou can use it as an opcode and trigger it in your code.
>
> The Csound already has the proper interface for it.
> We can treat the ins as input and outs as outputs for the UDO.
> That way we don’t need to change anything in the existent Csound code (csd).
> we can use old csd’s. But this limits us with using only signals.
> What if we want to have CSD that takes in ftable as parameter or a string.
>
> Welcome to Montevideo for the next Csound Conference 2017
>
>

> ------------------------------------------------------------------------------
>
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

The chrome implementation runs much faster. The js one does suffer a little in terms of performance.

The chrome implementation runs much faster. The js one does suffer a little in terms of performance.

On 7 Oct 2015 21:05, "Anton Kholomiov" <anton.kholomiov@gmail.com> wrote:

I see. It's cool that it works, but the audio quality is really poor for me. 

2015-10-07 22:49 GMT+03:00 Anders Genell <anders.genell@gmail.com>:

Fantastic!

It runs nicely on my iPhone6!

7 okt 2015 kl. 21:31 skrev Rory Walsh <rorywalsh@EAR.IE>:

This version uses pure JS:
http://eddyc.github.io/CsoundEmscripten/

Give it a moment to load properly.

On 7 October 2015 at 22:15, Anton Kholomiov <anton.kholomiov@gmail.com> wrote:

What is it pure JS that can run Csound (as alternative to pNaCl)? I'm interested to know about it

2015-10-07 20:06 GMT+03:00 Rory Walsh <rorywalsh@ear.ie>:

And I'm investigating the setting up of an online forum for all things Csound. I'll report back when things have progressed a little more.

On 7 October 2015 at 17:00, Steven Yi <stevenyi@gmail.com> wrote:

Hi Anton,

(Moving this to the new user's mailing list from the Sourceforge list)

Thanks very much for posting these here as well as on the issues
tracker, it's incredibly valuable.  I think our next steps for this
should be to figure out some actionable tasks that we can record as
issues in the csound and csound.github.io trackers. From there, we
should be able to refine the ideas as well as work towards addressing
each of them separately.

For the website, I've gotten started on a couple of things to help
make it a bit easier.  I will write about that in a moment in a
separate thread.

Thanks!
steven

On Tue, Oct 6, 2015 at 7:41 AM, Anton Kholomiov
<anton.kholomiov@gmail.com> wrote:
> Topics at the round table ICSC 2015
>
> The main theme for the round table was the attraction of newcomers.
> The Csound is magic and we know it but how can we explain it to others.
>
> There is confusion in learning resources, no showcases, no links to video
> tutorials.
> The thing that can capture the attention is portability. Lots of systems
> can interact with Csound. we can catch the eye of newcomer with it.
>
> terms: the site - is official Csound’s github site
>
> Csound strong points: Portability
>
> I think that to attract the novices we need to advertise the things
> that nobody can do better than Csound. My impression of the conference
> is that right now the killer feature of Csound is the Portability.
> Csound can run anywhere and used with anything.
> iOS, Android, any desktop, web-browser, ipython spread sheets, Haskell,
> Clojure,
> RPi, custom effect processors, creating distributed audio systems
> or environments for collaborative composition — csound can create sound
> for them all. We need to explain it to newcommers and catch their attention
> with it.
> I think it would be nice to have Carusel widget on the web site that
> higlights
> this point. Smth like:
>
> http://audiokit.io/
>
> http://snapframework.com/
>
> Challenge for non-programmer users to update the info on the official Csound
> site.
> We need a guide for non-programmers to submit github pull requests.
>
> Steven said that the site is hosted on github
> and everyone can update it (add news, articles, learning resources).
> But nobody seems to do it.
>
> Tarmo replied that the procedure is unclear to him.
>
> The site is updated with pull requests the procedure
> is pretty obvious for the programmer since the
> git is a modern standard for collaborative coding.
>
> So we need to explain to non-programmers how to use the Github
> pull requests process. DrB mentions that he wants to learn
> by watching the video of it.
>
> Confusion with two sites
>
> We’ve got csounds.com and also github site which is official one.
> Students that learn Csound are often confused with the two sites.
> Where should I learn the Csound?
>
> DrB says that he wants to keep the csounds.com alive since
> he can loose so many information on Csound (17 Gb of Csound resouces, maybe
> I’m wrong with the figure).
> But we can host it on github and make redirects. It’s no that hard
> and eliminates the confusion.
>
> The official site is not so pretty. it has this yet another open-source
> trash feel to it
>
> Can we create a better design for the site? Any web-designers out there?
> Can we reuse by any chance the ICSC 20015 website design
> to make the official site more attractive.
>
> Confusion with Csound releases
>
> It’s not clear for the users where and how to install the Csound.
>
> Showcases of Csound on the site. Csound in Action approach
>
> There were so many cool projects going with Csound
> that I’m unaware of. It would be nice to be able to
> see what people are doing with Csound at the site.
>
> That’s how we can attract the newcomers. That’s how
> they can appreciate the powers of csound.
>
> Learning resources.
>
> For newcomer it’s hard to guess where should (s)he learn
> the Csound. I think it’s better to promote the FLOSS manual
> as the best place to learn (we need to have a link at the official site)
> and also we can provide links to the books or online materials and examples.
>
> Learn by video
>
> Is it possible to create screencasts of what can be done with Csound.
> Actually there is online video tutorial on Csound
>
> http://www.youtube.com/watch?v=KxyBTr0eamQ
>
> Maybe we should link to it on the site or even better to
> integrate to the site. So that users are not distracted by other things
> that they can see on youtube. So that they can see only
> original 12 or more video posts.
>
> We need more musical examples
>
> Sine waves are great but it’s hard to convince the novice with them.
> We need a book or a learning material that can explain the user
> how to create drums, pads, bases, leads with Csound. Smth like
> manuals for Circle and Thor synths
>
> http://www.futureaudioworkshop.com/circle/tutorials/tutorial1
>
> https://www.propellerheads.se/substance/discovering-reason/index.cfm?article=part19&fuseaction=get_article
>
> like csound demystified
>
> Learn by interaction
>
> It would be nice to have the Csound playground.
> Some web-page where users can edit and listen to Csound without
> the need to install compiler.
>
> Steven says that there is such a site. He has created
> a first example and wanted people to collaborate but nobody
> seems to did a thing.
>
> Anton says that’s the thing doesn’t works for him
> I need to install or activate pNaCl which he couldn’t
> figure out how to do it.
>
> The Rory says that there is JavaScript csound without
> any dependencies. Maybe it’s better to move the
> learning material to pure JS solution.
>
> Learn by listening
>
> It would be nice if learning resources could be played online.
> There is a text of the example and near the text we can see the
> play/stop button trigger the playing.
>
> Often users have not so much time to copy things
> into editor, download possible dependent audio files
> to execute the csound example.
>
> It’s nice to supply FLOSS manual and the Reference manual with
> this facility.
>
> It can be done with rendered audio files or it can be done
> with pure JS. The rendered audio requires a lot of routine work (and space
> on the server)
> the pure JS can be done with creating a Csound example widget
> and adding global css info. Maybe it’s better to do it with JS.
>
> Here is an example:
>
> http://www.futureaudioworkshop.com/circle/tutorials/tutorial1
>
> It’s really helps to see the reason (or to see no reason)
> in diving deeper into the thing that is explained.
>
> Taking responsibilities
>
> Joachim has mentioned that it’s good to talk but to change things
> we need to do smth concrete. We need to take the responsibility
> to support ideas with actions.
>
> Online forums with categories.
>
> It’s hard to use the mailing list because the questions on
> different topics are mixed up.
>
> If I’m novice it’s hard to ask for me when I see all the
> stuff about implementing a new feature or parallel execution
> performance. My question seems to be unrelated to the thing.
> But it is related and John Ff sends the reminder on it.
>
> It would be nice to have categories for discussion
>
> Csound for developers
>
> Csound for Newcomers
>
> Csound’s showcases (music, installations, performances)
>
> Csound for DSP engineers
>
> Csound for musicians/performers
>
> Csound and other tech stuff (Mobiles, Game engines, other languages)
>
> Possible solution is Goolge groups.
> But there can be reaction from the users (also Victor L, John F) that like
> to
> use the mailing list (no need to go to a separate site, and check it out).
> But we can explain that google-groups can also be used that way
>
> Stackoverflow tag for Csound
>
> Every language has it so why do we need to ignore this opportunity to help
> people.
>
> Make Cabbage built in UI for Csound. Switching the FLTK with Cabbage
>
> Cabbage is much nicer than FLTK. Can we ship the csound with cabbage
> support?
> Steven says that he wants to separate the csound as audio engine from
> front ends. There is no best front end and we should let the users
> choose the right front end.
>
> Also front ends can ship with Csound not other ways.
>
> CsoundQt built-in editor problem
>
> CsoundQt is such a great thing to use. But there is one thing that
> annoys many users. The CsoundQt forces the musicians to use it’s own editor.
> But there are much better ways to edit the text (Sublime text, Vim, Emacs,
> Idea IntelliJ).
> Can we separate the concepts? Use CsoundQt for it’s great widgets and
> let the musician to use his own favorite editor.
>
> Right now there is no other way than to copy and paste the text
> to CsoundQt. But it becomes harder to edit it.
>
> Issue tracker
>
> There are better ways than Github to do it. Can we use them?
> Do we need it?
>
> trac (http://trac.edgewall.org/) or
>
> Attlassian Confluence JIRA
>
> OSC based Csound API
>
> Can we make explicit support for OSC in the Csound API.
> With support for livecoding. So that we can use OSC to send the
> new instruments to Csound object (not just messages).
>
> Opcodes with named parameters
>
> It would be nice to be able to use named parameters.
> The python things like:
>
> filter(q = 0.5, centerFrequency = 1500, asig)
>
> Namespaces/modules for Csound
>
> The namespaces can help the user safely share their code.
> With modules we can import someone elses instruments.
> There is a Macro solution with include. But it can break the
> code by exposing the global names/tables. So it would be
> great to have the local instrmnets or UDOs that can be safely
> imported to the Csound code.
>
> With modules people can create and distribute they instruments/UDOs.
>
> Csound packages distribution standard
>
> The next question is to define Csound distribution standard (Csound
> packages).
> It’s very complicated question I guess.
> There is a collection of UDOs on the Csound site. It would be nice to be
> able
> to install the Csound functionality in the way Node packages are
> distributed.
> If we have the namespaces and modules in Csound. Is it poossible to create
> a tool like npm in the node or sbt in scala or leiningen in Clojure.
> That gives the user ability to reuse Csound code.
>
> Creating opcodes out of Csd files. Emulating PD-abstractions in Csound
>
> The primary tool of abstraction for Csound is UDO. With UDO’s we can
> create a musical algorithm. It’s like defining a function in the Python with
> def.
> But UDO are restricted. We can use only opcodes in the UDOs.
> We can put into UDO only things that can be put into an instrument
> definition.
>
> But what if we could create a UDO out of complete Csound file.
> Just like we can do it in the PD or Max. Then the UDO can contain
> an Orchestra and the Score. it becomes very powerful audio generator.
> Imagine that you want to use the existing Csound composition in your own.
> Then tyou can use it as an opcode and trigger it in your code.
>
> The Csound already has the proper interface for it.
> We can treat the ins as input and outs as outputs for the UDO.
> That way we don’t need to change anything in the existent Csound code (csd).
> we can use old csd’s. But this limits us with using only signals.
> What if we want to have CSD that takes in ftable as parameter or a string.
>
> Welcome to Montevideo for the next Csound Conference 2017
>
>

> ------------------------------------------------------------------------------
>
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>