As a pattr zealot, I’ve knocked up a simple example to show ‘one way’ of doing the ‘single UI to reflect/control individual poly voices’. The crux of the patch is pattr objects in the UI layer dynamically bind to equivalent pattrs in the specific voice of a poly~ object, that contains the N instances of your dsp.
Depending on your needs, a (purely) pattr solution may or may not be most appropriate – its usually my go to solution, due to the systems abilty to do ‘wireless communication’ throughout the patcher heirarchy without resorting to send/receive pairs (coupled with the fact that adding presets to a ‘pattr-based system is a doddle).
Referring to the original question, I’d definitely be in favour of using poly~ to load N instances of your (X)FM synth. This will allow you take advantage of poly~s voice muting (to save on CPU), as well as acheive polyphony. Additioanlly, you *should* be able to avoid hard-coding how many drum voices your patch supports (should you find that 16 is too few, or perhaps too CPU intensive)
Finally, to add ‘presets per voice’, in line with the example patch I’ve posted, I’d probably go with adding a pattrstorage object into the poly subpatch, rather than using a single pattrstorage in the ‘top-level’ of the patch. The difficulties I’d envisage in doing this are that you’d have to manage N uniquely named pattrstorage objects, and manage an xml/json preset file for each. You’d also need to interact with the preset managing remotely in the UI, which could be complicated, depending on your requirements…
May 31, 2012 at 8:27pm #202810