Poll V11 #2: Removing automation backwards compatibility

[MeldaProduction]

But still, it's a good sample. And I sort of have an alternative solution in mind already .

[pumafred]

Hey Vojtech: I just discovered you can cheat in your poll.
It says "You may select up to 5 options", when it should be "one of 5 options".
I just tried it, and I added another vote for the closest option I had already voted!
I will delete this. No need to cheat.

[DarkStar]

... how about my questions?

Also, I cannot see how a compatibility mode could work. it would mean having two chunks of code, one for each Automation method, for ever. And it would meaning keeping all
the current parameters as VST parameters (otherwise the DAW will not pick up the correct name or may ignore parameters or run into other problems), defeating the objective.

[Batty]

Is one still able to connect hardware in 4 steps?
1. choose hardware to connect
2. turn knob that shall be used to make it learn
3. turn knob on hardware to learn it to connect to knob on software
4. use

as long as it doesn't get more complicated in the future then that, I'm ok with it.

[DarkStar]

^^^^
That's down to your DAW isn't it, not the plug-ins? Or did you mean the plug-ins' MIDI / MIDI Settings / Controllers/ Learn feature?

[Nicolaibob]

I think it is a great idea to break backwards compatibility. But i would suggest you to think more thorowly about it. I.e. why not - if you break backwards compatibility anywy, don't you just make it possible to have both pre version 11 and post version 11 installed. An possibly it could be widely accepted if you also predefines the 100 multiparameters to the most widely used automated parameters.

And then at the same time, changed the name of mLimiter to mSaturator

And reduce the amount of plugins, by removing alle the none-multiband versions (where multiband versions exists) and instead makes it a about having a license to enable multiband instead of wideband functionality. i.e only have a MSaturator, where a licensing option could enable adding more bands.

And likewise, make "auto" functionality also about activating it via a licensefiles, thus i.e. having only a "DynamicEq, where activating a license would enable the "Auto" feature.

And combining some of the "similar" effects like the different equalisers and dynamic processors into a few, where (again) som extra functionality, like "freeform editing" and "Analog" and "LinearPhase" through licensing files - instead of different "plugins". This might even allow for customers to purchase something like the "MTotalEQ" licensing optionpack, and the "MTotalDynamics" optionpack etc..

Just some thoughts... Hope they makes sense.

Nicolai

[ZentralmassivSound]

I'd very much prefer if there would be some solution to at least show what parameter was automated in older projects. I use automation a lot and if everything in existing projects just stops working, that would be really terrible. Some way to reuse the legacy automation data and reassign it via MP maybe.

[dmbaer]

There’s an old software development joke:

Q: How could God create the world in just seven days?
A: No installed user base.

OK – I didn’t say it was a good joke!

But it does highlight one of the fundamental frustrations of creating software. Just about the time you start understanding the problem well enough to craft a brilliant solution, you can no longer implement that solution due to violations of backward compatibility.

So, I don’t think you can just flat-out change things that will invalidate your user's existing DAW projects. What you can do, however, is freeze the M-series of plug-ins – no more or only minimal changes. Then launch a series of replacements. Leave, e.g., MTurboCompressor as is. But add, e.g., XTurboCompressor to the line-up (the “X” for “extended” or “extra-cool” or whatever). XTurboCompressor could be as different from the original as is needed to maximize the coolness factor imparted by this one-time added freedom. You would not need to do a wholesale replacement either. Just start adding the X-series plug-ins one at a time as they become available.

XXXX - can't wait!

[wildcafe]

Let's make an example: you'd like to modify a frequency of MFilter. I'm Ableton Live user.

Situation NOW:
I'm opening the plugin GUI, touch the cutoff frequency with the mouse, the parameter shows up in Live's arrangement and I can draw in the arrangement of Live an automation curve immediately.
Oh then, I'd like to automate the resonance. Same thing: opening plugin, touching it, drawing automation curve. Fine.
Perfect workflow. Nothing to do else (like assigning anything to anything before I can draw a curve). This works with any parameter in most of plugins I use (from NI through Waves to iZotope etc.).

