I'm not much for adding more to the core myself, when one can program
something like this once as a UDO, put it in a file, then #include it
and use it.   However, if something like this goes in, I'd rather see
it as a modification to maxalloc:

http://csound.github.io/docs/manual/maxalloc.html

perhaps by adding an additional "istrategy" argument. Others have
expressed wanting a different strategy (i.e., FIFO).  Looking at this
page:

http://electronicmusic.wikia.com/wiki/Voice_stealing

mentions in brief some other strategies.  Some things like dealing
with notes with sustain pedals point to places where I can imagine
someone saying "well this synth does it this way, why can't you put it
in", even though the voice selection algorithm starts to become harder
to implement in a generic way.

That said, I'm also not sure how maxalloc was implemented, and it may
not be easy to augment.

So let me ask a question as well: what does everyone think is "proper"
voice stealing, and what algorithms would you want supported?  If we
start from there with clearly defined expected behavior, I think it'd
help to see if is possible to do in user-code alone, and if not,
figure out a strategy for what to do (whether that is, expose more
features for inspecting Csound instrument instances, or implementing
the algorithms within C code).


On Mon, Nov 23, 2015 at 5:32 PM, Aaron Krister Johnson
 wrote:
> Hi all,
>
> Steven Yi was discussion a new processing graph proposal, as apparently
> Csound 7 is on the horizon.
>
> I would love to make a request of the developers for something that would
> really be helpful: a "polyphony" opcode. I'm thinking of something that
> would be able to automatically allocate and do proper voice stealing for
> both MIDI and score instruments.
>
> I'm not sure the best way this might happen, but perhaps an opcode without
> an output, defined within an instrument block, which could apply for all
> instances of that instrument. It could probably leverage existing code
> relating to turnoff2, maxalloc, etc. but make it convenient for the user to
> not have to roll their own code for such a standard situation as limiting
> polyphony.
>
> E.G.:
>     instr 1
>
>     polyphony 8
> iamp ampdb(p4)
> ipch p5
> aosc vco2, iamp, ipch, 0 ...... etc....
>
>     endin
>
>
> Thoughts? Is this feasible at all? Does anyone else like the idea?
>
>
> Aaron Krister Johnson
> http://www.untwelve.org
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

maxaloc is simple; it records how many are allowed anfd wen there are 
rthat many it will not init another.  Rather the opposite of usual voice 
stealing.  Very simple.

A more flexible voice stealer would need a list of instances in creation 
order at its heart.  An UDO could be constructed to record codes in a 
table or array but I suspect it is tricky.

==John ff

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I think I can see how to implement a "kill-oldest" strategy, which if 
suplemented by a "do-not-steal-me" opcode might be enough.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here