I’m sorry for being a bit late, but I’m having some health issues and actually shouldn’t be in front of the screen at all. Anyway, since I already announced this, I wanted to put this up. Won’t be able to respond to feedback afterwards. Just so you know. I hopefully didn’t forget anything important :-S
The idea is as simple, as effective and provides a huge flexibility, the extended way even beyond usual modular concepts, because it would offer complex setup modulators as single abstract elements. All within the current GUI.
The elements of the modulation setup, that are available in all target areas, are the basic modulations (AHDSR, Envelope, etc.). So there is actually nothing more logic, than making potential modular modulation elements, once applied on some target, a - modulation set related - part of these basic modulations and make them this way available everywhere else in the modulation set.
The initial idea:
So the “MyBlabla”-thingies contain the individual parameters of the device, applied somewhere on the origin target.
Three important points to consider here:
- Multiple usages of a modulation within a modulation set refer to the exactly same, exclusive modulation device. Changes on one usage affect all others too.
- On the first call of a modulation (per calculation cycle), the calculation is performed and the results are stored. Every following call directly delivers the stored results only, without performing a new calculation.
- References to modulations are only available within their related modulation set, to keep saved modulation sets consistent.
Maybe there could also be some indicator, which targets are affected by changing the device parameters. I personally don’t think, that would really necessary, because the are only a few targets anyway.
Well, that’d actually solve most of the non-modular issues. Still it’d keep things kinda uncomfortable, because you can’t set dedicated ranges or operands with the single modules, can’t share modulations with modulations on multiple targets, etc…
The extended idea:
The extended idea is keeping everything like it currently is, and extend it by a modulation wrapper in the basic modulations. I’ve called that wrapper “Modulation Subset”. New Subsets can be added/deleted to a Modulation Set by simply clicking the “+/-” in the browser. Imagine Modulation Subsets it like a Doofer for modulations and/or a modulation setup for an abstract target. Though Subsets won’t need any macro buttons, because they’d have to be bound to the instrument macro anyway and therefore are redundant.
Example of an (opened) Subset usage on target “Volume”, combined with a “normal” AHDSR.
The expected behavior of Subsets would be exactly the same, like in the initial idea with applied modulations.
- Multiple usages of a Subset within a modulation set refer to the exactly same, exclusive Subset device. Changes on one usage affect all others too.
- On the first call of a Subset (per calculation cycle), the calculation is performed and the results are stored. Every following call directly delivers the stored results only, without performing a new calculation.
- References to Subsets are only available within their related modulation set, to keep saved modulation sets consistent.
Furthermore Subsets are able to modulate themselfes and other Subsets (within the same Modulation Set).
EDIT: And of course I forgot something important.
Usage of a strict modular concept: Use Subsets for everything.
Usage and keeping of the current concept: Just ignore Subsets.
Usage and mix of both mixed: … explains itself
- The Subsets would also make Bracket Devices obsolete.