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
Csound-devel@lists.sourceforge.net

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  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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

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
 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  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
>> Csound-devel@lists.sourceforge.net
>> 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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

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  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
>  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  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
>>> Csound-devel@lists.sourceforge.net
>>> 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
>> Csound-devel@lists.sourceforge.net
>> 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
Csound-devel@lists.sourceforge.net

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
Csound-devel@lists.sourceforge.net

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  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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

Thanks, I have made some edits to the pages now.

Best,
Mike

On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi  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  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
>> Csound-devel@lists.sourceforge.net
>> 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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

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
 wrote:
> Thanks, I have made some edits to the pages now.
>
> Best,
> Mike
>
> On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi  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  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
>>> Csound-devel@lists.sourceforge.net
>>> 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
>> Csound-devel@lists.sourceforge.net
>> 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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

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  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
>  wrote:
>> Thanks, I have made some edits to the pages now.
>>
>> Best,
>> Mike
>>
>> On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi  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  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
>>>> Csound-devel@lists.sourceforge.net
>>>> 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
>>> Csound-devel@lists.sourceforge.net
>>> 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
>> Csound-devel@lists.sourceforge.net
>> 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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

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
 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  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
>>  wrote:
>>> Thanks, I have made some edits to the pages now.
>>>
>>> Best,
>>> Mike
>>>
>>> On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi  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  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
>>>>> Csound-devel@lists.sourceforge.net
>>>>> 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
>>>> Csound-devel@lists.sourceforge.net
>>>> 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
>>> Csound-devel@lists.sourceforge.net
>>> 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
>> Csound-devel@lists.sourceforge.net
>> 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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

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  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
>  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  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
>>>  wrote:
>>>> Thanks, I have made some edits to the pages now.
>>>>
>>>> Best,
>>>> Mike
>>>>
>>>> On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi  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  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
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> 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
>>>>> Csound-devel@lists.sourceforge.net
>>>>> 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
>>>> Csound-devel@lists.sourceforge.net
>>>> 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
>>> Csound-devel@lists.sourceforge.net
>>> 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
>> Csound-devel@lists.sourceforge.net
>> 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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

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
Csound-devel@lists.sourceforge.net

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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

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
 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
>> Csound-devel@lists.sourceforge.net
>> 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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

John, by what means would you prefer to conduct this discussion?

Best,
Mike

On Sun, Feb 12, 2012 at 6:23 PM, Iain Duncan  wrote:
> On Sun, Feb 12, 2012 at 3:04 PM, Steven Yi  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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

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
 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  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
>>  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  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
>>>>  wrote:
>>>>> Thanks, I have made some edits to the pages now.
>>>>>
>>>>> Best,
>>>>> Mike
>>>>>
>>>>> On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi  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  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
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> 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
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> 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
>>>>> Csound-devel@lists.sourceforge.net
>>>>> 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
>>>> Csound-devel@lists.sourceforge.net
>>>> 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
>>> Csound-devel@lists.sourceforge.net
>>> 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
>> Csound-devel@lists.sourceforge.net
>> 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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net

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  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
>  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  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
>>>  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  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
>>>>>  wrote:
>>>>>> Thanks, I have made some edits to the pages now.
>>>>>>
>>>>>> Best,
>>>>>> Mike
>>>>>>
>>>>>> On Sun, Feb 12, 2012 at 10:14 AM, Steven Yi  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  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
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> 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
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> 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
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> 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
>>>>> Csound-devel@lists.sourceforge.net
>>>>> 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
>>>> Csound-devel@lists.sourceforge.net
>>>> 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
>>> Csound-devel@lists.sourceforge.net
>>> 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
>> Csound-devel@lists.sourceforge.net
>> 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
> Csound-devel@lists.sourceforge.net
> 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
Csound-devel@lists.sourceforge.net