A thing that VCV has going for it compared to MiRack is polyphonic cable and potential to use both MPE and regular polyphonic modules.
A suggestion, maybe a long shot, would be to include some form of module “wrapper”, wherein multiple instances of, for instance, an oscillator could be stored. Perhaps a dedicated “midi-to-poly” module could then be used to feed these bundled modules.
If this is technically/aesthetically doable it would solve the issue of having monophonic modules responding to polyphonic midi.
(right now I use a workaround to get more voices by loading multiple mirack instances in AUM and assign them to different midi channels… works ok, but is both messy and makes comples modulation difficult. )
Hi, sorry for a late reply. What you describe is almost exactly how I was/am going to implement polyphony. Not because it can’t be done the other way - it’s not a big problem. But I don’t like the situation where some modules support polyphony, some not, while this way it can be taken care of by the host for all modules without having to wait for module developers to implement polyphony and maybe even adding some additional features and configuration options along the way. Theoretically implementing polyphony inside a module should give better performance, but not too many modules actually contain this kind of optimisations.
As you are still doing tests on polyphony: Is this something that can be treated as an own topic?
It is somehow vital to reuse previously created blocks of modules. Taking screenshots and rebuilding is possible, but clearly not as satisfying as the wrapper is to my imagination
