new pvst beta (updated 03-Dec-2023)

[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 23 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 18 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 13 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" ?