vst module enhancements

[woodslanding]

Since it sounds like v3 is in the pipeline, so maybe a good time for big FRs....

It would be so great to be able to load a different vst dll into a module, and load an fxb/fxp into it as well, via a text input. Just like the sampler module.

Probably would only need one input, as you could parse the filetype to know what to do.

There are obviously re-cabling issues, dealing with differing numbers of ins and outs.... I have some ideas if that's an issue.

It would also be nice to have an parameter array in and out that is just a 3 item array. {param number, param Name, value}. Sent out when a value is changed.... the input would just need one or the other of name or number....

Very nice for auto-naming controls for parameters, and for controlling a parameter without having to cable directly to it or merge a value into the full parameter array. I have so much (not quite working right, and very hard to debug) logic for extracting single changed values from and rewriting single values into the param array. Really clumsy for my uses as it currently exists.

Thanks!
-eric

[gurulogic]

woodslanding, it seems like we may have some in common inspirations for how VST function can be expanded in HH.

"It would be so great to be able to load a different vst dll into a module, and load an fxb/fxp into it as well, via a text input. Just like the sampler module."

I assume that you mean one module that is wired into the workspace and can change the loaded VST by selecting the saved preset file for that VST? I think this sort of concept would be a great addition to HH. Assuming I am thinking along the same lines, would you have all of the VST's pre loaded in memory with the project, or load from disk, or maybe a hybrid where the VST is only reloaded to memory if it has changed?

"It would also be nice to have an parameter array in and out that is just a 3 item array. {param number, param Name, value}. Sent out when a value is changed.... the input would just need one or the other of name or number.."

Agreed, VST parameters access in HH could definitely use some expansion for easier use in advanced patching/control scenarios. I am actually neck deep in creating a fully map-able multi VST/Rack with auto learn, param names and vst names that I will share when it is ready. Despite the amount of effort I have already put into this concept, I would welcome an easier way to approach multi VST mapping and a way around some of the limitations that are in place.

Limitations such as having to use a globally set number of accessible parameters per VST means that I am creating huge resource hungry arrays for VST's parameters even if only 3 parameters for a VST, or if a VST uses more than the size of array allocated per VST then the additional parameters would be un-mappable. I have thought about how to use the arrays to extract and distribute the arrays data to each VST dynamically, but it seems logistically near impossible or not worth the massive undertaking in patching. I can make it work, but if I change a vst with a new number of parameters, then my previous mappings can be broken.
In my ideal, each VST could have only chosen parameters assigned to the arrays i/o value, or maybe access parameters via names rather than arrays index, or something along those lines. [edit: whoa! select params by name.. might have just thought of a way to dynamically update assigned mappings when changing vst without the "impossible" part.. ]

Also, as I want to have wireless mapping freely throughout a workspace I am using buses but with the feedback loop involved in two way parameters communication, this opens a whole other can of worms.. Ok, I could go on but I am getting a bit long winded, lol

Quick tip if you don't know already, the array difference module will give you the last touched VST parameter index and value. This is the basis for the whole thing even be able to work for me.

[gurulogic]

Another really handy thing would be if VST plugins could have an outlet for name of VST coupled with an instance ID, for example if two of the same VST were loaded in a workspace, one instance would put out "NameofVST1" and the other "NameofVST2"
Currently is possible to index names of VST's when loading in a subpatch and rename subpatch with IML: but is not the most direct approach and lacks per instance ID.

[sm_jamieson]

> Also, as I want to have wireless mapping freely throughout a workspace I am using buses but with the feedback loop involved in
> two way parameters communication, this opens a whole other can of worms..

gurulogic,
Senso said there will be multi-wire busses in HH3. If the multi-wire busses could contain wires in both directions, that might be useful for you there. I've never used the bus binds, I am still wiring busses directly into patches. The "wiring" thing in Usine is both a blessing and a curse.

Simon.

[sm_jamieson]

See my other post for something else missing from VST handling - RENAME preset. Its just the name of the preset in the VSTi preset data, which gets saved to an fxb bank file.
See
http://www.sensomusic.org/forums/viewto ... ?pid=36407

I would also like a VST wrapper module parameter to set the title of the VST wrapper window. Some VSTs do not update this at all, but the "VB3" VST (or Usine ?) does not update the "current preset" parameter when the preset is changed via midi, so the window title does not match the preset, which is rather confusing.
It would be useful to be able to set the window title via a patch to make it match.

[senso]

I'll study carefully you're request. A little bit late for HH3 but nothing impossible in next updates.

[woodslanding]

Quick tip if you don't know already, the array difference module will give you the last touched VST parameter index and value. This is the basis for the whole thing even be able to work for me.

Great for getting a single value. Unfortunately, to SET a single value, you still have to merge it into the entire parameter array!

[woodslanding]

I assume that you mean one module that is wired into the workspace and can change the loaded VST by selecting the saved preset file for that VST?.

I was thinking of sending the name of a dll. to the module, which would then load it. After it was loaded, you could send it an fxp or fxb.

Of course it is possible that the .fxb/.fxp file could tell you which VST created it.... if that's the case, you could do it all with a single command, which would be awesome, mostly because you wouldn't have to worry about waiting for the dll to finish loading....

[woodslanding]

would you have all of the VST's pre loaded in memory with the project, or load from disk, or maybe a hybrid where the VST is only reloaded to memory if it has changed?

Well, caching vsts could be a FR, but not really part of the previous. If you are able to load a dll with a text string, there is no practical way for HH to know what vsts you might end up wanting to load....

Most don't take too long to load, but I know that VIP f.i. does cache vsts. Potential memory hog, though! VIP has some way of clearing them from memory if they haven't been used for a while.

[woodslanding]

I'd be perfectly happy to be able to load files via IML, if that's simpler than using pins....

Seems like HH does do some sort of caching. If I load a subpatch A containing a vst (my current workaround) then load subpatch B, subsequently reloading A goes much faster than it did the first time.

[sm_jamieson]

Update to the VST preset rename function. Not so easy for fxb files, but should be possible for individual preset.
See http://www.sensomusic.org/forums/viewtopic.php?id=5592