However the big question is automation - the new version should have more multiparameters, listed as first automation plugins, then the plugin settings, but settings for modulators/multiparameters/MIDI won't be automatable directly, since they are rarely used and some hosts have problems with so many automation parameters. This however means that the order of automation parameters will be changed, so if you automated something in previous projects, the automation will probably be assigned to a different parameter, depending on the host. Some backward automation mode could be possible, but it's extremely tricky to make. So my question is simple: do we need it? If you don't automate, sure you don't. If you do automate, but once you finish your project, there's only a small chance you'll have to get back to it in the future, you don't need it either.
V11 Poll: Do we need full automation compatibility mode?
-
MeldaProduction MeldaProduction https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=176122
- KVRAF
- 14339 posts since 15 Mar, 2008 from Czech republic
Ok, so far 2 rather more hardcore proposals were denied
. As a result, there won't be any compatibility break when it comes to plugin settings, no plugins will be removed / renamed.
However the big question is automation - the new version should have more multiparameters, listed as first automation plugins, then the plugin settings, but settings for modulators/multiparameters/MIDI won't be automatable directly, since they are rarely used and some hosts have problems with so many automation parameters. This however means that the order of automation parameters will be changed, so if you automated something in previous projects, the automation will probably be assigned to a different parameter, depending on the host. Some backward automation mode could be possible, but it's extremely tricky to make. So my question is simple: do we need it? If you don't automate, sure you don't. If you do automate, but once you finish your project, there's only a small chance you'll have to get back to it in the future, you don't need it either.
However the big question is automation - the new version should have more multiparameters, listed as first automation plugins, then the plugin settings, but settings for modulators/multiparameters/MIDI won't be automatable directly, since they are rarely used and some hosts have problems with so many automation parameters. This however means that the order of automation parameters will be changed, so if you automated something in previous projects, the automation will probably be assigned to a different parameter, depending on the host. Some backward automation mode could be possible, but it's extremely tricky to make. So my question is simple: do we need it? If you don't automate, sure you don't. If you do automate, but once you finish your project, there's only a small chance you'll have to get back to it in the future, you don't need it either.
-
- KVRAF
- 10376 posts since 2 Sep, 2003 from Surrey, UK
There's nothing like an example to clarify my thinking:
Take, as an example, MCompressor; its automatable parameters are:
Parameters 0016..0337 will be dropped, new Multiparameters will be added (MPs) and the MPs will be first in the list. So we would then have:
Have I got it right so far?
Now, let's say I have automated Threshold (#005) and Multiparameter 1 (#012) in the v10 plug-in. When the v11 plug-in is loaded, those automation mappings will be mapped to "Parameter 6" and "Parameter 13". That is (I understand) because the host only knows about the automation parameter index, not its name).
But all is not lost. There are (at least) 2 ways to get the mappings sorted out:
(a) in the host:
-- create empty automation envelopes for Parameter 1 (#000) and Threshold (#055),
-- copy envelope #012 to #000 and envelope #005 to #055,
-- delete envelopes #012 and #005.
(b) in the plug-in:
-- open (Multi)Parameter 6
-- select Threshold as the only parameter that it controls,
-- open (Multi)Parameter 13
-- select (Multi)Parameter 1 as the only parameter that it controls.
Method (a) sounds easier to me.
(Again, not gloating: Reaper project files can be edited - I could probably just change the envelope line, e.g. from <PARMENV 12 0 1 0.5 to <PARMENV 0 0 1 0.5 )
Take, as an example, MCompressor; its automatable parameters are:
Code: Select all
0000: (0.500) 0.00 dB Gain
0001: (0.500) 0.00 dB Output gain
0002: (0.316) 10 ms Attack
0003: (0.473) 50 ms Release
0004: (0.100) 1.0 ms RMS length
0005: (0.495) -12.0 dB Threshold
0006: (0.205) 1.80 : 1 Ratio
0007: (0.000) Hard Knee mode
0008: (0.250) 25.0% Knee size
0009: (1.000) On Link channels
0010: (0.000) Off Maximize to 0dB
0011: (0.000) Off Custom shape
0012: (0.500) 50.0% MultiParameter 1
0013: (0.500) 50.0% MultiParameter 2
0014: (0.500) 50.0% MultiParameter 3
0015: (0.500) 50.0% MultiParameter 4
0016: (0.500) 0.00 dB MultiPar-MultiPar1-Value
0017: (0.500) 0.00 dB MultiPa-MultiPa1-MaxValu
0018: (1.000) 100.0% MultiPar-MultiPar1-Range
0019: (0.129) 1000 ms Multi-Multi1-SwitcTime
...
0337: (1.000) On MultiPa-MultiPa4-EnabledCode: Select all
0000: (0.500) 50.0% Parameter 1
0001: (0.500) 50.0% Parameter 2
0002: (0.500) 50.0% Parameter 3
0003: (0.500) 50.0% Parameter 4
... << let's say another 46 MPs were added >>
0049: (0.500) 50.0% Parameter 50
0050: (0.500) 0.00 dB Gain
0051: (0.500) 0.00 dB Output gain
0052: (0.316) 10 ms Attack
0053: (0.473) 50 ms Release
0054: (0.100) 1.0 ms RMS length
0055: (0.495) -12.0 dB Threshold
0056: (0.205) 1.80 : 1 Ratio
0057: (0.000) Hard Knee mode
0058: (0.250) 25.0% Knee size
0059: (1.000) On Link channels
0060: (0.000) Off Maximize to 0dB
0061: (0.000) Off Custom shapeNow, let's say I have automated Threshold (#005) and Multiparameter 1 (#012) in the v10 plug-in. When the v11 plug-in is loaded, those automation mappings will be mapped to "Parameter 6" and "Parameter 13". That is (I understand) because the host only knows about the automation parameter index, not its name).
But all is not lost. There are (at least) 2 ways to get the mappings sorted out:
(a) in the host:
-- create empty automation envelopes for Parameter 1 (#000) and Threshold (#055),
-- copy envelope #012 to #000 and envelope #005 to #055,
-- delete envelopes #012 and #005.
(b) in the plug-in:
-- open (Multi)Parameter 6
-- select Threshold as the only parameter that it controls,
-- open (Multi)Parameter 13
-- select (Multi)Parameter 1 as the only parameter that it controls.
Method (a) sounds easier to me.
(Again, not gloating: Reaper project files can be edited - I could probably just change the envelope line, e.g. from <PARMENV 12 0 1 0.5 to <PARMENV 0 0 1 0.5 )
-
- KVRAF
- 10376 posts since 2 Sep, 2003 from Surrey, UK
If I am right, they will be moved to the start of the automation list, but you should be able to fix them, as above.jmg8 wrote:No problem for me, I only automate MPs anyway. I assume this will not be affected?
- KVRian
- 1094 posts since 23 Sep, 2006
Most of my automation is done with multiparameters so it shouldn't effect me. I'm not quite sure what the benefit of doing this change and potentially breaking backwards compatibility is though. I mean, whatever it is should really be worth it if its going to cause people headaches.
-
- KVRAF
- 10376 posts since 2 Sep, 2003 from Surrey, UK
In my view, at least two good reasons:
a) remove all those unnecessary automation parameters, which can trip up some hosts,
b) add more Multiparameters - giving us much more flexibility for control of parameters (parameter intervals and ranges, switches, switchable banks) when it cannot be done in the host.
a) remove all those unnecessary automation parameters, which can trip up some hosts,
b) add more Multiparameters - giving us much more flexibility for control of parameters (parameter intervals and ranges, switches, switchable banks) when it cannot be done in the host.
-
- KVRist
- 137 posts since 31 Jan, 2006
As stated before in another thread, for my audio post workflow it's like Hiroshima and Nagasaki on the same day.
It would be okay for me if I could have version 10 and 11 installed in parallel. Everything else is a complete disaster for me.
It would be okay for me if I could have version 10 and 11 installed in parallel. Everything else is a complete disaster for me.
SOUND!
- KVRAF
- 2702 posts since 9 Jul, 2015 from UK
Its not clear if it would affect this yet? I'm not sure if the current MPs will change their order and break the automation or not. Hopefully Vojtech can confirm this.vectorwarrior wrote:Most of my automation is done with multiparameters so it shouldn't effect me. I'm not quite sure what the benefit of doing this change and potentially breaking backwards compatibility is though. I mean, whatever it is should really be worth it if its going to cause people headaches.
Jason @ Melda Production
-
- KVRist
- 243 posts since 17 Sep, 2006
What about a compatibility button within every plugin. You exactly know which parameter will be remapped to which new number, right?
Lets say Parameter 3 in V10 was "Gain" and I automated it. However in V11 Gain is Parameter 87 now.
So how about adding a button within the settings of each plugin saying "V10 automation compatibility mode"
Now what it does would be: When activated and the host tells the plugin to automate Parameter 3 it will internally remap that to 87.
So when you open and old project and things seem somehow "off" just go through all plugins and activate "V10 automation compatbility mode". As your plugins can communicate with each other, you could maybe even switch all plugins in a project to compatibility mode on demand.
If you use some sort of pattern, like add 64 multiparameters after parameter 10, internal remapping would be simple math.
Of course you also want to drop some parameters, but I dont know how often those were used anyway. Personally I mainly automate: "
Bypass, Gain, Volume, Panning, Filter Frequencies und such basic stuff. I can't remember I have ever automated midi or modulators directly.
Other idea:
Couldn't you just leave the first about 100 parameters (which are the most important as far as I remember) as they are, then add more modulators and drop the rest? That way most automation would be backwards compatible without doing anything. Backward compatibility would only break if you automated something really fancy...
Actually
Lets say Parameter 3 in V10 was "Gain" and I automated it. However in V11 Gain is Parameter 87 now.
So how about adding a button within the settings of each plugin saying "V10 automation compatibility mode"
Now what it does would be: When activated and the host tells the plugin to automate Parameter 3 it will internally remap that to 87.
So when you open and old project and things seem somehow "off" just go through all plugins and activate "V10 automation compatbility mode". As your plugins can communicate with each other, you could maybe even switch all plugins in a project to compatibility mode on demand.
If you use some sort of pattern, like add 64 multiparameters after parameter 10, internal remapping would be simple math.
Of course you also want to drop some parameters, but I dont know how often those were used anyway. Personally I mainly automate: "
Bypass, Gain, Volume, Panning, Filter Frequencies und such basic stuff. I can't remember I have ever automated midi or modulators directly.
Other idea:
Couldn't you just leave the first about 100 parameters (which are the most important as far as I remember) as they are, then add more modulators and drop the rest? That way most automation would be backwards compatible without doing anything. Backward compatibility would only break if you automated something really fancy...
Actually
-
- KVRian
- 509 posts since 28 Oct, 2012 from Argentina
Isn´t this discussion over? viewtopic.php?p=6717173#p6717173
-
- KVRist
- 243 posts since 17 Sep, 2006
The discussion for the "hardcore proposals" yes. However Vojtech is now considering a compromise to at least reduce the number of multiparameters in V11 as he wrote in the first post of this thread...
- KVRAF
- 2702 posts since 9 Jul, 2015 from UK
Increase the amount of multiparameters and reduce the amount of automatable parametersAlphacodex wrote:The discussion for the "hardcore proposals" yes. However Vojtech is now considering a compromise to at least reduce the number of multiparameters in V11 as he wrote in the first post of this thread...
Jason @ Melda Production
- KVRAF
- 5391 posts since 25 Jan, 2014 from The End of The World as We Knowit
My host does not have problems with automating Melda parameters.
Which hosts have those problems, and are thus responsible for this new proposal??
Shouldn't those hosts get the upgrade?
Which hosts have those problems, and are thus responsible for this new proposal??
Shouldn't those hosts get the upgrade?
F E E D
Y O U R
F L O W
Y O U R
F L O W
-
- KVRian
- 509 posts since 28 Oct, 2012 from Argentina
Ah, thanks for clarifying.Alphacodex wrote:The discussion for the "hardcore proposals" yes. However Vojtech is now considering a compromise to at least reduce the number of multiparameters in V11 as he wrote in the first post of this thread...
-
- KVRist
- 243 posts since 17 Sep, 2006
Ah yes, sorry:
- Increasing multiparameters
- Reducing seldom used MIDI and Modulator parameter it was
- Increasing multiparameters
- Reducing seldom used MIDI and Modulator parameter it was
