new pvst beta (updated 04-Aug-2024)

[Klangkulisse]

Hey Polac,
thank you for the new version

[richb]

First of all, huge thanks for continuing to maintain a plugin loader for a more-or-less dormant piece of software. I was sort of amazed to find this thing is still going, but very happy.

I'm seeing a few issues and just wanted to check I'm not doing something silly.

Am I right in thinking that with the VST3 shell, you only get 32 bit plugins with 32 bit buzz and 64 bit plugins with 64 bit buzz? I see both on the VST2 side, but not in VST3 land, so I was wondering if something is upsetting things on my end or if that's how it is supposed to work?

I've also noticed that having VST3 plugins installed seems to slow down Buzz startup quite significantly. Is there any way to work around that other than uninstalling them (blacklisting plugins or something?)

Finally, I've noticed that a VST loader running any Universal Audio plugin that uses DSP, doesn't seem to unload the plugin cleanly. The DSP resources on the card aren't freed until you close Buzz itself. Are any of the settings in the plugin loader likely to affect this behaviour? When scanning, you can see the dsp usage go up and down as it instantiates each plugin in turn, so it works there at least.

Thanks for any help!

[polac]

Bump, new version online.

[polac]

hey frank... food for thought...

since vst3 is all fucking ruthless about the way plugins are installed (programfiles/commonfiles/vst3) without path installation options and what not...

is the possibility you could setup like a txt or config file or some other thing where if we wanted (but not needed), we could define the organization the way we want to? since we can't do it via folders, n whatnot anymore?

vst3 is so annoying because of these forced directories/install paths that most devs even still doing vst2 as an option....and thats what i normally grab, but it's not always an option.

Hi Mute,

sorry for late reply. You could use my shell2vst tool to create small regular vst2 .dlls instead of having them in all vst3 submenu. You can move them in your vst2 folders as you wish. It's to much fiddling around to have an additional submenu structure in the vst3 menu(and other shell vsts like Waveshell).

https://www.xlutop.com/buzz/zip/shell2vst.zip

[Buzztler]

Bump, new version online.

Ho-Ho-Ho! ... Ja, ist denn heut' schon Weihnachten?!?

[HerrFornit]

hey frank... food for thought...

since vst3 is all fucking ruthless about the way plugins are installed (programfiles/commonfiles/vst3) without path installation options and what not...

is the possibility you could setup like a txt or config file or some other thing where if we wanted (but not needed), we could define the organization the way we want to? since we can't do it via folders, n whatnot anymore?

vst3 is so annoying because of these forced directories/install paths that most devs even still doing vst2 as an option....and thats what i normally grab, but it's not always an option.

Hi Mute,

sorry for late reply. You could use my shell2vst tool to create small regular vst2 .dlls instead of having them in all vst3 submenu. You can move them in your vst2 folders as you wish. It's to much fiddling around to have an additional submenu structure in the vst3 menu(and other shell vsts like Waveshell).

https://www.xlutop.com/buzz/zip/shell2vst.zip

Hi mute,
I did not try, just an googled unlikley idea if your porpose is to use an other folder for vst3? use with adminrights in cmd.

Code: Select all

mklink /J vst3folder vst2folder

EDIT: Does not work

PS: Danke polac!

sended from my smartphone

[richb]

I've noticed that a VST loader running any Universal Audio plugin that uses DSP, doesn't seem to unload the plugin cleanly. The DSP resources on the card aren't freed until you close Buzz itself.

To narrow this down a bit:

