Cherry Audio Forums

Was experimenting further with poly patches. One thing that instantly gets on my nerves is that if you change something on a voice you have to delete and recreate all copies. So "polyfication" of a patch should be the very last step - which makes it more difficult to interatively experiment.

The optimal way would imho be to have poly cables (best for all modules, not only the "poly oscillator" which is nice but not really modular - as neither ADSRs nor VCAs nor filters nor anything else supports this "poly midi connector", "lite" versions of these essential modules are hardwired in the poly osc - which in result is a lot less capable than most hardwired poly-synths out there and imho somehow defeats the purpose of the modular environment).
Yes, poly cables would deviate from what is possible in hardware. But software already has limits regarding e.g. tactility etc. - if it artificially inherits the disadvantages of hardware, too then there is the possibility that the result is just the worst of both worlds - imho.

But if staying 100% close to the hardware metaphor is considered important: Perhaps one way to make this still more usable: Cabinets could by grouped into "sync groups".
One of the cabinets in the sync group would be the "master". Any change applied to that master sync group would automatically be applied to all "slave" group members. If a single cv connection from outside the sync group is established then all slaves automatically also get connected (thus we could have up to 6 slaves atm. because of the 6 connections per cv output restriction). If a cable is directly dragged to a specific slave though then only that slave is connected. So voice specific modulation would still be possible. Similarly if a setting is changed (or a module added) to a slave then this could also voice specific. If a knob was changed in the slave and afterwards turned in the master then it would jump back to the setting of the master again though - if the module exists in the master.
Additionally there could be a "reset to master" button where any local changes (like additional modules, tuned sliders etc.) of a slave could be reverted to the master.

A perhaps easier to implement (but less convenient) variant: There is no disctinction between master and slaves. Any change to any cabinet in the sync group is always applied to all group members. And connections from outside the sync group are always connected to all members, too. If a certain voice needs special treatment (like changed settings or specific modulation) then it would have to be ungrouped. Which makes it individually editable again.

Perhaps for certain poly-prepared modules like the poly cv converter there could be an additional patch aid "poly" output row (below the separate per voice cv rows). When connecting such a poly output to the master of a sync group then VoltageModular could automatically connect the corresponding cv cable from single voice 1 to the first slave from that sync group, the one from voice 2 to slave 2 etc. Thus we would usually only have to wire up the master for poly patches but still get the connections as if we wired up the individual voices - thus all the connections we'd have in real hardware (or the current version of VoltageModular) would still be made.

This wouldn't limit the flexibility at all and still would stay 100% close to the hardware metaphor. Synced cabinets and poly outputs would only be a patching aid that automates managing the single connections. But it would be a lot more convenient to create poly patches, without restricting ourselves to pre-wired, inherently limited "poly-lite" synths like the poly oscillator.

What do you think?

agreed...

+ 1

I hope for an Mpe module with expression curves.

Thanks guys. We are definitely interested in adding new features...but, as you know, there will always be new features. We are hard at work getting version 1 ready. It's never going to have everything that everyone wants. We will have to look at the poly features later. We are listening, but we also need to ship Voltage. Thanks for understanding! (=

Am currently experimenting with how poly-capable modules can be built for VM.

But the downside is still: Even if we have poly-enabled modules, 95% of the other modules are not poly-aware, so you either have to stay in your "island" of poly-enabled modules - or you have to model each voice individually again in separate cabinet rows, with all the fun of keeping stuff in sync. And as only a percentage of the devs are presumably interested in poly-stuff I guess in the future we will see mostly new non-poly aware new modules.

On second thought here a solution that would probably be not to difficult to implement and solve the problem in an elegant and simple way:
What about an option to define per cabinet row how many copies of the modules in that row VM should generate internally?
Connections from outside the "poly-row" would have to be mixed or multiplexed as needed. And any UI interaction would have to be synchronized with all internal copies.
I think the only extension on developer API side this would require is a method that allows us to find out the voice ID of the rack copy our instance lives in. (For e.g. 16 voices this ID would be e.g. 1-16). This would allow to create all kinds of multiplexers and demultiplexers for both cv and midi - which in turn would allow to use all the mono modules.

Here some examples:
First some "brute-force" approach where we have a mono-rack in row one with 16 individual sources for 1V/Oct, pressure etc. and 16 outputs that process the individual voices of the poly-rack below. In the poly rack (set to 16x polyphony) we have two instances of poly-aware "CV channel splitters" which have 16 inputs and one output on which they output the input that matches the poly-ID of the particular instance (writing such a module would be trivial when having the poly-ID available in the SDK). The output is then sent to a "CV channel multiplexer" that does the inverse operation: It routes a single input to the output that matches the poly-id of the instance. Edit apparently I can only have one image per posting, so adding the further examples in separate postings below.

