Keep vst instruments in memory when changing patch

@rikelliott

I hear you!

This is on my to-do list, and has been for a long time. It's a bit complicated to implement, so it may not show up in Unify for some time, but it's definitely on our roadmap, for precisely the reason you mention.

-shane

I think the best and easiest way to implement is to have a resident plugin list. in the plugin list display there can be a checkmark to enable/disable stay in memory. when checkmark is on for a plugin it stay resident and it is load only once when need and stay in memory.  for example most use kontakt or omnisphere or falcon or halion amd this can enable as resident  and it stay always in memory when a patch need it the first time.  there can also a menu "clean up memory", so currently unused plugins are remove from memory.

@user476565

That's a VERY interesting idea. I was planning on a more generic caching scheme, but this might be even better. It's now on my list!

-shane

with a cache it is more work to do. a user can best choose which plugins need stay resident because they have long load time. or you need measure the load time of the plugin(dll load time) and cache plugins that load longer than 0.3 sec for example

So we have the option to re-use plugins, which I was able to apply with Pigments. When I first switch to a patch with Pigments, it takes a long time to load. This makes sense, because the plugin is not yet in memory. Switching to other Pigments patches then goes very fast. However, if I go to a patch without Pigments, going to a patch with Pigments takes a long time again. So it seems Pigments is purged from memory. Is this intentional? Can I change it?

By the way, fast switching only works with the rule <PluginRule vendor="Arturia"/>. Including the plugin name makes it fail (similar to this issue with Kontakt).

Posted by: @crazyray54

Switching to other Pigments patches then goes very fast. However, if I go to a patch without Pigments, going to a patch with Pigments takes a long time again. So it seems Pigments is purged from memory. Is this intentional? Can I change it?

Yes it's intentional. No, you can't change it, sorry. There has to be some limit, otherwise you would eventually have every plug-in you own stuffed into RAM. The present caching technique is designed to make switching among patches in a single unified library almost as quick as opening the plug-in and switching presets.

By the way, fast switching only works with the rule <PluginRule vendor="Arturia"/>. Including the plugin name makes it fail (similar to this issue with Kontakt).

This might be because the name Unify uses internally for the plug-in isn't exactly what you specify. Check the plug-in's entry in Unify's Known Plug-Ins list. Note also that specifying only the vendor "Arturia" will cause Unify to attempt to re-use ALL Arturia plug-ins, which might or might not be what you want.

Much of the behavior of third-party plug-ins, such as how quickly or slowly they start up, how well they handle re-use, etc., is not something we can control, so all this remains a matter of trial and error.

@getdunne

Is this a good list? I am not certain why the percent mark follows Kontakt below, but that was already there. I added Pigments and Reaktor.

<PluginRules>
  <PluginRule vendor="Spectrasonics"/>
  <PluginRule vendor="Native Instruments%" name="Kontakt%"/>
  <PluginRule vendor="Native Instruments%" name="Reaktor"/>
  <PluginRule vendor="Native Instruments%" name="Massive"/>
  <PluginRule vendor="Rhizomatic" name="Plasmonic"/>
  <PluginRule vendor="Decidedly" descName="DecentSampler"/>
  <PluginRule vendor="Arturia" descName="Pigments"/>
</PluginRules>

Posted by: @terrybritton

@getdunne

Is this a good list? I am not certain why the percent mark follows Kontakt below, but that was already there.

The percent sign is used as a wildcard (as explained in the manual) because the plug-in name as seen by a host program may have extra stuff like "x64" at the end of it, which is platform-dependent.

As to whether this is a "good list", that is also explained in the manual. This remains an experimental technique, and it's risky for us to assume that a given plug-in will support it. Witness the fact that recent versions of Kontakt don't do so as well as earlier versions did.

Would it be possible to keep the plugin's GUI open when switching to another preset if it has been listed in ReuseAcceptRules.xml?

Posted by: @karlfranz

Would it be possible to keep the plugin's GUI open when switching to another preset if it has been listed in ReuseAcceptRules.xml?

Technically possible? Yes. Easy, or likely to be to appear in Unify anytime soon? No. I'll put it on the to-do list.