Hi guys. I have a problem.
I save an Ableton project with MG2 and MB VST plugins.
Each plugins is set to use custom patch.
After saving the project and loading it back - patch name becomes default for both plugins.
Most of the settings remain the same though, at least visually. That could be a minor problem, however, Noise gate parameter while being visually the same - seems to be actually reset to some default value de facto. Therefore its not just a cosmetic issue, it directly messes up basic functionality.
For example, I save the perfectly fine project, my Bass plugin tracking works fine with a noise gate setting tuned specifically for my case. After loading project I’ve just saved - Bass plugin starts to make a lot of false triggering. I move Noise Gate slightly - not like really changing something seriously, just enough to reapply the value - and since that moment noise gate starts to function correctly and false triggers are gone.
Seems like internally noise gate value is not restored correctly on the project load, and goes to default state.
I cannot yet reliably determine if MG2 has the same noise gate issue, as it’s tracking is much more forgiving in general and it is harder to reproduce that obviously, but as soon as patch name loss is the same, I can assume that MG2 tracking might be affected the same way, silently loosing noise gate settings on project load.
That’s really a frustrating issue, as I have to tweak projects by hand each time I load them. Doing that several times a day, not an experience I had expected for the price tag.
I’ve recorded video that demonstrates the issue.
I run the same prerecorded audio clip through MB plugin to exclude any human error introduced by the live playing.
You can see the following in the video:
Project is fine, patch is saved, tracking works.
I reopen the project - patch name is lost, MIDI tracking becomes mangled until I tweak a noise gate again by the smallest margin, or reload patch manually.
Also you can notice another bug, that I cannot save patch under the name I had already used in previous sessions.
The plug-in is out of date
This may occur after an operating system update, where the version of the plug-in is not fully compatible with the new OS. The state of a plug-in is stored in a reserved binary data block in a Live set. This binary data block can only be read or written to by the plug-in itself.
Usually re-installing the plug-in will resolve the issue.
Make sure to download the most recent version from the manufacturer’s website - copies installed from DVD or USB may be out of date.
We recommend installing plug-ins to their default system locations using our guidelines on Windows and Mac.
here’s another option (you’ll lose all of your settings though):
My main setup is: Ableton Live Intro 11.3.13 Windows 10 Pro 22h2
After some tests, I see that it behaves the same way on my another Windows laptop, with Ableton Live Intro 11.3.13 Windows 11 Home 22h2.
Live Set (project) had been created from the scratch on that second laptop, therefore it is not something specific to that Set state or laptop.
I’ve tried removing items from that Acustica Audio article with no luck.
I’ve shared the wav sample I am using for this test here, to ensure that issues can be reproduced:
Used first two notes from the sample for the test.
I have to use quite high noise gate value to get rid of the false triggers for this sample.
P.S, I would like to notice, that I use Midi Bass for these tests.
While Midi Guitar is resetting patch name to “Default” as well, I cannot tell for sure if it there is a same problem of noise gate really behaving differently on project load - at least because MG tracking tolerance to the noise gate setting is much higher, allowing it to work in different noise gate positions, so the same problem can be just be unnoticed, even if MG loses the setting value (which is probable due to the assumed shared code base)
it seems possible that your primary issue is with ableton, even though you have two systems with the same issue.
i don’t have a system free to install live lite 11, otherwise i’d try to replicate this behavior.
i think reinstalling to one of ableton’s specified vst folders is worth a try.
VST2 devices do not have a default dedicated installation path. Instead, most manufacturers allow a path to be selected during installation. Unless there’s a specific reason otherwise, VST2 devices should be installed to one of these locations:
If possible, use the same folder for all VST2 plug-ins. Note the location selected during installation, as you’ll need to specify this when activating plug-ins in Live.
I guess we can take Ableton out of the equation.
I had replicated the same in Reaper (again on the both laptops)
Different machines, different OS variants, different audio cards, different DAWs, different VST folders.
For now the only common denominator I see is Midi Bass.
If I create a patch within daw project, save-as it, let’s say as PATCH1
Save the project
Load the project, getting that loaded “DEFAULT” patch
Save “DEFAULT” patch as PATCH2
“.opatch” Files for PATCH1 and PATCH2 are really identical.
Therefore it means DAW passes values correctly to the MB VST plugin, except for the patch name.
MB really receives all that data from the DAW.
However, noise-gate does not function correctly until we move the knob.
To conclude - looks that DAW passes all the parameters correctly, but plugin does not initialize something internally (most probably noise-gate value) on startup anyway.
Hey there!
I am away from my studio for a couple of days, so I can’t really help you right now. I checked with my setup Mac, Abelton and AU and I didn’t have any of those issues. But obviously we are talking about the vst version. Working with Abelton I have experienced a number of issues with the vst version, so I simply opted to use what worked.
I am not really shure how severe this bug is, but I believe @JamO will focus on getting MG3 out first, before adressing this. I will take a look at this when I get back myself, but the most you can expect from me is just a confirmation that there is an issue with the vst and Abelton.
the patches that are saved in MG patches on disk are separate from the info that is loaded when a plugin is initialised in a host.
You must imagine that the current patch data is stored in the host, and that may vary from the data in the .opatch file. (you could have twisted a knob after the last time you saved a patch within MG)
To retrieve the plugin state, the host issues a call into the plugin, asking for the data.
MG2 does not add the patchname to the data, so that is why that is not updated, when the host restores the plugin state, and still displays the confusing “default”. The rest of the data is restored however.
Noisegate
The noisegate is host automation enabled, but automation is broken in MG2.
This means that if you once set the MG noisegate from ableton instead of inside MG, this automation will be stored in the Ableton, and resend to the plugin after initialisation. So better never use the remotes, only change data within MG gui itself!
Now whether in your case the automation bug applies, I dont know, but I thought I’d better tell you more of the whole story. If you did alter the noisegate from the Ableton gui remotely, please try a fresh channel with a fresh MG to test, and do everything in the MG interface.
If you did not touch the autmoation remote noise gate knob in Ableton, then the bug is somewhere else.
Did not touch them. As well as on a second laptop where issue reproduced from the scratch without anything taken from the first one, and also without touching these sliders.
As for Reaper I do not even have a slightest guess where these remotes can be, and reproduced the issue from the scratch as well starting with an empty project using MB interface only as shown in a second video. I doubt I could enable something automation related automatically there.
Anyway, that’s an interesting insight, thanks.
To retrieve the plugin state, the host issues a call into the plugin, asking for the data.
MG2 does not add the patchname to the data, so that is why that is not updated, when the host restores the plugin state, and still displays the confusing “default”. The rest of the data is restored however.
Suspected it to work that way, nice to get a confirmation.
Is that noise gate really a noise gate in it’s regular meaning or something exclusive for mg2 which only shares the name?
Maybe I could just throw in some noise gate plugin instead? (no big expectations here, but had to ask)
1)-the internal noise gate in MG itself is not a normal noisegate, it alters the probability edge of the tone recognition.
2)-the custom gate script is a script that can rule out lower veloctiy notes.
Putting a noise gate in front of MG will have no positive effect, since the internal gate (recognition) will have less signal to work with (the edge where the gate opens will introduce new artefacts), and still will produce false early notes, most low velocity.
Yep. Looks you are right. It is fundamentally broken. I mean, it works until I save the project, but after that - saved project cannot be loaded and crashes Ableton Live completely with 100% rate.
(Please notice that my original problem does not include any of the stuff below, I just used plugin gui and nothing else)
I was now exploring options to restore noise gate value externally, from clyphx, midi cc, whatever I can try to map and reset that value from outside the plugin, and bumped into that painfully, to the point when project is broken beyond repair and crashes Ableton Live.
Reproduces easily:
Put MG/MB into Effects Rack
map macros to any MB/MG control
rotate macros knob to change value to any other value
