Load VST Plugin via IML?

[gurulogic]

I am trying to use IML to automatically load a VST plugin from the send message module, so far somewhat successfully except the only plugin I can get to load is whichever one I had last loaded manually, so I guess whichever plugin is still being cached.
Any tips to load a specific plugin from my VST directory? This is what I am working with so far (???) means it doesn't matter what I put there, the last loaded plugin will load.

SET_TARGET_PATCH SENDER_PATCH
STORE_FOR_UNDO
CREATE_UID plugname = ????
CREATE_PLUGIN plugname 200 200 DROP_FILENAME
SET_VALUE plugname visible 1
RENAME_MODULE plugname
RENAME_PATCH DROP_SHORT_FILENAME

[gurulogic]

Ok.. Scratch that question. I have figured out how I can load/reload a sub patch in place, and that works better for me.
Still would be great to find an IML message to save sub patch without prompt. Is this possible?

Edit: Never mind, figured it out.. Well mostly. Patch saves in Root Usine Directory, would be nice to choose where to load and save sub patches from but I feel I am getting close.. My fear of IML is lessening a bit

SET_TARGET_PATCH SENDER_PATCH
SAVE_PATCH "Rack1.pat"
CLEAR_PATCH
LOAD_PATCH "Rack1.pat"
RENAME_PATCH Rack1

[23fx23]

you can load a vst in custom folder this way too:

SET_TARGET_PATCH SENDER_PATCH
CREATE_PLUGIN myplug 100 100 'C:Program Files (x86)_VSTS_VSTISSinnahSinnah_x64.dll'

[gurulogic]

Cheers!

[woodslanding]

I don't suppose it's possible to have a VST load an fxb or fxp via IML (please, please, please!!)

[23fx23]

mmm i don't think man can currently load fxp via iml, but for sure it's possible to load a usine preset, or trig a program nb load, (=one fxp in current fxb) assuming you saved them first in default bank a workaround,

[woodslanding]

I figured. Problem is if i change anything in the hh patch it breaks all the presets. When you have 100s of them it is a lot of work. With fxb compatibility is taken care of by the manufacturer.

[gurulogic]

Hmm.. I didn't know about that you could break presets for existing modules by changing otjer stuff in patch. What are the limitations for future reference?

One thought is, have you tried with each vst in a sub patch with it's own preset manager? In this case i would think you could even move this vst/sub patch between any workspace complete with presets.

[woodslanding]

Yes that is what I eventually figured out I needed to do. There is now as little as possible in my vst hosting subpatch, and I should be able to swap them in and out and cable them up via IML to allow vst switching within a rack via script. Have to use cables for audio and midi in/out, as the busses create latency. But everything else can be bussed (params, preset names, etc.) Not sure how I am ever going to get global preset recall working with this scenario, though....

I am not clear what breaks presets. Maybe Senso will weigh in. My guess is removing or adding any controls whose state must be remembered will break the presets for a subpatch.

And of course, I am concerned that HH3 will deal with this differently, and I'll have to recreate all 500 of my kontakt presets yet again. That's why fxp support would be nice. It would be future proof. I have 500 fxps waiting for it!

Also, I have my fxps divided into folders by type, and there is not an arbitrary 32 element limit to the number of items in a folder, and no hoops to jump through to create that 33rd file, unlike HH presets....

I did this all for my max implementation, before I abandoned it. As of max7, you can't do RT midi in the scripting engine, as the inputs are scanned in the low priority thread, so I am back to HH. Wish I'd known that before I forked out the $$, but I am allowed to resell Max, so not so very bad. Max also takes forever to start up.

[gurulogic]

"Not sure how I am ever going to get global preset recall working with this scenario, though"

I think that "sub vst patch" preset manager recall could be linked to global preset variables, ie: fader to select via bus etc preset of sub patch.. The trick here is that to prevent the "sub vst patch" from storing in the global preset, you need to nest the sub patch containing it's own preset manager is another patch that has saved in preset turned off. This isolates the sub patch for being part of the global preset.

Another option if you want something that should be very future proof and can migrate plugin setups between different hosts is to try Blue Cat Patchwork to host your VST's within Usine. It has very robust preset management features, can load entire chains of VST's in realtime (via bank/program change) and seems very stable. For me it was almost perfect except it has a bit convoluted of an internal routing scheme that doesn't make it as ideal for a complete multi VST/audio flows rack solution, and also it doesn't expose actual parameter names to host for mapped VST parameters which is a bit annoying. Also the requirement of having the UI open to load programs makes for a bit of mess if using multiple instances, but maybe give the demo a try and see if that works for you? I might even be talked into selling my licence at a discount

[23fx23]

one other possible solution would be do convert vst params floats, save to txt file and have a script parsing data back. ie theorically doable using array to commatext, write to file, and on loading the revese, load file, parse floats to array, tho i reckon load .Fxp would be a nice and easier add, it could be a 'by waiting' possible solution maybe that don't rely on usine pm.
(maybe some existing tools can convert already .fxp to readable textfiles one shot dk..)

otherwise what i would try first personally is build a user bank per vst with all the programs im suspected to use, 127 per vst seems quite enough for a liveset and just use the program pin via iml. or most plugins have a folder where man can put users .fxp. im pretty sure there are tools to quicky build a fxb out of a set of fxp copied in a folder so that's not a nightmare to maintenance