Quote:
Originally Posted by fundorin
So, I think that that's why Geoff came with an idea of "widgets" in chain
real_knob1<>widget[x]<>fx_param1.
Users doesn't map MIDI CC values to the FX parameters. They map widgets to them. And, inside the main script, CCs are mapped to widgets.
|
It is clear that MIDI should be separated. The question, what widget[x] is:
* ACT style: global widget[ctl_type][n] , where ctl_type is button/knob/slider, n is just index in ordered list
+ per surface widget[ctl_type][i] , where i is user definable. Initially n==i, but user can change that per surface.
* simple style widget[x]
* ??? somehow tree based, widget[fx_type][x] where fx_type is EQ_4BAND/EQ_6BAND/Comp/Comp_4BAND.
Or something more complex, fe. widget[EQ_Comp_Stip][EQ][LF][x]
Quote:
Even if you have prepared track templates with, let's say, ReaEQ and ReaComp loaded, some of your tracks would have them in "slots" 1 and 2 (audio tracks and folders), while others in "slots" 2 and 3, cause "slot" 1 in used for instrument plugin. Or, "slots" 3 and 4, cause "slot" 1 is for midi arpeggiator.
|
That was the problem with Sonar ProChannel, once they have allowed to change the order of modules (originally, EQ was always the first and Comp always the second).
Since I had no general solution for mapping, in particular case we was solving that by hard-coding:
* EQ just had to be found by name (there is only one EQ in ProChannel)
* Compressor had to be also found by name, assuming we want control the first and giving explicit priority list, f.e. PC76/PC4K/CA2A
Doing so (to be clear, that is working in Sonar thing), while it was not difficult (AZ Controller is an interactive system, not script), I have found the procedure rather boring and not scalable for not ProChannel case. That was the first time I have started to seriously think how that can be done better.
Quote:
There won't be any standard ever.
|
Till someone invents some amusing approach and everyone else follow