As the inputs were just generated from MIDI in the example above (and the midi cable is multi-channel capable anyways), the layout above could be further simplified by introducing "MPE to rack CV" modules that map midi events to cv. The type of the midi event (CCs, aftertouch, pitchbend, note events, velocity or as a convenience note pitch+pitchbend) could be chosen and the channel from which the events are taken is determined by the poly-id of the mpe-to-rack-cv instance again. In our example note pitch+pitchbend would be mapped to key cv of the oscillator and e.g. channel aftertouch to gain.
As a further simplification this layout would use the automatic mixing facility af poly-racks - we only need a single cable from the gain output to the main output, the 16 copies would be mixed automatically (so this is fine as long as I want to mix every voice with the same gain - which is presumably the default. Otherwise we could use a more explicit mixing approach like shown in the example above).

The same game could be done with midi modules (that usually are not channel aware - like the poly oscillator). Here it would be easy to write a "MIDI channel splitter" that gets in an MPE compatible midi stream and outputs only the events that are sent on a channel that matches the poly-id.
This would probably be a lot easier than the more elaborated "sync group" approach from above. The only restriction would be that you would have to place the modules for one voice into one row. But as there is (afaik?) no restriction how many modules you can put into one row this wouldn't be too severe.

P.S.: This could easily be extended (as second step) with some of the suggestions from above. Specifically with the "multi-channel cable". If we would introduce a new kind of cable that is essentially not one CV cable but a bundle of several that can be accessed like an array in the SDK(*), then the rule could be that multi-channel cables are not multiplexed nor merged automatically (the same as MIDI cables). So I can send data from e.g. voice 3 of poly-row 1 to voice 3 of poly row 2 by writing a simple module that wraps a mono-cv into a multi-channel cv at the position that matches the poly-id: 3.
Or I could write new polyphonic/multitimbral modules that can send out multi-channel CV. And then use a module that splits a multi-channel stream to a single CV (based on poly-ID) and thus allows to easily use poly-capable modules together with mono modules in a per-voice fashion.
And all that without introducing any complexity to either users nor devs that don't care about individually controllable voices.

(*) optimally the number of channels in a multichannel stream wouldn't be hardcoded but determined by the module that generated it. Then the receiver can check for the number of channels. And either dynamically adapt or only consider the first N (e.g. the first 16 for the 1:16 multiplexer module - but writing a multiplexer that supports up to 32 channels would be simple without changing the concept underhood).
The background for that: In a third step we could allow a module to dynamically change the number of voices of the row it is placed in. That way you could easily implement dynamic voice allocation just by looking at the number of channels of an incoming multi-channel cable and setting the poly-count of the row accordingly.
So implementing this poly-support could start small "just" with the poly rows and has some nice outlook with future extensions that would smoothly fit in!

The more I think about it the more awesome it sounds

P.P.S.: An alternative to "poly-rows" would be "poly-subracks". So instead of defining the polyphony for a row there would be a "subrack-module" with a single multi-channel CV input and output as well as MIDI in and out. And for this subrack module polyphony can be specified.
Additionally when double clicking on that subrack module an empty rack opens that allows to define it's content. Additionally an optional "link name" could be set. Submodules with the same link name share the same content, so if you alter one all linked ones are also altered. The content of subrack modules could also be stored into individual files for reuse in other setups.

From an SDK point of view it could either be possible to aquire the multichannel input+output and midi input+output of the rack this module is belonging to - and the poly-id of the particular instance. That way we could easily write modules that either hand out or consume just the cv or MIDI channel for the particular voice (so mono-cv/midi modules can be connected) or that combine the inputs/outputs of several voices..

An alternative would be not to expose this in the SDK to all modules but offer pre-provided "inlet" and "outlet" modules that provide the multi-channel cv in/out and the midi in/out as well as the poly-id. Then writing demux modules that e.g. just output the voice specific cv or midi event stream would still be possible (and it would prevent that any module could pull input out of thin air without visual indication - so users could always follow paths up to the inlets/outlets when looking which input goes into a particular module).

That would essentially be similar to the abstraction and submodule + "clone" concept of Pure Data (or poly~ in Max).

It also helps to clean up complex setups - a feature that would also be helpful for people who don't mind about polyphony but just want to build setups that are not "write only".
From a complexity reduction point of view this would certainly be helpful. Question is whether "awesome wall of modules" considered as piece of art is the ultimate goal (you can still make your walls, subracks would be a "can", not "must" )

By setting the default polypyhony of subracks to 1 and exposing the full multi-channel input/output (instead of just the voice specific cv) this usage of sub-racks for structuring of setups (instead of for polyphony) would be simplified. (And we wouldn't need three concepts for abstractions, submodules and clones like in Pd).

Thanks for your feedback. You've made some good arguments for having poly. We are looking into this and most likely will be implementing poly cables/poly jacks. (=

Cherry Garcia wrote: ↑Mon Oct 22, 2018 5:19 pm Thanks for your feedback. You've made some good arguments for having poly. We are looking into this and most likely will be implementing poly cables/poly jacks. (=

Sounds great - I hope it comes to fruition - and kudos to NothanUmber for the ideas