Hi All,

I'm looking into the a request from Matt to reinstate calling
subinstruments as opcodes:

http://www.csounds.com/manual/html/instr.html#InstrSubinstrument

I took a look at csound 4.23f13gbs source from SourceForge and found
reference to a "_subins" opcode which is used when named instruments
are called as subinstruments using opcode syntax.  I am wondering did
anything change since when that was there and when it was removed (all
traces of calling named instruments as subinstruments using opcode
syntax seem to be gone in current csound5 cvs, and my guess has been
gone for a long time).

There are a couple things here I'd like to note though before I
continue to look into this.

First, calling subinstruments has limitations that I believe have been
discussed here before, namely that inargs to the subinstr are itime
vars used as pfields.  This makes calling the subinstr much like
spawning and event with the event opcode but with the ability to
capture the audio output for further processing.  On the other hand,
it's a bit limited to only be able to use itime variables.

Second, and the much more serious issue to me, is that subinstruments
return audio to the calling instrument using a bit of a trick, using a
temporary spout.  It swaps the csound->spout with the temp one, runs
the instrument, then collects the output from the temp spout, then
return the original spout back to the csound->spout pointer.  The big
problem with this is that this will not work at all for multi-core
implementations of Csound.  I can not see any way possible to get
around this issue as of yet and would venture to even suggest removing
the subinstr and subinstrinit opcodes if we are seriously going to do
work on making csound capable of running multi-core.


Politics aside (as the whole subinstruments/UDO's has a bit of a
touchy history) and focusing only on the technical features and
balancing that with future needs, if we can not find a solution to
this that is less drastic, what does everyone think about removing
subinstrument calling or at least making them deprecated?

Thanks,
steven

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net