Open jamesholdenmusic opened 9 months ago
jamesholdenmusic
commented
6 months ago https://github.com/tmhglnd/poly-recursion?tab=readme-ov-file
this is clever, each poly loads the next into itself. ie each poly is the processing then another poly. so as long as the chain just has stereo io in a line you can make any length of chain with no added latency
jamesholdenmusic
commented
3 weeks ago a collective could also be solely a ui object - those boxes vanish and you just see a 'collective' box. a note block manages the polyphony if you instantiate voices of the collective, but otherwise it just uses a load of voices? not sure about this.
ui-wise, there are two things: the possibility to clear stuff out of the way, as described in the original idea, and the possibility to shuffle the order of things in a linear way like normal software, or to group a little linear rack into one item, which might be a separate idea?
this should be easier than it sounds.
a collective is a wrapper that loads multiple blocks into itself. it combines the parameters of all into one block's worth of space (?), so that and the fixed routings (no feedback?) are the limits on what you can do. to make one you just select the blocks, if they can be collected a button appears. like vsts a collective is just a json file - a huge list of parameters etc like a normal block but a special section listing the contents(ie poly4 contains this one, poly5 is blank, etc..) and routing/offset-attenuate-spread settings of everything long!
simple example: midi in -> voice basic -> 2p filter -> out lfo ---- pwm^ midi in -> env ------------^
so the voice.basic gets the first 23 slots in params, the 2p filter gets the next 15, the lfo gets the 17 after that, etc
midi routing is handled by a mini version of the gen router?
the polys are arranged in some kind of parallel tree structure, able to load either kind of patcher (notes, audio, polyrouter)? in a special new sub-wrapper? or just some fancy js to give them everything they need? they don't need to be reloaded so no wrapper needed. also all run on one core this kind of setup could easily be made polyphonic - main patch just loads a few copies as voices, etc.
so more complex eg: midi in -> autodamp -> 4x voice basic -> 2p filter -> vca -> out midi in -> 2x env ---------------------------^ ----------^
in order to have full poly features for the polys contained inside you'd need to take up more than one voice-worth of param-data-space, but you would anyway as 4 voice basic is like 90 params. but this would make making the collective polyphonic harder? i don't want to get into drawing like 4 voices with 4 subvoices inside each, that makes no sense..