Hi Matt,

> doesn't  'setksmps' use the same technique?

Ugh! I took a look and setksmps and UDO's use a similar thing going on
but I think modify things like onekr and ksmps but not spout.  I have
to do more looking into this.  Either way, UDO's too will need to be
reworked.  I actually have to check what happens if you use an output
opcode like outc when using UDO's as I've always used xout.

> 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?
>
> but what about backwards compatibility? :)
>
> anyway,
> i would say just put it in it with a warning in the code and manual
> and deal with multiprocessor issues if it ever gets to that point.
> however it is a little used feature (especially since istvan removed
> it!) and i could live without it..

Yeah, I'm not sure at this point what to do.  It's all a bit of a
mess; I'm thinking that I'm going to move on to other things and just
leave things where they are.  It might be worth rethinking how output
is done altogether and instead of writing directly to spout, to have
it write to an instrument's spout buffer which is then collected by
whatever is driving the instrument.  Basically this would mean getting
rid of all accesses to the global spout and instead write to the local
spout.  This would make instruments and udo's much more
self-contained.  Having local versions of sr, kr, ksmps, etc. per
instrument/UDO would make it a lot better I think for multi-core.

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