Here comes the result of some thinking I did on Roberts questions. I´m basically suggesting lfos as part of the midi effects group, and a table of automation/modulation routing in the midi panel.
Robert Henke wrote:
A better system from a todays perspective would allow any parameter to be
controlled in a relative or absolute fashion by many sources, and therefore allow for things like:
-automation of parameters within a clip, and not just modulation.
( -> automation recording not just of MIDI CCs but all parameters from within a clip )
-more then one modulation source per parameter ( -> LFOs !!! )
-control of a single parameter from various sources with variable curves. ( e.g. macro controls )
This sounds all very exciting, and would improve Live dramatically. However, it
would be the one single most complex re-design of the software since version 1.0.
It would change not only the way the engine handles automation data, but would
also require new interface strategies. It raises questions like: Is there automation
in the clip or in the arrangement or both? If so, which one wins if you move/delete things?
depends: If you have the automation lock in the arrangement view on, arrangement modulation wins, if not, session view wins, no matter if you drag a clip from session to arrangement or viceversa. When there are no collissions, but different automated parameters, they should add up. I you dont want them to add up, you can previously delete all automation of one of the clips.
Robert Henke wrote:
"How to visualize multiple modulations?"
The following idea is being applied to the lfos, but they basically apply for the table of modulation routing as well. I´ll explain that more in detail later on.
If the lfo was just another "midi" insert, it could look like spectrum, with a table of buttons before the graph. If you have one lfo modulating another one, the first graph could display the its own wave, while the second could be displaying its own wave in one colour, and the result of the modulation of the two waves in another colour within the same graph.
The modulated parameter should be shown with the usual green frame but should maybe have an additional colour.
Robert Henke wrote:
"Can an LFO be modulated by itself?"
Yes, just duplicate it, and it will be modulating itself by default in a certain way. But there are switches that change the way of modulation: addition, subtraction, multiplication, division, exponential and square and a percentage amount behind it.
Robert Henke wrote:
"What happens at overdub?"
The lfos are of course not recorded, unless you choose to "flatten" them, meaning that they are transformed in an automation envelope. So the problem is: What happens when, at overdub, you record another automation via midi?
depends:
1. setting: User is playing absolute values. The lfo keeps on modulating in a relative fashion to the controller. The percentage of modulation can be previously set. This can be done in the midi panel at crtl+m .
When you set 0% of modulation, the controler is not modulated at all and completely overrules the lfos, at 100% the controller will have no effect.
If the controller picks up the automation at its current level, the transition in the automation from only lfos to midi and lfos would be smooth.
If the controller is meant to completely override the lfos, not picking the current value up as a starting point, there might be a necessity for a smooth transitions between the lfos and the controller input. This would involve another adjustable parameters, preferably similar to attack, decay, sustain, release. These parameters define how fast the controller takes over the lfos when it is moved and how fast the lfos take over when the movement of the controller stops. These parameters should come into the midi panel as well.
2. Setting: User is playing relative values: The user needs to be able to choose where in the chain of modulations he is inserting the controller modulation. For that purpose, the chain of automations could show up in the midi panel, visualized as icons with names like lfo 1, lfo 2, macro 1 etc. The user would then choose the position of the controller to between one of the modulations. By default the controller shows up as another little icon in front of all other modulations in the modulation chain, which means that this is the first signal in the chain.
------------------------------------
Those were, more or less, the questions Robert posted, and of course they are only a rough draft of all the problems that arise, which Im starting to realize that are maybe beyond me. Anyways, some further thoughts to round it up a bit:
Like Robert said, any automation parameter should be able to modulate any value and the best would be to be able to modulate any other automation parameter with it.
So as already outlined I would go for a table of modulation routing, which I would put in the midi panel. The midi panel will show you an automatetable parameter once you doubleclick on it while the midi panel is open. It will be displayed on the left hand side.
If there is already automation/modulation present through lfos, relative or absolute envelopes, macros or midi, this will be displayed on the right side of the automated parameter.
If there is more than one automation on one parameter, the Icons representing the automation will be ordered by their position in the modulation chain, effectively showing the modulation chain for that parameter. There should be some default order: first midi, then macros, then drawn automation envelopes, then lfos.
The table allows you to freely move around automation envelopes, midi and macro assignments, and lfos. You can also duplicate them and set up modulation whatever modulation chains.
Preferably the modulation curves would be represented by graphs similar to the lfos, adjustable in size.
Between each modulation step have to be the same modulation options that are in the chains of lfos, that I mentioned before: addition, subtraction, multiplication, division, exponential and square and a percentage amount behind it. Midi and macros may need also the aforementioned adsr envelope.
But you can not only set each modulation to an absolute or relative value by rightclicking an automation icon: You can also turn an lfo into an automation envelope, or an automation envelope into an lfo.
Since the user will also want to change the modulation routing while still being able to control clips and transport functions, the question arises if the midi panel is the right place for this, since as it is now, the midi panel only opens when you want to assign a certain parameter, hence you cant manipulate it in that moment, only assign it.
Maybe its actually better to have an independent panel for this. But you could also have another button that deactivates the assigning of midi so that you can freely press all buttons and clips in order to make them play instead of assigning them, while you are routing the modulation.
Is the extra button a flaw in the system?
I still think the midi panel would be the appropriate place to place this table of modulations, even though it might require an extra button. Because you are actually in the process of assigning controls, and when setting them up, it would be annoying to have to switch between an extra panel to the midi panel. You want to be able to look at all the controls, midi included. You could make it as simple as pressing ctrl+M+(another) M, disabling the assigning, then you´ll be able to change the modulation routings while using clips, transports, and even your already assigned midi controls.
What about macros? Macros have a double impact. They are, for one thing, also automatable parameters that can be controlled by lfos, midi, etc. But they are also an automation parameter for the affected value. Therefor macros have an input and an output side. The input side can be treated like midi values, the output side as any automatable parameter.
Ok thats it for now. I´d love any feedback, especially pointing me towards potential difficulties or impossibilities. At this point, I dont see any changes that wouldnt allow opening up old sets, nor other difficulties. But I´m no software programmer.
I'm all for user-initiated hacking, I should be, I've done my fair share of it - sorry if it came across otherwise. You get one of these:
.