Csound 6 Development Plan
Locked
 
|
Hi All,
I've started a Wiki page for Csound 6 development. It has a mindmap I did some months ago from just a couple weeks after the Csound Conference, and has some ideas I had. Please check it out and feel free to add comments and/or update sections. https://sourceforge.net/apps/mediawiki/csound/index.php?title=Csound_6_Development_Plan Thanks! steven ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Csound 6 Development Plan
|
I cannot edit the page, even after logging in to SourceForge. Please,
fix this. The following error is returned: You do not have permission to edit this page, for the following reason: The action you have requested is limited to users in one of the groups: editor, admin. Regards, Mike On Sat, Feb 11, 2012 at 6:47 PM, Steven Yi <[hidden email]> wrote: > Hi All, > > I've started a Wiki page for Csound 6 development. It has a mindmap I > did some months ago from just a couple weeks after the Csound > Conference, and has some ideas I had. Please check it out and feel > free to add comments and/or update sections. > > https://sourceforge.net/apps/mediawiki/csound/index.php?title=Csound_6_Development_Plan > > Thanks! > steven > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Hi Michael,
I'm not sure how to handle this. Andres or John: Any ideas? Thanks! steven On Sun, Feb 12, 2012 at 1:08 AM, Michael Gogins <[hidden email]> wrote: > I cannot edit the page, even after logging in to SourceForge. Please, > fix this. The following error is returned: > > You do not have permission to edit this page, for the following reason: > The action you have requested is limited to users in one of the > groups: editor, admin. > > Regards, > Mike > > On Sat, Feb 11, 2012 at 6:47 PM, Steven Yi <[hidden email]> wrote: >> Hi All, >> >> I've started a Wiki page for Csound 6 development. It has a mindmap I >> did some months ago from just a couple weeks after the Csound >> Conference, and has some ideas I had. Please check it out and feel >> free to add comments and/or update sections. >> >> https://sourceforge.net/apps/mediawiki/csound/index.php?title=Csound_6_Development_Plan >> >> Thanks! >> steven >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Csound-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > -- > Michael Gogins > Irreducible Productions > http://www.michael-gogins.com > Michael dot Gogins at gmail dot com > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Hi Michael,
I think I figured it out. Could you try now to see if you can make edits? Thanks! steven On Sun, Feb 12, 2012 at 12:24 PM, Steven Yi <[hidden email]> wrote: > Hi Michael, > > I'm not sure how to handle this. Andres or John: Any ideas? > > Thanks! > steven > > On Sun, Feb 12, 2012 at 1:08 AM, Michael Gogins > <[hidden email]> wrote: >> I cannot edit the page, even after logging in to SourceForge. Please, >> fix this. The following error is returned: >> >> You do not have permission to edit this page, for the following reason: >> The action you have requested is limited to users in one of the >> groups: editor, admin. >> >> Regards, >> Mike >> >> On Sat, Feb 11, 2012 at 6:47 PM, Steven Yi <[hidden email]> wrote: >>> Hi All, >>> >>> I've started a Wiki page for Csound 6 development. It has a mindmap I >>> did some months ago from just a couple weeks after the Csound >>> Conference, and has some ideas I had. Please check it out and feel >>> free to add comments and/or update sections. >>> >>> https://sourceforge.net/apps/mediawiki/csound/index.php?title=Csound_6_Development_Plan >>> >>> Thanks! >>> steven >>> >>> ------------------------------------------------------------------------------ >>> Virtualization & Cloud Management Using Capacity Planning >>> Cloud computing makes use of virtualization - but cloud computing >>> also focuses on allowing computing to be delivered as a service. >>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>> _______________________________________________ >>> Csound-devel mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> >> -- >> Michael Gogins >> Irreducible Productions >> http://www.michael-gogins.com >> Michael dot Gogins at gmail dot com >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Csound-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Csound 6 Development Plan
|
In reply to this post by Steven Yi
I do not mean to be picky here, but what you call 'Use cases' are actually 'Requirements'
Use cases are a UML diagram showing the interaction between a user and a program... my 2 cents. Richard |
|
|
I'm sorry, but that is not correct. Use cases are not UML, though UML
can be, and is often, used to express a use case (though, none of the companies I've worked for used UML for use case capturing...). In the use case section of this document, the "developer" IS the "user interacting with the program." Csound 5 opened up the roles for Csound to include the traditional user coding in Csound orc/sco, as well as adding developers who are using Csound as a synthesis engine/library. Csound 6 planning so far is primarily about the developer role, and how to accomodate their use cases for how they use Csound as an engine. There has not been much concrete discussion yet on traditional user changes, though some general discussion on language changes have come and gone. We will need to continue to expand the document for both roles. I have added a note to the wiki to clarify that the use cases and roles they are written for. Thanks, steven On Sun, Feb 12, 2012 at 2:40 PM, zappfinger <[hidden email]> wrote: > I do not mean to be picky here, but what you call 'Use cases' are actually > 'Requirements' > Use cases are a UML diagram showing the interaction between a user and a > program... > > my 2 cents. > > Richard > > -- > View this message in context: http://csound.1045644.n5.nabble.com/Csound-6-Development-Plan-tp5475930p5476675.html > Sent from the Csound - Dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Csound 6 Development Plan
|
|
Thanks, I have made some edits to the pages now.
Best, Mike On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi <[hidden email]> wrote: > I'm sorry, but that is not correct. Use cases are not UML, though UML > can be, and is often, used to express a use case (though, none of the > companies I've worked for used UML for use case capturing...). In the > use case section of this document, the "developer" IS the "user > interacting with the program." > > Csound 5 opened up the roles for Csound to include the traditional > user coding in Csound orc/sco, as well as adding developers who are > using Csound as a synthesis engine/library. Csound 6 planning so far > is primarily about the developer role, and how to accomodate their use > cases for how they use Csound as an engine. There has not been much > concrete discussion yet on traditional user changes, though some > general discussion on language changes have come and gone. > > We will need to continue to expand the document for both roles. I > have added a note to the wiki to clarify that the use cases and roles > they are written for. > > Thanks, > steven > > On Sun, Feb 12, 2012 at 2:40 PM, zappfinger <[hidden email]> wrote: >> I do not mean to be picky here, but what you call 'Use cases' are actually >> 'Requirements' >> Use cases are a UML diagram showing the interaction between a user and a >> program... >> >> my 2 cents. >> >> Richard >> >> -- >> View this message in context: http://csound.1045644.n5.nabble.com/Csound-6-Development-Plan-tp5475930p5476675.html >> Sent from the Csound - Dev mailing list archive at Nabble.com. >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Csound-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Hi Michael,
Regarding your addition, is the goal to make Instruments as plugins, much like opcodes can be read in at runtime? The one thing about loading an instrument at runtime, is that current Csound ORC both defines the instrument as well as assigns it to an index or name. We'd have something other than instr to do something like: loadinstr 1, "myinstrument.instr" (some other extension). I'm curious though, this kind of thing seems to reduce the long-term viability of a musical work by introducing binary dependencies. I guess I wouldn't use it myself, but what advantages do you see it giving? I can understand the use of compiled orchestras as a caching mechanism to speed up load times (sort of like python's pyc files versus py files), though. Thanks! steven On Sun, Feb 12, 2012 at 4:44 PM, Michael Gogins <[hidden email]> wrote: > Thanks, I have made some edits to the pages now. > > Best, > Mike > > On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi <[hidden email]> wrote: >> I'm sorry, but that is not correct. Use cases are not UML, though UML >> can be, and is often, used to express a use case (though, none of the >> companies I've worked for used UML for use case capturing...). In the >> use case section of this document, the "developer" IS the "user >> interacting with the program." >> >> Csound 5 opened up the roles for Csound to include the traditional >> user coding in Csound orc/sco, as well as adding developers who are >> using Csound as a synthesis engine/library. Csound 6 planning so far >> is primarily about the developer role, and how to accomodate their use >> cases for how they use Csound as an engine. There has not been much >> concrete discussion yet on traditional user changes, though some >> general discussion on language changes have come and gone. >> >> We will need to continue to expand the document for both roles. I >> have added a note to the wiki to clarify that the use cases and roles >> they are written for. >> >> Thanks, >> steven >> >> On Sun, Feb 12, 2012 at 2:40 PM, zappfinger <[hidden email]> wrote: >>> I do not mean to be picky here, but what you call 'Use cases' are actually >>> 'Requirements' >>> Use cases are a UML diagram showing the interaction between a user and a >>> program... >>> >>> my 2 cents. >>> >>> Richard >>> >>> -- >>> View this message in context: http://csound.1045644.n5.nabble.com/Csound-6-Development-Plan-tp5475930p5476675.html >>> Sent from the Csound - Dev mailing list archive at Nabble.com. >>> >>> ------------------------------------------------------------------------------ >>> Virtualization & Cloud Management Using Capacity Planning >>> Cloud computing makes use of virtualization - but cloud computing >>> also focuses on allowing computing to be delivered as a service. >>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>> _______________________________________________ >>> Csound-devel mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Csound-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > -- > Michael Gogins > Irreducible Productions > http://www.michael-gogins.com > Michael dot Gogins at gmail dot com > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Csound 6 Development Plan
|
|
Thanks for your response.
Yes, the goal is instrument plugins, I should of thought of that term myself. I don't think a change in language is required, if the instr name is not found Csound can look for a plugin before producing an error. There are two reasons I would like to have instrument plugins: (1) It is easier to write synthesis and DSP code in C++ than in orchestra code for some people, including me. I already had some experience doing this with cmix, where it is the only way to write instrument code, and I actually prefer this. (2) There would be no binary obsolescence if the piece, as a whole, were written in C++ as a single C++ source code file including instrument definitions. Such a piece would run Csound via the API and automatically register its plugin instruments with Csound the same way it is possible to register plugin opcodes at run time with the API. In general, there is a constant battle between musical usability and software engineering complexity in our work. I see the ability to write all aspects of a piece, including score generating code, user interface, and synthesis, in a single language as being a significant decrease in software engineering complexity and an increase in musical usability, especially if that language is standard, freely available, and highly efficient, as C++ is. This is a path I am also exploring via Lua and LuaJIT. But in the best case here I still end up with 2 languages, Lua and Csound orchestra language, with fragments of C also for passing data back and forth. Of course I need to keep Csound with its vast capabilities and huge library of code and pieces in this picture... I don't want to throw out the baby with the bath water... Best, Mike On Sun, Feb 12, 2012 at 11:54 AM, Steven Yi <[hidden email]> wrote: > Hi Michael, > > Regarding your addition, is the goal to make Instruments as plugins, > much like opcodes can be read in at runtime? The one thing about > loading an instrument at runtime, is that current Csound ORC both > defines the instrument as well as assigns it to an index or name. > We'd have something other than instr to do something like: > > loadinstr 1, "myinstrument.instr" > > (some other extension). > > I'm curious though, this kind of thing seems to reduce the long-term > viability of a musical work by introducing binary dependencies. I > guess I wouldn't use it myself, but what advantages do you see it > giving? I can understand the use of compiled orchestras as a caching > mechanism to speed up load times (sort of like python's pyc files > versus py files), though. > > Thanks! > steven > > > > On Sun, Feb 12, 2012 at 4:44 PM, Michael Gogins > <[hidden email]> wrote: >> Thanks, I have made some edits to the pages now. >> >> Best, >> Mike >> >> On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi <[hidden email]> wrote: >>> I'm sorry, but that is not correct. Use cases are not UML, though UML >>> can be, and is often, used to express a use case (though, none of the >>> companies I've worked for used UML for use case capturing...). In the >>> use case section of this document, the "developer" IS the "user >>> interacting with the program." >>> >>> Csound 5 opened up the roles for Csound to include the traditional >>> user coding in Csound orc/sco, as well as adding developers who are >>> using Csound as a synthesis engine/library. Csound 6 planning so far >>> is primarily about the developer role, and how to accomodate their use >>> cases for how they use Csound as an engine. There has not been much >>> concrete discussion yet on traditional user changes, though some >>> general discussion on language changes have come and gone. >>> >>> We will need to continue to expand the document for both roles. I >>> have added a note to the wiki to clarify that the use cases and roles >>> they are written for. >>> >>> Thanks, >>> steven >>> >>> On Sun, Feb 12, 2012 at 2:40 PM, zappfinger <[hidden email]> wrote: >>>> I do not mean to be picky here, but what you call 'Use cases' are actually >>>> 'Requirements' >>>> Use cases are a UML diagram showing the interaction between a user and a >>>> program... >>>> >>>> my 2 cents. >>>> >>>> Richard >>>> >>>> -- >>>> View this message in context: http://csound.1045644.n5.nabble.com/Csound-6-Development-Plan-tp5475930p5476675.html >>>> Sent from the Csound - Dev mailing list archive at Nabble.com. >>>> >>>> ------------------------------------------------------------------------------ >>>> Virtualization & Cloud Management Using Capacity Planning >>>> Cloud computing makes use of virtualization - but cloud computing >>>> also focuses on allowing computing to be delivered as a service. >>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> [hidden email] >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> ------------------------------------------------------------------------------ >>> Virtualization & Cloud Management Using Capacity Planning >>> Cloud computing makes use of virtualization - but cloud computing >>> also focuses on allowing computing to be delivered as a service. >>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>> _______________________________________________ >>> Csound-devel mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> >> -- >> Michael Gogins >> Irreducible Productions >> http://www.michael-gogins.com >> Michael dot Gogins at gmail dot com >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Csound-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Hi Michael,
I think there's a tremendous value in having things within Csound Code, particularly for history and learning, as well as later extension. It's a reason that I never spent much time with things like LADSPA and VST. Something I'd prefer in this case is that we have the capacity to do it, but not necessarily promote it. By this I'm thinking we can make instruments more like an interface rather than a concrete class. If we do this, we would need to modify the performance loop. The idea is that an instrument would have methods like (in psuedo-code): class Instrument { Note addNote(); void removeNote(Note n); MYFLT* performKsmps(); } Instruments would then be responsible for keeping track of active instances (this is already the case with current csound, but worth pointing out for new instruments). The main performance loop kperf would need modification to not handle going through each instrument's opcode list itself, but just delegate to the classes perform function. So the loop would just iterate through instrument and call perform instead of doing the performing. Note the above performKsmps returns a MYFLT*. This was another thing I remembered discussing with Victor, that instrument no longer write to global SPOUT, but rather write to a per-instance spout. The Instrument performKsmps then would then collect and mix the instance spouts, and csound's performKsmps would in turn collect and mix instrument spouts. This should then make things a little easier for parallelization. To address your concern, Instruments could then be subclassed within C/C++/other host language. They would need to handle the above methods. I think we could do it in a C way by doing: struct InstrumentDefinition { Note* (*addNote)(int argc, pfield[] pfields, map optionalArgs); void (*removeNote)(Note*); MYLFT* (*performKsmps)(); }; My one concern though is performance due to function pointers. (I had a conversation with John Lato last week and he saw some things that implied that the function pointers used with how the opcode chain is built may take longer than he would expect). However, I think this would do the trick, yes? Thanks! steven On Sun, Feb 12, 2012 at 6:49 PM, Michael Gogins <[hidden email]> wrote: > Thanks for your response. > > Yes, the goal is instrument plugins, I should of thought of that term myself. > > I don't think a change in language is required, if the instr name is > not found Csound can look for a plugin before producing an error. > > There are two reasons I would like to have instrument plugins: > > (1) It is easier to write synthesis and DSP code in C++ than in > orchestra code for some people, including me. I already had some > experience doing this with cmix, where it is the only way to write > instrument code, and I actually prefer this. > > (2) There would be no binary obsolescence if the piece, as a whole, > were written in C++ as a single C++ source code file including > instrument definitions. Such a piece would run Csound via the API and > automatically register its plugin instruments with Csound the same way > it is possible to register plugin opcodes at run time with the API. > > In general, there is a constant battle between musical usability and > software engineering complexity in our work. I see the ability to > write all aspects of a piece, including score generating code, user > interface, and synthesis, in a single language as being a significant > decrease in software engineering complexity and an increase in musical > usability, especially if that language is standard, freely available, > and highly efficient, as C++ is. > > This is a path I am also exploring via Lua and LuaJIT. But in the best > case here I still end up with 2 languages, Lua and Csound orchestra > language, with fragments of C also for passing data back and forth. > > Of course I need to keep Csound with its vast capabilities and huge > library of code and pieces in this picture... I don't want to throw > out the baby with the bath water... > > Best, > Mike > > On Sun, Feb 12, 2012 at 11:54 AM, Steven Yi <[hidden email]> wrote: >> Hi Michael, >> >> Regarding your addition, is the goal to make Instruments as plugins, >> much like opcodes can be read in at runtime? The one thing about >> loading an instrument at runtime, is that current Csound ORC both >> defines the instrument as well as assigns it to an index or name. >> We'd have something other than instr to do something like: >> >> loadinstr 1, "myinstrument.instr" >> >> (some other extension). >> >> I'm curious though, this kind of thing seems to reduce the long-term >> viability of a musical work by introducing binary dependencies. I >> guess I wouldn't use it myself, but what advantages do you see it >> giving? I can understand the use of compiled orchestras as a caching >> mechanism to speed up load times (sort of like python's pyc files >> versus py files), though. >> >> Thanks! >> steven >> >> >> >> On Sun, Feb 12, 2012 at 4:44 PM, Michael Gogins >> <[hidden email]> wrote: >>> Thanks, I have made some edits to the pages now. >>> >>> Best, >>> Mike >>> >>> On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi <[hidden email]> wrote: >>>> I'm sorry, but that is not correct. Use cases are not UML, though UML >>>> can be, and is often, used to express a use case (though, none of the >>>> companies I've worked for used UML for use case capturing...). In the >>>> use case section of this document, the "developer" IS the "user >>>> interacting with the program." >>>> >>>> Csound 5 opened up the roles for Csound to include the traditional >>>> user coding in Csound orc/sco, as well as adding developers who are >>>> using Csound as a synthesis engine/library. Csound 6 planning so far >>>> is primarily about the developer role, and how to accomodate their use >>>> cases for how they use Csound as an engine. There has not been much >>>> concrete discussion yet on traditional user changes, though some >>>> general discussion on language changes have come and gone. >>>> >>>> We will need to continue to expand the document for both roles. I >>>> have added a note to the wiki to clarify that the use cases and roles >>>> they are written for. >>>> >>>> Thanks, >>>> steven >>>> >>>> On Sun, Feb 12, 2012 at 2:40 PM, zappfinger <[hidden email]> wrote: >>>>> I do not mean to be picky here, but what you call 'Use cases' are actually >>>>> 'Requirements' >>>>> Use cases are a UML diagram showing the interaction between a user and a >>>>> program... >>>>> >>>>> my 2 cents. >>>>> >>>>> Richard >>>>> >>>>> -- >>>>> View this message in context: http://csound.1045644.n5.nabble.com/Csound-6-Development-Plan-tp5475930p5476675.html >>>>> Sent from the Csound - Dev mailing list archive at Nabble.com. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Virtualization & Cloud Management Using Capacity Planning >>>>> Cloud computing makes use of virtualization - but cloud computing >>>>> also focuses on allowing computing to be delivered as a service. >>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> [hidden email] >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> ------------------------------------------------------------------------------ >>>> Virtualization & Cloud Management Using Capacity Planning >>>> Cloud computing makes use of virtualization - but cloud computing >>>> also focuses on allowing computing to be delivered as a service. >>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> [hidden email] >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> >>> >>> -- >>> Michael Gogins >>> Irreducible Productions >>> http://www.michael-gogins.com >>> Michael dot Gogins at gmail dot com >>> >>> ------------------------------------------------------------------------------ >>> Virtualization & Cloud Management Using Capacity Planning >>> Cloud computing makes use of virtualization - but cloud computing >>> also focuses on allowing computing to be delivered as a service. >>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>> _______________________________________________ >>> Csound-devel mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Csound-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > -- > Michael Gogins > Irreducible Productions > http://www.michael-gogins.com > Michael dot Gogins at gmail dot com > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Csound 6 Development Plan
|
|
First, I don't think that function pointers will incur any particular
overhead with respect to all that is already going on. This is based on professional experience. A dynamic function pointer should have the same performance as a C++ virtual method call resolved at run time, that is, one additional pointer dereference on top of the function call setup. This should be negligible in practice. If in doubt, measure it. Second, what you envision is slightly different from what I have in mind, which is more like hooks into the runtime graph that the user (or Csound itself if it detects instrument plugins) would set. There would be one hook that Csound would call to create a new instrument instance, and another call to actually run the instrument. It would be up to the instrument instance itself, unlike as in your example, whether to write to spout (which would be added to using the Csound API from within the instrument). There might even be an Instrument base class derived from the existing instrument template structure, for access to pfields etc. by the C++ or C instrument code. Hope this is a bit clearer, Mike On Sun, Feb 12, 2012 at 2:14 PM, Steven Yi <[hidden email]> wrote: > Hi Michael, > > I think there's a tremendous value in having things within Csound > Code, particularly for history and learning, as well as later > extension. It's a reason that I never spent much time with things > like LADSPA and VST. Something I'd prefer in this case is that we > have the capacity to do it, but not necessarily promote it. By this > I'm thinking we can make instruments more like an interface rather > than a concrete class. > > If we do this, we would need to modify the performance loop. The idea > is that an instrument would have methods like (in psuedo-code): > > class Instrument { > > Note addNote(); > void removeNote(Note n); > MYFLT* performKsmps(); > } > > Instruments would then be responsible for keeping track of active > instances (this is already the case with current csound, but worth > pointing out for new instruments). The main performance loop kperf > would need modification to not handle going through each instrument's > opcode list itself, but just delegate to the classes perform function. > So the loop would just iterate through instrument and call perform > instead of doing the performing. > > Note the above performKsmps returns a MYFLT*. This was another thing > I remembered discussing with Victor, that instrument no longer write > to global SPOUT, but rather write to a per-instance spout. The > Instrument performKsmps then would then collect and mix the instance > spouts, and csound's performKsmps would in turn collect and mix > instrument spouts. This should then make things a little easier for > parallelization. > > To address your concern, Instruments could then be subclassed within > C/C++/other host language. They would need to handle the above > methods. I think we could do it in a C way by doing: > > struct InstrumentDefinition { > Note* (*addNote)(int argc, pfield[] pfields, map optionalArgs); > void (*removeNote)(Note*); > MYLFT* (*performKsmps)(); > }; > > My one concern though is performance due to function pointers. (I had > a conversation with John Lato last week and he saw some things that > implied that the function pointers used with how the opcode chain is > built may take longer than he would expect). However, I think this > would do the trick, yes? > > Thanks! > steven > > > > On Sun, Feb 12, 2012 at 6:49 PM, Michael Gogins > <[hidden email]> wrote: >> Thanks for your response. >> >> Yes, the goal is instrument plugins, I should of thought of that term myself. >> >> I don't think a change in language is required, if the instr name is >> not found Csound can look for a plugin before producing an error. >> >> There are two reasons I would like to have instrument plugins: >> >> (1) It is easier to write synthesis and DSP code in C++ than in >> orchestra code for some people, including me. I already had some >> experience doing this with cmix, where it is the only way to write >> instrument code, and I actually prefer this. >> >> (2) There would be no binary obsolescence if the piece, as a whole, >> were written in C++ as a single C++ source code file including >> instrument definitions. Such a piece would run Csound via the API and >> automatically register its plugin instruments with Csound the same way >> it is possible to register plugin opcodes at run time with the API. >> >> In general, there is a constant battle between musical usability and >> software engineering complexity in our work. I see the ability to >> write all aspects of a piece, including score generating code, user >> interface, and synthesis, in a single language as being a significant >> decrease in software engineering complexity and an increase in musical >> usability, especially if that language is standard, freely available, >> and highly efficient, as C++ is. >> >> This is a path I am also exploring via Lua and LuaJIT. But in the best >> case here I still end up with 2 languages, Lua and Csound orchestra >> language, with fragments of C also for passing data back and forth. >> >> Of course I need to keep Csound with its vast capabilities and huge >> library of code and pieces in this picture... I don't want to throw >> out the baby with the bath water... >> >> Best, >> Mike >> >> On Sun, Feb 12, 2012 at 11:54 AM, Steven Yi <[hidden email]> wrote: >>> Hi Michael, >>> >>> Regarding your addition, is the goal to make Instruments as plugins, >>> much like opcodes can be read in at runtime? The one thing about >>> loading an instrument at runtime, is that current Csound ORC both >>> defines the instrument as well as assigns it to an index or name. >>> We'd have something other than instr to do something like: >>> >>> loadinstr 1, "myinstrument.instr" >>> >>> (some other extension). >>> >>> I'm curious though, this kind of thing seems to reduce the long-term >>> viability of a musical work by introducing binary dependencies. I >>> guess I wouldn't use it myself, but what advantages do you see it >>> giving? I can understand the use of compiled orchestras as a caching >>> mechanism to speed up load times (sort of like python's pyc files >>> versus py files), though. >>> >>> Thanks! >>> steven >>> >>> >>> >>> On Sun, Feb 12, 2012 at 4:44 PM, Michael Gogins >>> <[hidden email]> wrote: >>>> Thanks, I have made some edits to the pages now. >>>> >>>> Best, >>>> Mike >>>> >>>> On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi <[hidden email]> wrote: >>>>> I'm sorry, but that is not correct. Use cases are not UML, though UML >>>>> can be, and is often, used to express a use case (though, none of the >>>>> companies I've worked for used UML for use case capturing...). In the >>>>> use case section of this document, the "developer" IS the "user >>>>> interacting with the program." >>>>> >>>>> Csound 5 opened up the roles for Csound to include the traditional >>>>> user coding in Csound orc/sco, as well as adding developers who are >>>>> using Csound as a synthesis engine/library. Csound 6 planning so far >>>>> is primarily about the developer role, and how to accomodate their use >>>>> cases for how they use Csound as an engine. There has not been much >>>>> concrete discussion yet on traditional user changes, though some >>>>> general discussion on language changes have come and gone. >>>>> >>>>> We will need to continue to expand the document for both roles. I >>>>> have added a note to the wiki to clarify that the use cases and roles >>>>> they are written for. >>>>> >>>>> Thanks, >>>>> steven >>>>> >>>>> On Sun, Feb 12, 2012 at 2:40 PM, zappfinger <[hidden email]> wrote: >>>>>> I do not mean to be picky here, but what you call 'Use cases' are actually >>>>>> 'Requirements' >>>>>> Use cases are a UML diagram showing the interaction between a user and a >>>>>> program... >>>>>> >>>>>> my 2 cents. >>>>>> >>>>>> Richard >>>>>> >>>>>> -- >>>>>> View this message in context: http://csound.1045644.n5.nabble.com/Csound-6-Development-Plan-tp5475930p5476675.html >>>>>> Sent from the Csound - Dev mailing list archive at Nabble.com. >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Virtualization & Cloud Management Using Capacity Planning >>>>>> Cloud computing makes use of virtualization - but cloud computing >>>>>> also focuses on allowing computing to be delivered as a service. >>>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>>> _______________________________________________ >>>>>> Csound-devel mailing list >>>>>> [hidden email] >>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Virtualization & Cloud Management Using Capacity Planning >>>>> Cloud computing makes use of virtualization - but cloud computing >>>>> also focuses on allowing computing to be delivered as a service. >>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> [hidden email] >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> >>>> >>>> -- >>>> Michael Gogins >>>> Irreducible Productions >>>> http://www.michael-gogins.com >>>> Michael dot Gogins at gmail dot com >>>> >>>> ------------------------------------------------------------------------------ >>>> Virtualization & Cloud Management Using Capacity Planning >>>> Cloud computing makes use of virtualization - but cloud computing >>>> also focuses on allowing computing to be delivered as a service. >>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> [hidden email] >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> ------------------------------------------------------------------------------ >>> Virtualization & Cloud Management Using Capacity Planning >>> Cloud computing makes use of virtualization - but cloud computing >>> also focuses on allowing computing to be delivered as a service. >>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>> _______________________________________________ >>> Csound-devel mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> >> -- >> Michael Gogins >> Irreducible Productions >> http://www.michael-gogins.com >> Michael dot Gogins at gmail dot com >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Csound-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Csound 6 Development Plan
|
In reply to this post by Steven Yi
When you'll have figured it out can you tell rhe resr of use what you have
decided for csound? I realise I am an older generation but I cannot see wiki (watever they are) as a helpful component of thought. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Csound 6 Development Plan
|
How would you like to do this? How could we be more helpful? Maybe we should use the methods that all of us understand, not just some.
Victor On 12 Feb 2012, at 22:30, John ffitch wrote: > When you'll have figured it out can you tell rhe resr of use what you have > decided for csound? I realise I am an older generation but I cannot see > wiki (watever they are) as a helpful component of thought. > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
I'm fine to switch to some other format, just find the wiki
convenient. We can add a txt file to the Csound 6 repo if that works for everyone. On Sun, Feb 12, 2012 at 10:43 PM, Victor Lazzarini <[hidden email]> wrote: > How would you like to do this? How could we be more helpful? Maybe we should use the methods that all of us understand, not just some. > > Victor > On 12 Feb 2012, at 22:30, John ffitch wrote: > >> When you'll have figured it out can you tell rhe resr of use what you have >> decided for csound? I realise I am an older generation but I cannot see >> wiki (watever they are) as a helpful component of thought. >> >> >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Csound-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > Dr Victor Lazzarini > Senior Lecturer > Dept. of Music > NUI Maynooth Ireland > tel.: +353 1 708 3545 > Victor dot Lazzarini AT nuim dot ie > > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Csound 6 Development Plan
|
On Sun, Feb 12, 2012 at 3:04 PM, Steven Yi <[hidden email]> wrote:
I'm fine to switch to some other format, just find the wiki The wiki has the advantage of being browsable by those who have not (yet) checked out code, and being independent of version snapshots. Has anyone considered using something like Redmine? We love it here (www.xornot.com). It's Ruby-On-Rails based, very extendable, free, and just all around a fantastic software development management tool. It has built in facilities for ticket systems, wiki's, journal, calendar, developer news, cross project tickets, etc. Integrating with git is easy.
Iain ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
Re: Csound 6 Development Plan
|
|
John, by what means would you prefer to conduct this discussion?
Best, Mike On Sun, Feb 12, 2012 at 6:23 PM, Iain Duncan <[hidden email]> wrote: > On Sun, Feb 12, 2012 at 3:04 PM, Steven Yi <[hidden email]> wrote: >> >> I'm fine to switch to some other format, just find the wiki >> convenient. We can add a txt file to the Csound 6 repo if that works >> for everyone. > > > The wiki has the advantage of being browsable by those who have not (yet) > checked out code, and being independent of version snapshots. > > Has anyone considered using something like Redmine? We love it here > (www.xornot.com). It's Ruby-On-Rails based, very extendable, free, and just > all around a fantastic software development management tool. It has built in > facilities for ticket systems, wiki's, journal, calendar, developer news, > cross project tickets, etc. Integrating with git is easy. > > Iain > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
In reply to this post by Michael Gogins-2
Hi Michael,
I did some reading up and apparently the main issue with function pointers is not the call so much as what compiler optimizations are possible versus a direct call. Ultimately though, yes, we'd have to measure. I do think we do need to move to changing spout access. It's just better design IMO to grab the values from the instrument rather than have it push to a global resource. I don't see it as something that would prevent your use case though. Also, I think what I mentioned in the previous email looks not too different than what you mentioned, as the addNote would be what instantiates an instance, performKsmps would be what runs the instance, and removeNote would end the instance. A C++ base class could certainly be created that would come with Csound that has default instantiation and instance queue code. I think the design is simple yet flexible enough to handle the requirements. The issue I have with setting some kind of hook on Csound is that it is not generic enough. I find the same issue with the yield callback, and consequently made similar changes to allow adding multiple callback-able objects to a CsoundObj instance in iOS/Android (hopefully should be out soon). In essence though, I think what we're talking about is fairly similar, except that what I'm proposing is what you're proposing but encapsulated within this InstrumentDefinition, rather than on Csound itself. Did I understand your thought correctly? Thanks! steven On Sun, Feb 12, 2012 at 7:58 PM, Michael Gogins <[hidden email]> wrote: > First, I don't think that function pointers will incur any particular > overhead with respect to all that is already going on. This is based > on professional experience. A dynamic function pointer should have the > same performance as a C++ virtual method call resolved at run time, > that is, one additional pointer dereference on top of the function > call setup. This should be negligible in practice. If in doubt, > measure it. > > Second, what you envision is slightly different from what I have in > mind, which is more like hooks into the runtime graph that the user > (or Csound itself if it detects instrument plugins) would set. There > would be one hook that Csound would call to create a new instrument > instance, and another call to actually run the instrument. It would be > up to the instrument instance itself, unlike as in your example, > whether to write to spout (which would be added to using the Csound > API from within the instrument). > > There might even be an Instrument base class derived from the existing > instrument template structure, for access to pfields etc. by the C++ > or C instrument code. > > Hope this is a bit clearer, > Mike > > > On Sun, Feb 12, 2012 at 2:14 PM, Steven Yi <[hidden email]> wrote: >> Hi Michael, >> >> I think there's a tremendous value in having things within Csound >> Code, particularly for history and learning, as well as later >> extension. It's a reason that I never spent much time with things >> like LADSPA and VST. Something I'd prefer in this case is that we >> have the capacity to do it, but not necessarily promote it. By this >> I'm thinking we can make instruments more like an interface rather >> than a concrete class. >> >> If we do this, we would need to modify the performance loop. The idea >> is that an instrument would have methods like (in psuedo-code): >> >> class Instrument { >> >> Note addNote(); >> void removeNote(Note n); >> MYFLT* performKsmps(); >> } >> >> Instruments would then be responsible for keeping track of active >> instances (this is already the case with current csound, but worth >> pointing out for new instruments). The main performance loop kperf >> would need modification to not handle going through each instrument's >> opcode list itself, but just delegate to the classes perform function. >> So the loop would just iterate through instrument and call perform >> instead of doing the performing. >> >> Note the above performKsmps returns a MYFLT*. This was another thing >> I remembered discussing with Victor, that instrument no longer write >> to global SPOUT, but rather write to a per-instance spout. The >> Instrument performKsmps then would then collect and mix the instance >> spouts, and csound's performKsmps would in turn collect and mix >> instrument spouts. This should then make things a little easier for >> parallelization. >> >> To address your concern, Instruments could then be subclassed within >> C/C++/other host language. They would need to handle the above >> methods. I think we could do it in a C way by doing: >> >> struct InstrumentDefinition { >> Note* (*addNote)(int argc, pfield[] pfields, map optionalArgs); >> void (*removeNote)(Note*); >> MYLFT* (*performKsmps)(); >> }; >> >> My one concern though is performance due to function pointers. (I had >> a conversation with John Lato last week and he saw some things that >> implied that the function pointers used with how the opcode chain is >> built may take longer than he would expect). However, I think this >> would do the trick, yes? >> >> Thanks! >> steven >> >> >> >> On Sun, Feb 12, 2012 at 6:49 PM, Michael Gogins >> <[hidden email]> wrote: >>> Thanks for your response. >>> >>> Yes, the goal is instrument plugins, I should of thought of that term myself. >>> >>> I don't think a change in language is required, if the instr name is >>> not found Csound can look for a plugin before producing an error. >>> >>> There are two reasons I would like to have instrument plugins: >>> >>> (1) It is easier to write synthesis and DSP code in C++ than in >>> orchestra code for some people, including me. I already had some >>> experience doing this with cmix, where it is the only way to write >>> instrument code, and I actually prefer this. >>> >>> (2) There would be no binary obsolescence if the piece, as a whole, >>> were written in C++ as a single C++ source code file including >>> instrument definitions. Such a piece would run Csound via the API and >>> automatically register its plugin instruments with Csound the same way >>> it is possible to register plugin opcodes at run time with the API. >>> >>> In general, there is a constant battle between musical usability and >>> software engineering complexity in our work. I see the ability to >>> write all aspects of a piece, including score generating code, user >>> interface, and synthesis, in a single language as being a significant >>> decrease in software engineering complexity and an increase in musical >>> usability, especially if that language is standard, freely available, >>> and highly efficient, as C++ is. >>> >>> This is a path I am also exploring via Lua and LuaJIT. But in the best >>> case here I still end up with 2 languages, Lua and Csound orchestra >>> language, with fragments of C also for passing data back and forth. >>> >>> Of course I need to keep Csound with its vast capabilities and huge >>> library of code and pieces in this picture... I don't want to throw >>> out the baby with the bath water... >>> >>> Best, >>> Mike >>> >>> On Sun, Feb 12, 2012 at 11:54 AM, Steven Yi <[hidden email]> wrote: >>>> Hi Michael, >>>> >>>> Regarding your addition, is the goal to make Instruments as plugins, >>>> much like opcodes can be read in at runtime? The one thing about >>>> loading an instrument at runtime, is that current Csound ORC both >>>> defines the instrument as well as assigns it to an index or name. >>>> We'd have something other than instr to do something like: >>>> >>>> loadinstr 1, "myinstrument.instr" >>>> >>>> (some other extension). >>>> >>>> I'm curious though, this kind of thing seems to reduce the long-term >>>> viability of a musical work by introducing binary dependencies. I >>>> guess I wouldn't use it myself, but what advantages do you see it >>>> giving? I can understand the use of compiled orchestras as a caching >>>> mechanism to speed up load times (sort of like python's pyc files >>>> versus py files), though. >>>> >>>> Thanks! >>>> steven >>>> >>>> >>>> >>>> On Sun, Feb 12, 2012 at 4:44 PM, Michael Gogins >>>> <[hidden email]> wrote: >>>>> Thanks, I have made some edits to the pages now. >>>>> >>>>> Best, >>>>> Mike >>>>> >>>>> On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi <[hidden email]> wrote: >>>>>> I'm sorry, but that is not correct. Use cases are not UML, though UML >>>>>> can be, and is often, used to express a use case (though, none of the >>>>>> companies I've worked for used UML for use case capturing...). In the >>>>>> use case section of this document, the "developer" IS the "user >>>>>> interacting with the program." >>>>>> >>>>>> Csound 5 opened up the roles for Csound to include the traditional >>>>>> user coding in Csound orc/sco, as well as adding developers who are >>>>>> using Csound as a synthesis engine/library. Csound 6 planning so far >>>>>> is primarily about the developer role, and how to accomodate their use >>>>>> cases for how they use Csound as an engine. There has not been much >>>>>> concrete discussion yet on traditional user changes, though some >>>>>> general discussion on language changes have come and gone. >>>>>> >>>>>> We will need to continue to expand the document for both roles. I >>>>>> have added a note to the wiki to clarify that the use cases and roles >>>>>> they are written for. >>>>>> >>>>>> Thanks, >>>>>> steven >>>>>> >>>>>> On Sun, Feb 12, 2012 at 2:40 PM, zappfinger <[hidden email]> wrote: >>>>>>> I do not mean to be picky here, but what you call 'Use cases' are actually >>>>>>> 'Requirements' >>>>>>> Use cases are a UML diagram showing the interaction between a user and a >>>>>>> program... >>>>>>> >>>>>>> my 2 cents. >>>>>>> >>>>>>> Richard >>>>>>> >>>>>>> -- >>>>>>> View this message in context: http://csound.1045644.n5.nabble.com/Csound-6-Development-Plan-tp5475930p5476675.html >>>>>>> Sent from the Csound - Dev mailing list archive at Nabble.com. >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Virtualization & Cloud Management Using Capacity Planning >>>>>>> Cloud computing makes use of virtualization - but cloud computing >>>>>>> also focuses on allowing computing to be delivered as a service. >>>>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>>>> _______________________________________________ >>>>>>> Csound-devel mailing list >>>>>>> [hidden email] >>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Virtualization & Cloud Management Using Capacity Planning >>>>>> Cloud computing makes use of virtualization - but cloud computing >>>>>> also focuses on allowing computing to be delivered as a service. >>>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>>> _______________________________________________ >>>>>> Csound-devel mailing list >>>>>> [hidden email] >>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Gogins >>>>> Irreducible Productions >>>>> http://www.michael-gogins.com >>>>> Michael dot Gogins at gmail dot com >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Virtualization & Cloud Management Using Capacity Planning >>>>> Cloud computing makes use of virtualization - but cloud computing >>>>> also focuses on allowing computing to be delivered as a service. >>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> [hidden email] >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> ------------------------------------------------------------------------------ >>>> Virtualization & Cloud Management Using Capacity Planning >>>> Cloud computing makes use of virtualization - but cloud computing >>>> also focuses on allowing computing to be delivered as a service. >>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> [hidden email] >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> >>> >>> -- >>> Michael Gogins >>> Irreducible Productions >>> http://www.michael-gogins.com >>> Michael dot Gogins at gmail dot com >>> >>> ------------------------------------------------------------------------------ >>> Virtualization & Cloud Management Using Capacity Planning >>> Cloud computing makes use of virtualization - but cloud computing >>> also focuses on allowing computing to be delivered as a service. >>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>> _______________________________________________ >>> Csound-devel mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Csound-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > -- > Michael Gogins > Irreducible Productions > http://www.michael-gogins.com > Michael dot Gogins at gmail dot com > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
Hello,
I'd like to fill in my thoughts a bit more, since IIRC I didn't have the chance to present the whole story to Steven last week. I think that there's something about how Csound currently executes that adds significant overhead, at least above some theoretical best-case. What exactly the source is, I don't know. However, I believe that there's significant overhead added per engine stack frame. In particular, can anyone explain why simply removing the extra stack frames associated with assignments, such as when assigning a p-variable to a i-variable, causes a non-negligible performance difference? Steven, are you alluding to pointer aliasing issues? That's my thought as well, but AFAIK the only way to test is by directly examining assembly, and I really am not the best person to do so. John L. On Mon, Feb 13, 2012 at 12:14 AM, Steven Yi <[hidden email]> wrote: > Hi Michael, > > I did some reading up and apparently the main issue with function > pointers is not the call so much as what compiler optimizations are > possible versus a direct call. Ultimately though, yes, we'd have to > measure. > > I do think we do need to move to changing spout access. It's just > better design IMO to grab the values from the instrument rather than > have it push to a global resource. I don't see it as something that > would prevent your use case though. Also, I think what I mentioned in > the previous email looks not too different than what you mentioned, as > the addNote would be what instantiates an instance, performKsmps would > be what runs the instance, and removeNote would end the instance. A > C++ base class could certainly be created that would come with Csound > that has default instantiation and instance queue code. I think the > design is simple yet flexible enough to handle the requirements. > > The issue I have with setting some kind of hook on Csound is that it > is not generic enough. I find the same issue with the yield > callback, and consequently made similar changes to allow adding > multiple callback-able objects to a CsoundObj instance in iOS/Android > (hopefully should be out soon). In essence though, I think what we're > talking about is fairly similar, except that what I'm proposing is > what you're proposing but encapsulated within this > InstrumentDefinition, rather than on Csound itself. Did I understand > your thought correctly? > > Thanks! > steven > > > On Sun, Feb 12, 2012 at 7:58 PM, Michael Gogins > <[hidden email]> wrote: >> First, I don't think that function pointers will incur any particular >> overhead with respect to all that is already going on. This is based >> on professional experience. A dynamic function pointer should have the >> same performance as a C++ virtual method call resolved at run time, >> that is, one additional pointer dereference on top of the function >> call setup. This should be negligible in practice. If in doubt, >> measure it. >> >> Second, what you envision is slightly different from what I have in >> mind, which is more like hooks into the runtime graph that the user >> (or Csound itself if it detects instrument plugins) would set. There >> would be one hook that Csound would call to create a new instrument >> instance, and another call to actually run the instrument. It would be >> up to the instrument instance itself, unlike as in your example, >> whether to write to spout (which would be added to using the Csound >> API from within the instrument). >> >> There might even be an Instrument base class derived from the existing >> instrument template structure, for access to pfields etc. by the C++ >> or C instrument code. >> >> Hope this is a bit clearer, >> Mike >> >> >> On Sun, Feb 12, 2012 at 2:14 PM, Steven Yi <[hidden email]> wrote: >>> Hi Michael, >>> >>> I think there's a tremendous value in having things within Csound >>> Code, particularly for history and learning, as well as later >>> extension. It's a reason that I never spent much time with things >>> like LADSPA and VST. Something I'd prefer in this case is that we >>> have the capacity to do it, but not necessarily promote it. By this >>> I'm thinking we can make instruments more like an interface rather >>> than a concrete class. >>> >>> If we do this, we would need to modify the performance loop. The idea >>> is that an instrument would have methods like (in psuedo-code): >>> >>> class Instrument { >>> >>> Note addNote(); >>> void removeNote(Note n); >>> MYFLT* performKsmps(); >>> } >>> >>> Instruments would then be responsible for keeping track of active >>> instances (this is already the case with current csound, but worth >>> pointing out for new instruments). The main performance loop kperf >>> would need modification to not handle going through each instrument's >>> opcode list itself, but just delegate to the classes perform function. >>> So the loop would just iterate through instrument and call perform >>> instead of doing the performing. >>> >>> Note the above performKsmps returns a MYFLT*. This was another thing >>> I remembered discussing with Victor, that instrument no longer write >>> to global SPOUT, but rather write to a per-instance spout. The >>> Instrument performKsmps then would then collect and mix the instance >>> spouts, and csound's performKsmps would in turn collect and mix >>> instrument spouts. This should then make things a little easier for >>> parallelization. >>> >>> To address your concern, Instruments could then be subclassed within >>> C/C++/other host language. They would need to handle the above >>> methods. I think we could do it in a C way by doing: >>> >>> struct InstrumentDefinition { >>> Note* (*addNote)(int argc, pfield[] pfields, map optionalArgs); >>> void (*removeNote)(Note*); >>> MYLFT* (*performKsmps)(); >>> }; >>> >>> My one concern though is performance due to function pointers. (I had >>> a conversation with John Lato last week and he saw some things that >>> implied that the function pointers used with how the opcode chain is >>> built may take longer than he would expect). However, I think this >>> would do the trick, yes? >>> >>> Thanks! >>> steven >>> >>> >>> >>> On Sun, Feb 12, 2012 at 6:49 PM, Michael Gogins >>> <[hidden email]> wrote: >>>> Thanks for your response. >>>> >>>> Yes, the goal is instrument plugins, I should of thought of that term myself. >>>> >>>> I don't think a change in language is required, if the instr name is >>>> not found Csound can look for a plugin before producing an error. >>>> >>>> There are two reasons I would like to have instrument plugins: >>>> >>>> (1) It is easier to write synthesis and DSP code in C++ than in >>>> orchestra code for some people, including me. I already had some >>>> experience doing this with cmix, where it is the only way to write >>>> instrument code, and I actually prefer this. >>>> >>>> (2) There would be no binary obsolescence if the piece, as a whole, >>>> were written in C++ as a single C++ source code file including >>>> instrument definitions. Such a piece would run Csound via the API and >>>> automatically register its plugin instruments with Csound the same way >>>> it is possible to register plugin opcodes at run time with the API. >>>> >>>> In general, there is a constant battle between musical usability and >>>> software engineering complexity in our work. I see the ability to >>>> write all aspects of a piece, including score generating code, user >>>> interface, and synthesis, in a single language as being a significant >>>> decrease in software engineering complexity and an increase in musical >>>> usability, especially if that language is standard, freely available, >>>> and highly efficient, as C++ is. >>>> >>>> This is a path I am also exploring via Lua and LuaJIT. But in the best >>>> case here I still end up with 2 languages, Lua and Csound orchestra >>>> language, with fragments of C also for passing data back and forth. >>>> >>>> Of course I need to keep Csound with its vast capabilities and huge >>>> library of code and pieces in this picture... I don't want to throw >>>> out the baby with the bath water... >>>> >>>> Best, >>>> Mike >>>> >>>> On Sun, Feb 12, 2012 at 11:54 AM, Steven Yi <[hidden email]> wrote: >>>>> Hi Michael, >>>>> >>>>> Regarding your addition, is the goal to make Instruments as plugins, >>>>> much like opcodes can be read in at runtime? The one thing about >>>>> loading an instrument at runtime, is that current Csound ORC both >>>>> defines the instrument as well as assigns it to an index or name. >>>>> We'd have something other than instr to do something like: >>>>> >>>>> loadinstr 1, "myinstrument.instr" >>>>> >>>>> (some other extension). >>>>> >>>>> I'm curious though, this kind of thing seems to reduce the long-term >>>>> viability of a musical work by introducing binary dependencies. I >>>>> guess I wouldn't use it myself, but what advantages do you see it >>>>> giving? I can understand the use of compiled orchestras as a caching >>>>> mechanism to speed up load times (sort of like python's pyc files >>>>> versus py files), though. >>>>> >>>>> Thanks! >>>>> steven >>>>> >>>>> >>>>> >>>>> On Sun, Feb 12, 2012 at 4:44 PM, Michael Gogins >>>>> <[hidden email]> wrote: >>>>>> Thanks, I have made some edits to the pages now. >>>>>> >>>>>> Best, >>>>>> Mike >>>>>> >>>>>> On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi <[hidden email]> wrote: >>>>>>> I'm sorry, but that is not correct. Use cases are not UML, though UML >>>>>>> can be, and is often, used to express a use case (though, none of the >>>>>>> companies I've worked for used UML for use case capturing...). In the >>>>>>> use case section of this document, the "developer" IS the "user >>>>>>> interacting with the program." >>>>>>> >>>>>>> Csound 5 opened up the roles for Csound to include the traditional >>>>>>> user coding in Csound orc/sco, as well as adding developers who are >>>>>>> using Csound as a synthesis engine/library. Csound 6 planning so far >>>>>>> is primarily about the developer role, and how to accomodate their use >>>>>>> cases for how they use Csound as an engine. There has not been much >>>>>>> concrete discussion yet on traditional user changes, though some >>>>>>> general discussion on language changes have come and gone. >>>>>>> >>>>>>> We will need to continue to expand the document for both roles. I >>>>>>> have added a note to the wiki to clarify that the use cases and roles >>>>>>> they are written for. >>>>>>> >>>>>>> Thanks, >>>>>>> steven >>>>>>> >>>>>>> On Sun, Feb 12, 2012 at 2:40 PM, zappfinger <[hidden email]> wrote: >>>>>>>> I do not mean to be picky here, but what you call 'Use cases' are actually >>>>>>>> 'Requirements' >>>>>>>> Use cases are a UML diagram showing the interaction between a user and a >>>>>>>> program... >>>>>>>> >>>>>>>> my 2 cents. >>>>>>>> >>>>>>>> Richard >>>>>>>> >>>>>>>> -- >>>>>>>> View this message in context: http://csound.1045644.n5.nabble.com/Csound-6-Development-Plan-tp5475930p5476675.html >>>>>>>> Sent from the Csound - Dev mailing list archive at Nabble.com. >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Virtualization & Cloud Management Using Capacity Planning >>>>>>>> Cloud computing makes use of virtualization - but cloud computing >>>>>>>> also focuses on allowing computing to be delivered as a service. >>>>>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>>>>> _______________________________________________ >>>>>>>> Csound-devel mailing list >>>>>>>> [hidden email] >>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Virtualization & Cloud Management Using Capacity Planning >>>>>>> Cloud computing makes use of virtualization - but cloud computing >>>>>>> also focuses on allowing computing to be delivered as a service. >>>>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>>>> _______________________________________________ >>>>>>> Csound-devel mailing list >>>>>>> [hidden email] >>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Gogins >>>>>> Irreducible Productions >>>>>> http://www.michael-gogins.com >>>>>> Michael dot Gogins at gmail dot com >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Virtualization & Cloud Management Using Capacity Planning >>>>>> Cloud computing makes use of virtualization - but cloud computing >>>>>> also focuses on allowing computing to be delivered as a service. >>>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>>> _______________________________________________ >>>>>> Csound-devel mailing list >>>>>> [hidden email] >>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Virtualization & Cloud Management Using Capacity Planning >>>>> Cloud computing makes use of virtualization - but cloud computing >>>>> also focuses on allowing computing to be delivered as a service. >>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> [hidden email] >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> >>>> >>>> -- >>>> Michael Gogins >>>> Irreducible Productions >>>> http://www.michael-gogins.com >>>> Michael dot Gogins at gmail dot com >>>> >>>> ------------------------------------------------------------------------------ >>>> Virtualization & Cloud Management Using Capacity Planning >>>> Cloud computing makes use of virtualization - but cloud computing >>>> also focuses on allowing computing to be delivered as a service. >>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> [hidden email] >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> ------------------------------------------------------------------------------ >>> Virtualization & Cloud Management Using Capacity Planning >>> Cloud computing makes use of virtualization - but cloud computing >>> also focuses on allowing computing to be delivered as a service. >>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>> _______________________________________________ >>> Csound-devel mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> >> -- >> Michael Gogins >> Irreducible Productions >> http://www.michael-gogins.com >> Michael dot Gogins at gmail dot com >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Csound-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Csound-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Csound-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/csound-devel |
«
Return to Csound - Dev
|
1 view|%1 views
Loading...
| Powered by Nabble | See how NAML generates this page |
