V11 Poll: Do we need full automation compatibility mode?

Official support for: meldaproduction.com

Do you need full backwards automation compatibility for V11?

Yes
10
26%
Yes, but I'll survive
4
11%
No
24
63%
 
Total votes: 38

RELATED
PRODUCTS

Post

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.
Vojtech
MeldaProduction MSoundFactory MDrummer MCompleteBundle The best plugins in the world :D

Post

No problem for me, I only automate MPs anyway. I assume this will not be affected?
Jason @ Melda Production

Post

There's nothing like an example to clarify my thinking:

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-Enabled
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:

Code: 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 shape
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 )
DarkStar, ... Interesting, if true
Inspired by ...

Post

jmg8 wrote:No problem for me, I only automate MPs anyway. I assume this will not be affected?
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.
DarkStar, ... Interesting, if true
Inspired by ...

Post

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.

Post

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.
DarkStar, ... Interesting, if true
Inspired by ...

Post

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.
SOUND!

Post

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.
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.
Jason @ Melda Production

Post

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

Post

Isn´t this discussion over? viewtopic.php?p=6717173#p6717173

Post

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...

Post

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...
Increase the amount of multiparameters and reduce the amount of automatable parameters
Jason @ Melda Production

Post

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?
F E E D
Y O U R
F L O W

Post

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...
Ah, thanks for clarifying.

Post

Ah yes, sorry:
- Increasing multiparameters
- Reducing seldom used MIDI and Modulator parameter it was

Locked

Return to “MeldaProduction”