Situation after removing automation:
Version 1: I have to open the GUI. I have to open a modulator. I have to search the parameter I'd like to automate. I have to set correct value ranges so that the automation does a good job and have to do a lot of brainwork.
Version 2: selecting "Clear & Learn", moving the frequency, opening the modulator, checking correct ranges, closing it again. Drawing the curve in Live.

I'd not like to see this change, because it's a pain, if you'd like to automate many parameters. In addition how would you show 10 multiparameters in a user friendly way (beside the other parameters)?
As a user I can't see really the benefit of removing automation of parameters. For me as a user it's perfect as it is. And it's pretty industry standard.

What's happening, if you "just implement changes"?
Let's say Vojtech would like to extend the max. delay time in MFlanger from 20ms to 200ms. What's happening then in your projects with older versions of the plugin? If you automated it to go from 10ms to 20ms, it will go then from 100ms to 200ms (as the automation curve is the same, but the range changes). It could mess up things. But how often does this happen?

Compromise solution:
How many parameters are affected? I think it's not so many...
Maybe we should have a parameter-changelog window in each plugin telling us, which parameters have been modified over time. In addition enhanced with a factor to convert values from old to new.

So if I realize, there's anything sounding strange in a project on a track, I open this changelog and see if there has been a change to an automated parameter which I can then adapt.

Would be the best solution for me to get the best of old and new...

[Batty]

Darkstar: I meant both...at the moment I use this from the Daw, but as I understood - this possibly will get broken in v11 (plugin midi report to daw being taken away). I hope I just misunderstood things and wanted to be sure that this kind of control is still available - in or outside the plugin - and doesn't get more tedious then these 1-4 points.

[DarkStar]

Here's an idea to think about (it might be a halfway-house to the proposal that Vojtech put forward):

Remove from all the plug-ins only those VST (that is, automation) parameters relating to:
-- Modulator properties (many parameters),
-- MIDI Controller properties (Value, MaxValue, Enabled, Invert, Range),
-- MIDI Note Controller properties (Value, MaxValue, Enabled),
-- Multiparameter properties (Value, MaxValue, Interval etc).

All of those properties are valuable in configuring the plug-ins' behaviour but I would not expect that many people (anyone?) often automates them. The big advantage is that most existing automation of the other parameters is not affected.



Please note that this is for the automation parameters only (those identified to the host);they would remain as internal parameters.

In addition, further parameters could be completely (?) removed from individual plug-ins; some candidates are:
-- 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.

With just those changes:
MMultiBandGranular would drop from 3,318 VST parameters to 474 + the Multiparameters.
MMultiBandFlanger would drop from 2,756 VST parameters to 234 + the Multiparameters.
MMultiBandRingModulatorr would drop from 4,424 VST parameters to 90 + the Multiparameters.

What do you guys think?

[masitito]

What do you guys think?

Sounds reasonable.

But still, if it's not too hard to implement I would love to see this happen for 11.x onward. Plus the option to install the new 11.x plugins parallel to the old 10.x plugins.

a) just in case and b) you can remove more parameters without having to worry about old projects and sorry customers.

Masi

[pone]

Guess it's time to save those installers and bookmark the archived versions, heh.
What are we trying to fix again? What's wrong with just adding new parameters to the end of the parameter list? Surely if a host is problematic that's the host's problem.
Might as well just make MXXXcore free and make everyone use that instead if they have problems.

my 2 cents

[_al_]

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.

[Hanz Meyzer]

Well, I can imagine it would be a pain in the ass, if you change the vst automation parameters for people who based their work on this. I personally know 3 people. And all these people find this a horror, so I speak for them here a bit:

In general I find the meta concept also better, but would have to be very easy to setup then. More easy than now.

So I would like to suggest on the following:

- Provide a mapping dialogue, so you can on-the-fly map missing parameters, if V11 detects a song which used V10... So an automation in a DAW won't be lost.

- Use variable/flexible vst parameters. So if I song is detected made with an V10 version, V11 would switch to compatibility mode and provides the old parameter list. So provide a backwards meta setup list.

- Allow installing V10 and V11 side-by-side. And also at least do some future bug fixing for V10.