Advanced Voice Allocation
Hi,
I think I may need to build my own voice allocation system, for a couple of reasons -
1. poly cannot dynamically change the amount of voices before stealing, and borax does not have a steal feature.
2. I would like to have quite a complex allocation system - user assignable voice numbers to the actual "physical voices", that may be enabled. Then once selected - have different allocation modes and order settings - continuous (cycle through all enabled voices) and restart (jump back to "earlier" voices when available) (the way poly works now) mode. And have several play order settings - foreward, backward, forback, interlace, and different randoms/drunk etc.
I hope it's clear what I'm after - it may seem over the top - and probably is, but I have my reasons :)
I'm hoping there is an external or some in depth resources to help me.
I think I'll be able to manage the allocations by renaming/assigning the outgoing voice numbers, but I'd like to avoid saving incoming notes to manage stealing.
So far my only thought to manage the stealing is to create several polys - one for each possible voice amount and switching between them when required - but that seems quite primitive.
Thanks.
i use a simple round robin abstraction (similar to the cycle object, which didnt allow floats or lists in earlier versions of max), that works for most cases.
i originally started using voice allocation from _outside not only because i simply fail to understand the automatic nonsense, but also because i had the need to control e.g. "aftertouch" independently from "note on" and things like that.
so i made one patch with provides prepend target 1, prepend target 2, ... and various cycle/decode objects which "sort" incoming data to the voice where i want it to be sent.
in a simple round robin voice stealing is basically always on, but for a generator type (synth? sampler?) of poly patch this is sufficient for my needs.
if you really want to know about currently running voices you will of course still need to get that info from inside the poly (thispoly, adsr, line,...). which can produce some interesting threading problems... for example if that info is required to influence the settings of your custom voice allocation system ... even worse when the vector size inside the poly differs from the outer world.
but i´d consider this a special case only.