• It only happens when using 32 bit buzz (so using the bridge I guess as they're 64 bit plugins)

• It only occurs if you delete the Polac VST machine in machine view, if you switch to a different plugin instead via right-click -> plugins->whatever the DSP usage drops off as expected

• The various settings 'run in separate process -> options...' don't affect this behaviour

I've also noticed that having VST3 plugins installed seems to slow down Buzz startup quite significantly

Also instantiation of VST3 plugins seems very slow for me. Buzz startup is ~1 minute, instantiation is 30 seconds or so. Possible that's a pace/ilok thing or something, although they're fast in REAPER.

[mute]

thank you

[polac]

In case of shell2vst, i would move the vst3shell files out of the vst2 folder at first, then use shell2vst on it and put the small stub dlls back to your vst2 folder. That way you only have one entry for each vst in you menus.

[UNZ]

hi polac, is there a way i can get PVST to call effGetParameterProperties?

it would be nice to get parameter names with more than 8 chars in a safe way.
it doesn't feel right to just write more than 8 chars on a call to effGetParamName, but apparently many plugins do this?

Anyway, VstParameterProperties label allows 64 chars, but it looks like PVST never calls this.

[polac]

Hi UNZ, i'll take a look.

[aKa]

Holy moly, you are still on it @Polac.
I was just wondering today if Buzz is still a thing.
Last time i used it was 15 years ago and now i stumbled over some old buzz files and wanted to give it a go again.

Thats some proper dedication. Mad respect.
Also respect do Oskari of course.

[UNZ]

Hi

i think i found a bug in PVST with VST3:

getMidiControllerAssignment seems to ignore the channel

if a VST does something like this in getMidiControllerAssignment():

if (channel == 1 && midiControllerNumber == Steinberg::Vst::ControllerNumbers::kPitchBend)
{
id = id1;
return Steinberg::kResultTrue;
}

if (channel == 2 && midiControllerNumber == Steinberg::Vst::ControllerNumbers::kPitchBend)
{
id = id2;
return Steinberg::kResultTrue;
}

these CC don't get mapped to parameters at all.
this makes it impossible to implement stuff like MPE. for example you can't do per-note pitchbends in surge and vital, just tested this, the pitchbend always goes to channel 0, no matter what value you set as the midi channel in pxp. these plugins rely on the fact that they can define a set of 16 parameters for each CC (and pitchbend and kAfterTouch) and map each midi-channel to a different parameter. this doesn't seem to work in PVST, as only the mapping on channel 0 seems to get honored. (yes this is a all bit hacky, the proper way would be for both host and plugins to support vst3 note-expressions, but almost nobody does this and it would be difficult in a tracker anyway. many plugins implement MPE in this way and completely ignore the vst note expressions dialect.)

EDIT: it actually looks like nothing gets mapped at all in getMidiControllerAssignment() unless it is on channel 0.
so only this works:
if (channel == 0 && midiControllerNumber == Steinberg::Vst::ControllerNumbers::kPitchBend), can't get them to map on anything other than channel 0
{
id = id1;
return Steinberg::kResultTrue;
}

i think the problem is that the mapping is either ignored, or that when sending pitchbend, the midi-channel from the pxp parameter is not included in matching to vst parameter

EDIT2: same problem with midi cc 0 to 127 and with 128 (kAfterTouch), can't get them to map on anything other than channel 0

EDIT 3: so i just tried this with VST2, and it also doesn't work, leading me to believe that the problem is that the midichannel from PXP is just always ignored. is this a setting or something? see attachment.

pxp_pb.png (9.75 KiB) Viewed 16080 times

EDIT 4: so... the notes themselves also don't honor the midi-channel. but this definitely worked last week before i updated to the latest PVST...

EDIT 5: if you use buzz-notes the channel works, with midi-notes it gets ignored (i know buzz never send the channel, but pvst could still use the state of the midi-channel parameter, right?). pitchbends etc are still always on channel 0...

EDIT 6: i think i'm starting to understand: these pxp midi columns are basically useless because you never get a proper midi channel with them. the solution is either for PVST to take the state from it's own midi-channel column, or to just use the pvst commands i guess...

pvst_pb.png (8.9 KiB) Viewed 16075 times

leaving this here for anyone who struggles with getting this to work. basically you need to use the buzz-notes and pvst commands for now, as the pxp midi columns are completely useless without honoring the midi-channel.

so in summary this isn't strictly a bug but more like a missing feature: i propose to use the midi-channel parameter state even when dealing with pxp midi-columns. in theory this can work, but i know it's a bit more complicated in practise, as midi events could come in on multiple threads etc i guess and you'd need to synchronize them to tick.

[UNZ]

Polac, i just wanted to say THANK YOU for implementing Note Expressions in PVST.
i just discovered this on accident while trying to debug this midi stuff.
it doesn't seem documented yet, but if a VST3 exposes note expressions, you can actually send them using pvst:

note_expressions.png (7.04 KiB) Viewed 16070 times

this is awesome for testing my VST3 and saves me from having to buy cubase or bitwig

one question:
the note expression "track command value" has to be 0002, it doesn't work with 0000 or 0001, is there a particular reason for this?
what is the meaning of the 0002? does it maybe mean "kNoteExpressionValueEvent" ?

[polac]

Polac, i just wanted to say THANK YOU for implementing Note Expressions in PVST.
i just discovered this on accident while trying to debug this midi stuff.
it doesn't seem documented yet, but if a VST3 exposes note expressions, you can actually send them using pvst:
note_expressions.png

this is awesome for testing my VST3 and saves me from having to buy cubase or bitwig

one question:
the note expression "track command value" has to be 0002, it doesn't work with 0000 or 0001, is there a particular reason for this?
what is the meaning of the 0002? does it maybe mean "kNoteExpressionValueEvent" ?

It's just cumbersome to use note expressions though . Don't know what i programmed there, have to take a look.

edit: Hmm, help file says this:

15 xxxx
xxxx(0-FFFF): Track number.

Never used note expressions here, only for testing when implementing.

[UNZ]

yeah i'm using it for testing too. it's great for that.
i dabbled a little bit more with it, looks like you can target notes on the different buzz-tracks with it, so that's pretty cool if you have several note expressions you want to put on the same note. ultimately this is a feature that desperately needs GUI support, but tracker-style input is great for testing.

i think when vst3 came out, with it's bad reception, note expressions where overlooked in pretty much any daw other than cubase and people implemented MPE instead. now with midi2 on the horizon the story changes again, but i think the per-note MIDI2 messages will get translated to note expressions from the host and sent as that to the plugin, as vst3 doesn't really want you to deal with midi anyway, so note expressions will probably become more ubiquitous from here on. afaik bitwig already implements them, not sure about ableton, they call it MPE still. also, CLAP is supporting all 3 note dialects (MPE, VST3, MIDI2).

anyway, congrats on probably being the first to implement them outside of steinberg crap i really appreciate it. they want 300$ for that, as their 99$ LE version doesn't even support them...

[richb]

Is there any info anywhere about how the loader actually works?

Trying to figure out what's making VST3 scanning so slow by prodding it with process monitor, seems like buzz kicks off an instance of scan.x64.exe for each plugin, passing the path to the vst3 shell dll and a long number. That globs through all of the .vst3 plugins every time, which takes a while, before (I think?) loading one specific plugin and querying it. Maybe it's looking up the requested plugin via id or something so it has to load all of them to figure out which to open?. I guess that means there's a bit of an O(N^2) situation, so when you've got a large number of plugins it gets super slow. Maybe something could be cached somewhere?

Or I'm completely wrong, I don't really know what I'm looking at

edit -

The delay seems to be dependent on the number of VST3 plugins present and nothing else.
The delay is about 25 seconds in my folder of ~300 VST3 effects (this is indirectly a UA thing, they install every plugin with multiple variants regardless of what you own, I could certainly mitigate this a bit by clearing most of them out)
I have only a few VST3 instruments, and instantiating any of those is quick.

The delay happens between the Load Image of vst3shell.x64.dll and the Load Image of the requested plugin, wherever that occurs (instantiating a plugin from buzz_x64.exe, per plugin from scan.64.exe when doing a plugin rescan). It also happens on buzz startup via scan.64.exe between the Load Image of vst3shell.x64.dll and scan.x64.exe exiting.
Upshot is a 30 second delay to start buzz or load any VST3 effect, and a rescan takes a few hours.

During the delay you can see the the filesystem touching every file in the VST3 plugins dir. Not sure what else is going on as I haven't poked at the actual dll at all, just looking at what it's doing with the OS from the outside.

I'm not sure if its exacerbated by the fact that all the UA plugins are bundle style (the .vst3 is a directory with a .vst3 binary in a subdir) - I say this as the jumps in time seem to correlate with the OS returning IS_DIRECTORY on a CreateFile operation with a .vst3 directory.

[UNZ]

• It only occurs if you delete the Polac VST machine in machine view, if you switch to a different plugin instead via right-click -> plugins->whatever

hey, speculation on my part but what i know is this: IIRC, if you delete the pvst machine in machine view, the destructors are not called, because the vst is kept alive for undo purposes. i'm guessing this is why your card never frees any resources, the vst doesn't really know that anything happened, to the vst it looks like nothing happened at all. as opposed to when you switch presets, the freeing of used resources is handled internally.

i thought there was an option in PVST to unload-on-delete, but after checking, i can't find it, maybe i was dreaming. this would most likely break undo, but fix your problem...

[polac]

hi polac, is there a way i can get PVST to call effGetParameterProperties?

it would be nice to get parameter names with more than 8 chars in a safe way.
it doesn't feel right to just write more than 8 chars on a call to effGetParamName, but apparently many plugins do this?

Anyway, VstParameterProperties label allows 64 chars, but it looks like PVST never calls this.

Is it really often used by vsts, and can you tell a vst that use it so that i can test?

I would say it is safe to use effGetParamName with more than 8 chars, I doubt there are hosts that do not offer larger buffers for safety. In pvst i have a buffer of 256 chars. Also most plugins don't care about the 8 chars limit either.

[UNZ]

hi polac, is there a way i can get PVST to call effGetParameterProperties?

it would be nice to get parameter names with more than 8 chars in a safe way.
it doesn't feel right to just write more than 8 chars on a call to effGetParamName, but apparently many plugins do this?

Anyway, VstParameterProperties label allows 64 chars, but it looks like PVST never calls this.

Is it really often used by vsts, and can you tell a vst that use it so that i can test?

I would say it is safe to use effGetParamName with more than 8 chars, I doubt there are hosts that do not offer larger buffers for safety. In pvst i have a buffer of 256 chars. Also most plugins don't care about the 8 chars limit either.

probably not used very often, i just assumed naively that it can't be that an entire industry ignores the limit and stomps all over host memory in the pursuit of causing buffer overflows and exploits everywhere. no matter how big you make the buffer, there's always a bigger idiot out there...i guess i was wrong and people accept all kinds of crap.

*sigh*, maybe at least the limits for the most popular hosts would be known?