Poll V11 #2: Removing automation backwards compatibility

[jmg8]

I always use multiparameter when automating, because it means you can quickly give an automation clip a different function, without having to make new automation clips.

Me too. I only automate multiparameters. Lets say you want to change a parameter by a very small amount, it can be very tricky to draw in the automation lane. Its nice to have the full range in the automation lane to draw from max to min. Multiparameters allow us to do this and at any time we can go back and experiment with ranges, parametrs, transfer curves etc without disturbing the automation.

[zeep]

Live user here.
I automate EQ bands all the time (MDynamicEQ) aswell as wet/dry. (v7.09)

Should i update to the latest version, how will this change affect my old projects?
Will all automation be gone?

[pone]

I guess the real vote will start when the change is implemented and if angry emails come or not.
Normally there is an email notification on important melda polls, so maybe it's too early to panic/celebrate.

How about we have an option to launch the plugin in an "Integrated mode" with only 100 multiparmeters. Have it On by default and give a warning dialog about zero future backwards compatibility.
I believe, since we're breaking backwards compatibility anyway, with the "Integrated mode" off do what ever that's needed to parameter ranges, list orders etc., but still let us have direct access to that list.

Otherwise, what would be the purpose of buying anything but MXXX then? (a few more bands in AutoDynamicEq? ) It has everything* and in the exact same way and even better (which also includes powersynth).

I don't believe adding an additional abstraction layer helps usage.
The edit screen has a graphical representation and parameters placed where they should be. The easy screen is a bunch of knobs with names on them. If the answer to that is staying in the edit screen, then the additional binding has almost no benefit but the opposite.

EDIT: this also means that the only undo that would work is the undo button in the plugin

[pone]

Live user here.
I automate EQ bands all the time (MDynamicEQ) aswell as wet/dry. (v7.09)

Should i update to the latest version, how will this change affect my old projects?
Will all automation be gone?

I don't think (don't remember) any backwards-compatibility-breaking changes happened to MdynamicEQ since v7 (the current version is 10.07). I highly advise that you update.

You can just download it and see or read through https://www.meldaproduction.com/changes/

[Tagirijus]

Otherwise, what would be the purpose of buying anything but MXXX then? (a few more bands in AutoDynamicEq? ) It has everything* and in the exact same way and even better (which also includes powersynth).

To me it is simple: I do not want to load MXXX and then load the correct module into MXXX, when I just need a compressor for example (in FL Studio the workflow is "open plugin picker + drag the correct plugin" versus "open plugin picker, drag MXXX, click on a free module slot + choose the correct plugin"). So to me it is mainly a different workflow. MXXX is very great for getting creative (at leats to me). I use it, if I need more creative things - not mixing related.

[alexis1]

Otherwise, what would be the purpose of buying anything but MXXX then? (a few more bands in AutoDynamicEq? ) It has everything* and in the exact same way and even better (which also includes powersynth).

To me it is simple: I do not want to load MXXX and then load the correct module into MXXX, when I just need a compressor for example (in FL Studio the workflow is "open plugin picker + drag the correct plugin" versus "open plugin picker, drag MXXX, click on a free module slot + choose the correct plugin"). So to me it is mainly a different workflow. MXXX is very great for getting creative (at leats to me). I use it, if I need more creative things - not mixing related.

Cost. Simplicity (as mentioned above). And backwards compatibility is valued for a reason.

Removing automation, and backwards compatibility, seems like a bad idea, including from a marketing point of view.

Signed,

