Ok, Iβve added now track automation for VST3 fx and VST3iβ¦
Sadly the VST3 parameterID is required. By that value the DAWs will map the automation lane to the plugin parameter.
Only works with Redux VST3, because Redux VST3 simply uses the parameter index as parameterID (just like VST2) and I currently have no other value for the parameterID.
I guess that means that I need to pause the development of the DAWproject exportβ¦
A lot of stuff already works:
VST3 plugins
Renoise sample instruments
Note data
Track automation (only if the VST3 uses index as parameterID)
Section naming
Track coloring and naming
Loads fine now into Bitwig and Studio One
Whatβs missing:
Master track automation
Any kind of pattern hex automation
Redux macro to instrument automation conversion
polyphonic aftertouch
Whatβs not working due to api limitations (please! give me a hint if I am wrong!):
VST2 .fxp generation/export
AU .aupreset generation/export
parameterID mapping, so most automation wonβt work
Canβt determine the target device of the Instr. Automation Device. Has to be done via a complete track search instead (so the device has to sit on the track where the instrument plays). That <LinkedInstrument> node is missing in the active_preset_data for some reason, if you access it via api. I assume there could be a better way to prevent what was to prevented by that.
Test .xrns: crystalhammer test.xrns (71.1 KB)
(uses redux instrument automation on track βbdβ, and shade plugin automation on track βpizzaβ)
Result .dawproject: Untitled.dawproject.pdf (101.8 KB) - REMOVE .pdf suffix
(misses the pizza shade automation, since UVI Shade VST3 requires a proper parameterID)
Not as I can tell⦠The Song.xml pretty much is a collection of those XMLs you will get while copy-paste action.
I think a DAW not neccessarily does have to use parameter id, itβs mainly for remapping parameters if a plugin vendor would change the order of the plugin parameters in a later version. This would not work in Renoise then, or at least would wrongly map the automation to the parameters then (Iβve actually seen that behaviour already, I think in some Vanhalla VST3). Renoise simply also uses the parameter index for VST3. But it certainly could query and provide the parameter ids of each plugin, even if it does not use it. Other DAWs rely on parameter ids instead. Or at least the daw project file format / spec.
is there an easy way to find out the plugin 's local file path? available_plugins only have a custom path. By easy I mean a better, shorter way than:
Find out which os you are using
Find out which cpu type you are using
Find out the Renoise preferences path
Loading Cached[PluginType]_[CpuType].db into sqlite handler
Querying for the actual plugin path βLocalFilePathβ
Fixing the found path for macOS VST3
Mmmmhβ¦ I am trying nasty workaround to find out plugin parameter ids and plugin unique ids using external tools (was easy to do in Rust for VST2, not so for VST3)β¦ But it seems to be a rocky road. Also does not seem to work with AU then, because Looks like Renoise saves the identifier only here, not the path at all, querying Appleβs AU service for that, or so. I have no access here.
Also is there a way to get the available_plugins even if there is no instrument slot added yet?
Thanks for ideas!
PS:
If someone is good in Rust, I would be glad if you could give me some tipps here. I cannot find a single VST3 library which provides solid VST3 plugin hosting functionality for Rust at all. Even annoyed myself using the common AIs, and mostly got hallucinated solutions about non-existing libraries I wasted half the day with those AIs, damn it.
The VST3 helper tool should basically do the same as:
Continuing here, I am trying to build an .aupreset now from the preset chunkdata⦠ChatGPT tells me that an aupreset is basically a plist xml like this:
The active_preset_data chunk seems to be a plist structure which then contains all the dataβ¦ So theoretically, I βonlyβ have to convert the bplist (which is a binary structure) to an xml formatβ¦? This in LUAβ¦