Shared Macro Control Access CCs

I’m using version 1.4.2.829.

My primary interest in trying Shared Parts or Shared Global Parts, when using Layers, was to see if I could get another set of 8 Macro Control Access Knobs directed to the same shared VST instance. Eight knobs is often not enough for my project.
Testing with Kontakt 7, this does not work. Any knob from any layer will in fact control the instance, and the data values are saved with the VST Live Project project file. However. the data values are not enforced by any “activation” process, whether loading the project file with the song selected, or simply selecting the song with the mouse, from another song. The data values show up by the knob, but you have to “touch” the knob to get enforcement. Obviously, you don’t want to have to do that in a live situation.
If the dev team is already working on jettisoning the Macro Access Control feature in favor of letting everyone make many types of controls in any quantity, then I’ll wait for that. As it stands, unless it is a Kontakt 7 automation issue, the data values from additional layers sharing the first VST instance don’t seem to be retrievable from the master VST instance collection Macro Access Controls. It’s easy to see how that could happen, since the emphasis would first be on sharing the VST, not adjacent layer data.

We will check.

Cannot confirm this. When a Layer is activated (selected, through Part Selection), it sends all programmed quick control values to its MIDI output (“Instrument”). This is independent of the plugin instance however, quick controls are mainained by the Layer, not the (possibly shared) plugin instance.

Individual settings for Layers are more flexible of course. If you need to address more than the given 8 quick controls, you can just add more Layers for that, sending to the same plugin instance (shared).

But maybe I didn’t get all of the picture?

This issue is now resolved, if in fact it was ever a problem. However there is a procedural issue for the user that may require documentation or another remedy. I tested this in version 1.4.8.847 using a shared Kontakt 7 VST multi-rack. The part had two layers, with the first layer shared by the second.

I found out that I needed to close the VST Instrument Editor before saving the project. If I saved a Quick Access Control CC value using File/Save while the VST Instrument Editor was open and then closed VST Live and reopened it, the correct value would be showing on the knob, but it fails enforcement on the VST at project load time. What that looks like in Kontakt 7 is that its UI value looks correct but the engine has done nothing with the received CC and instead, the previous setting or a default setting is resident.

If an editor is open, you can save, but it does no good. Instead, close any/all VST Instrument Editors, then save. If you don’t, you will notice that you get asked to save again, when you close VST Live Pro.

The current behavior presents a procedural hazard to the user and can make it look like the Macro Control Access feature is not working correctly. The feature might appear to work better if File/Save was simply disabled unless and until all VST Editor windows were closed. Apparently the VST Live Pro persistence layers depend on that state in order to save reuseable settings that load and activate as expected.

It is possible that the current behavior began occurring after they fixed the bug that was causing VST Live Pro to crash on close when a VST Instrument Editor was open. I noticed this a couple of versions ago, but then it seemed fixed in a later version and is not happening anymore. I don’t know if anyone ever reported that crash back then, but it’s possible its nearly on the save code path.

That is certainly wrong, we’ll check.

Tried this: new project, default Layer is Halion Sonic (Compressed Rock Piano), open its editor, click QC, change send 1 level, save, exit, load, all good and as expected. What’s you recipe to reproduce?
Maybe first check with the next version expected to come very soon.

No repro now in 1.4.9.851. Thanks for your follow up, the issue is resolved.