Notifications
Clear all

Keep vst instruments in memory when changing patch

11 Posts
6 Users
6 Reactions
2,558 Views
(@rikelliott)
Active Member
Joined: 4 years ago
Posts: 9
Topic starter  

I do not know if this is possible but if I am moving between a series of patches based on "Alicia's Keys" for example together with other Kontakt libraries it would be great if unify cached the VST data so it did not need to load everything back in again.


   
mj_prod reacted
Quote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4453
 

@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


   
mj_prod reacted
ReplyQuote
(@user476565)
Estimable Member
Joined: 4 years ago
Posts: 139
 

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.

This post was modified 4 years ago by user476565

   
mj_prod reacted
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4453
 

@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


   
mj_prod reacted
ReplyQuote
(@user476565)
Estimable Member
Joined: 4 years ago
Posts: 139
 

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


   
ReplyQuote
(@crazyray54)
Active Member
Joined: 2 years ago
Posts: 16
 

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).


   
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4453
 
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.


   
crazyray54 reacted
ReplyQuote
(@terrybritton)
Member
Joined: 3 years ago
Posts: 117
 

@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>

   
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4453
 
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.


   
ReplyQuote
karlfranz
(@karlfranz)
Estimable Member
Joined: 4 years ago
Posts: 135
 

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


   
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4453
 
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.


   
karlfranz reacted
ReplyQuote
Share: