I’m having the same problem with V Collection X. Any suggestions on a resolution prior to me replacing VST3’s with VST2’s?
Well…confirmed the problem is isolated to a few Arturia plugins. Juno 8 is one I
am working with that exhibits the following behaviour across both VST2 and VST3.
- The patch loses what appears to be it’s patch settings and reverts back to a raw setting with no sustain or effects (and sharp attack).
- From Gig Performer 5 via monitoring I can see there is a Midi message on all VST plugins that triggers the loss of settings. I cannot see where it comes from and is not related to any midi devices attached (I have removed them all one by one and no change to the what I refer to as the “Midi Bomb”).
- The patch in the VST library goes from selected patch to an edited patch (* next to patch). This happens to all VST patches in the Rackspace though only changes “some” VST patches to exhibit the lose of settings. Eg. Augmented strings is not impacted by losing settings, but still shows the patch as edited.
- Going into the Library of impacted patches and selecting the original patch brings all settings back.
- I can sit, watch the Midi messages via monitoring and without touching any midi devices, the Mid Bomb executes and impacted VST’s lose their settings.
This makes a list (TBD) of impacted Arturia plugins (VST2, VST3, AAX) useless in Gig Performer and what appears to be Pro Tools.
To understand what the Midi Bomb looks like I need some form of Logging - does anyone know how to produce some form of Log file for the midi messages so we can understand what is in the Midi Bomb that is triggering the loss of Settings across multiple Arturia plugins?
For debugging purposes, what if you delete all the midi links going into one of those Juno 8 VSTs?
If you have the Gigfile saved with the Juno 8 set to some particular patch, then open it up with no midi links connected to the VST, does it still exhibit this patch change problem?
Can you upload the simplest gigfile that you can create that exhibits the problem?
Also, if you have the animated wiring enabled, can you see which wire lights up?
I have something similar from time to time. What helped me was putting a midi filter in front of the plugin, only let pass note, pitch, modwheel, aftertouch and sustain.
Edit: ups, already had a similar response some time ago up this thread…
@dhj it’s not possible to see this in the wiring view, as this happens nearly only when opening the affected rackspace. Global midi monitor is the only help in this case…
Yes, but the claim was that the “bomb” was coming from another plugin – that wouldn’t show up on the global monitor - at least I don’t think it would
Finished more testing. The Midi Bomb can be seen on the midi monitoring (wires all activated/light up simultaneously without any keys/knobs/etc touched). I can also now confirm the Release is the midi message impacted and is lowered on plugins where there is a ADSR. Eg. For Emulator II V string patch the VCA Release is lowered. For Juno 8 string patch the ENV-2 Release is lowered. There is no reason for this to happen. I assume where the patch is sampled based (Augmented strings) there is no change as this plugin is unaffected (sounds right) despite the patch showing a * in the patch name.
Looks like I have isolated the problem. It appears that the culprit is the Arturia KeyLab mkII keyboard sliders and Arturia plugin combination. The keyboard sliders are sending CC messages without being touched. If I filter out the offending CC messages the patches remain as expected. Also it appears that if the sliders are not fully down the CC messages for faulty sliders will be sent - keeping them down appears to fix the issue. Eg. if the sliders corresponding to Release and Attack are at a value around 30 they will sporadically send messages between 29-31 and thus alter the sound of Arturia plugins parameters. These are the values I have filtered at this point.
CC# 72
CC# 73
CC# 82
CC# 83
I have not captured any other spurious impacting CC messages at this point but I suspect they could change depending onthe state of the individual sliders. Very disappointed in the KeyLab mkII. Looks like this is an Arturia problem they need to resolve with faulty sliders and integration with Arturia plugins.
Nasty!
Hm, you should check you KeyLab. Mine is ‘quiet’ - I had other boards sending much more flicker CC’s.
And - “listen and repeat” (this phrase was often used in an old German Telekolleg TV show)
Use restrictive MIDI filters in front of plugin instruments!
BBB,
who recently fell into the trap again while testing a community patch…
I’ve seen this kind of thing with low-end expression pedals but I’m surprised to see it on Arturia gear, which is generally very good quality.
That said, I’ve just returned two keyboards within a week of each other because of faults (one stopped powering up, the other had a knob that stopped controlling parameters) and it seems to me that a lot of “post-COVID” gear has quality control issues.