Hi All,

I had an interesting discussion with Victor and some good things came
out of it.  A few things:

* Debug mode - Csound does not optimize the tree.  This allows
variable look ups to be done as nothing gets optimized out, and so
probing can be done.  Slower to run; but debug probing would not be
possible otherwise.  Matches behavior with debugging that you find in
compiled code and compilers.

* Instance references - in addition to csoundScoreEvent and
csoundInputMessage, is to have a version that accepts a note and
returns the instance associated with it. This allows a few things to
be done, including managing the note from a host, as well as modifying
it during performance using channels (next point).

* Channel Data - Channels currently are global.  We discussed doing
channels at three levels: global, per instrument definition
(equivalent to static class members in Java), and per instrument
instance.  The global is well understood and used currently; per
instrument allows controlling things in a way similar to MIDI-based
workflows, i.e. controlling a filter cutoff, something shared by all
not instances.  Per instance channel data would allow some complex
interactions to occur, though would likely be more edge-case based
musical work.  Introducing an instance type within csound is a
possibility to pass instances of instruments as references to other
instances.  chnget and chnset would be modified to have an additional
parameter that allows what scope to pull/push data from/to, i.e.
0=global, 1=instrument definition, 2=instrument instance.


Related to debug, I think we may want to think about performance
profiles and optimization flags.  Like gcc, there are certain flags
one can use to enable/disable optimizations (like -fmerge-constants),
and there are meta-flags that will set multiple individual features
(like -O3).  This goes back to some conversation we had here regarding
optimizing csound for offline vs. real-time.  Some things that are
done in SuperCollider, for example, optimize for problems regarding
realtime to avoid dropouts, while at the expense of offline rendering
speed and sample rate accuracy (i.e. a table load is off the main
audio thread, which is great for realtime, but may mean the load
finishes a control block later or more).  Having a framework for these
kinds of things would simplify how we approach experiments with the
runtime and offline performance design.

I think that covers most of what we discussed.  Probably should add
this to the wiki, but will wait for any feedback first.

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

We also discussed being able to access each instance's output buffer, so we can more easily directly tap the output of an instrument. This would go hand-in-hand with changing instruments to hold their own output buffers.

Victor
On 25 Feb 2012, at 18:02, Steven Yi wrote:

> Hi All,
> 
> I had an interesting discussion with Victor and some good things came
> out of it.  A few things:
> 
> * Debug mode - Csound does not optimize the tree.  This allows
> variable look ups to be done as nothing gets optimized out, and so
> probing can be done.  Slower to run; but debug probing would not be
> possible otherwise.  Matches behavior with debugging that you find in
> compiled code and compilers.
> 
> * Instance references - in addition to csoundScoreEvent and
> csoundInputMessage, is to have a version that accepts a note and
> returns the instance associated with it. This allows a few things to
> be done, including managing the note from a host, as well as modifying
> it during performance using channels (next point).
> 
> * Channel Data - Channels currently are global.  We discussed doing
> channels at three levels: global, per instrument definition
> (equivalent to static class members in Java), and per instrument
> instance.  The global is well understood and used currently; per
> instrument allows controlling things in a way similar to MIDI-based
> workflows, i.e. controlling a filter cutoff, something shared by all
> not instances.  Per instance channel data would allow some complex
> interactions to occur, though would likely be more edge-case based
> musical work.  Introducing an instance type within csound is a
> possibility to pass instances of instruments as references to other
> instances.  chnget and chnset would be modified to have an additional
> parameter that allows what scope to pull/push data from/to, i.e.
> 0=global, 1=instrument definition, 2=instrument instance.
> 
> 
> Related to debug, I think we may want to think about performance
> profiles and optimization flags.  Like gcc, there are certain flags
> one can use to enable/disable optimizations (like -fmerge-constants),
> and there are meta-flags that will set multiple individual features
> (like -O3).  This goes back to some conversation we had here regarding
> optimizing csound for offline vs. real-time.  Some things that are
> done in SuperCollider, for example, optimize for problems regarding
> realtime to avoid dropouts, while at the expense of offline rendering
> speed and sample rate accuracy (i.e. a table load is off the main
> audio thread, which is great for realtime, but may mean the load
> finishes a control block later or more).  Having a framework for these
> kinds of things would simplify how we approach experiments with the
> runtime and offline performance design.
> 
> I think that covers most of what we discussed.  Probably should add
> this to the wiki, but will wait for any feedback first.
> 
> 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

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