Just a non-sound designing low tech user who wants basic audio tools - thus owns MTransient, MAutoDynamicEQ, Mcompressor, MautoVolume, and MCompare, and has no desire for a behemoth-can-do-it-all plug-in (I'm guessing not the typical marketing target for Melda products?)

[MeldaProduction]

Thanks for the feedback folks. It's necessary to say, that the changes would happen only for plugins with easy screens probably. Anyways too many are against so... But it will probably implemented anyways with an option for backwards compatibility. Damn... I was hoping we could let the past be past .

[steve2KVR]

...mmmmmmmmm...."Damn... I was hoping we could let the past be past ." ...so don't ever, ever, ever have anything to do with RDB design/implementation/management/support so you can have a happly life! ...jmho.../s~

..."if it weren't for the end users and management supervision, it was a great project..."

[Tagirijus]

Cost. Simplicity (as mentioned above). And backwards compatibility is valued for a reason.

Removing automation, and backwards compatibility, seems like a bad idea, including from a marketing point of view.

Signed,

Just a non-sound designing low tech user who wants basic audio tools - thus owns MTransient, MAutoDynamicEQ, Mcompressor, MautoVolume, and MCompare, and has no desire for a behemoth-can-do-it-all plug-in (I'm guessing not the typical marketing target for Melda products?)

SO I might not get your point here as well. I mean: you do not have to buy MXXX, if you just need a simpler tool. So what is the problem exactly?

[DarkStar]

So that we do not have to rush, is there anything we can do to prepare for the v11 Automation?

-- Will all plug-ins (except the ones in the Free FX Bundle) get the "100 automation parameters"?
-- Do I understand correctly that all existing parameters will still be available in the Multiparameter and Modulator windows, for selection?
-- And that all existing parameters will still be available in the MIDI Settings / Controllers and Notes (and, therefore, could still be automated using MIDI CCs/Notes)?

[chroma]

i don't do a lot of automation (more live things)... but couldn't you just have the 100 multiparameters mapped automatically to the first 100 parameters by default (either the default preset, or done automatically when importing/loading an old preset)? then the IDs would be the same, the names would still be the same, the user could change them later to make their own presets, and old automation would still work even though technically it was automating a multiparameter now.

don't know how to handle parameters >100 if there are common cases where those would be used... that + DarkStar's idea would go a long way to providing backwards compatibility while reducing the large number of parameters....

[mike_the_ranger]

Would the automation list display the names of the parameters or "MultiparameterXXX"?

[DarkStar]

The names that you type in on the Multiparameter windows (as long as your host picks them up, dynamically).

[MeldaProduction]

i don't do a lot of automation (more live things)... but couldn't you just have the 100 multiparameters mapped automatically to the first 100 parameters by default (either the default preset, or done automatically when importing/loading an old preset)? then the IDs would be the same, the names would still be the same, the user could change them later to make their own presets, and old automation would still work even though technically it was automating a multiparameter now.

don't know how to handle parameters >100 if there are common cases where those would be used... that + DarkStar's idea would go a long way to providing backwards compatibility while reducing the large number of parameters....

That is problematic, because changing parameters doesn't change multiparameters, after all a single multiparameter can change multiple parameters (hence the name ).

[chroma]

That is problematic, because changing parameters doesn't change multiparameters, after all a single multiparameter can change multiple parameters (hence the name ).

well, yeah, but this is just for backwards compatibility....

so, if the user already has automation to, let's say, the gain of eq band 3, and that's (say) ID 41.

you can make this still work by making the tool come up with the first 100 parameters now the multiparameters mapped to those parameters - i.e. ID 41 is now a multiparameter that is controlling the gain of EQ band 3, and the automation still does what the user expects.

obviously, if the user tweaks EQ band 3 manually, this will get out of sync (because the multiparameter no longer matches the actual parameter value), but old sessions will still work. and probably in the GUI this would be a little more obvious.

but that brings up another question... how does recording automation work with multiparameters? now, they are explicit, but e.g. if I want to record changes to gain 3, the few times I've done it I just grab the gain for band 3 in the GUI and change it, and the automation records it. today, if I want to change a multiparameter, of course I can do that, but in this model there aren't that many 'normal' parameters left - i'd have to use a multiparameter to change the gain on band 3, and in that case, will the GUI make sure that this workflow still does something useful?