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
Statistics: Posted by 23fx23 — 13 Dec 2016, 04:56
]]>
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
Statistics: Posted by gurulogic — 12 Dec 2016, 21:46
]]>
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.
Statistics: Posted by woodslanding — 12 Dec 2016, 21:22
]]>
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.
Statistics: Posted by gurulogic — 11 Dec 2016, 23:59
]]>
]]>
]]>
]]>
]]>
SET_TARGET_PATCH SENDER_PATCH
CREATE_PLUGIN myplug 100 100 'C:Program Files (x86)_VSTS_VSTISSinnahSinnah_x64.dll'
Statistics: Posted by 23fx23 — 18 Nov 2016, 16:58
]]>
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
Statistics: Posted by gurulogic — 18 Nov 2016, 06:27
]]>
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
Statistics: Posted by gurulogic — 17 Nov 2016, 10:18
]]>