V11 Poll: Do we need full automation compatibility mode?

[Chandlerhimself]

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.

I think the benefit is the added multiparameters. Now there are a lot of plugins with 4 MPs which doesn't allow people to much room to make interesting active presets. When I first started using Melda plugins I didn't understand why the easy screen even exsisted. I would always just go to the edit screen because the easy screen didn't have enough options. Recently however, with plugins like MTurboComp, I only use the easy screen active presets. All the parameters I need are there, but that is because MTC isn't limited by 4 MPs.

Although it seems like a lot of hassle IMO this will make things better in the long run. Hopefully this will get people to share presets more too.

[MeldaProduction]

Thanks for the feedback folks! I must say the results are just not as bright as I hoped for , so apparently a compatibility mode is just needed...

[DarkStar]

^^^^
Yep, it seems that a compatibility mode will be needed.

Going back to my MCompressor example: in v10 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 in v11 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

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, AND RUN IN COMPATIBILITY MODE those automation mappings will be mapped by the plug-in

• Host: "Threshold" (#005) to MCompressor: "Threshold" (#055)
  Host: "Multiparameter 1" (#012) to MCompressor: "Parameter 1" (#000)

It 'just' needs a remapping table in each plug-in

-----------------------------------
PS Vpjtech, I do hope that you will be dropping some of those other automation parameters. For example:
-- the 1,920 Band Voice Transformation parameters in MMultiBandGranular,
-- the 1,596 Band Shape parameters in MMultiBandFlanger et al,
-- the 3,408 Band Oscillator Shape parameters in MMultiBandRingModulator.

[Hanz Meyzer]

Vojtech, Maybe silly suggestion, but what about removing the "M" from all plug-in names of v11, so u simply can keep all v10 alongside v11? Also you wouldn't waste your time with crazy compatibility coding and you could change everything you prefer....

A real cut without hurting...

Personally I would prefer "melda compressor" over "melda mcompressor'. The vendor name isn't in the plug in name for most vendors. Normally the vendor string is enough, no?

Also you finally could rename mlimiter, etc.

What do you think about it?

[MeldaProduction]

Hey folks, thanks for the feedback again. Now automation compatibility mode already implemented, seems working fine, needs lots of testing though.

DarkStar: Yes, all these parameters removed, I need to go one by one and keep only what makes sense.

Hanz Meyzer: The M is vital, it's the trademark .