new pvst beta (updated 2-Jul-2020)

User avatar
IXix
Posts: 855
Joined: Wed Nov 23, 2011 3:24 pm

Re: new pvst beta (updated 2-Jul-2020)

Post by IXix »

rav wrote:
Sat Jul 11, 2020 9:52 pm
Ok - i have made more tests. It looks like that i can't reload only projects with SuperMassive x64 - BMX attached
loadder.gif
I have had crash with going to preferences last tab 3 times more, but cant reproduce it for now. Today it crashed on Valhalla FreqEcho x64.
Sorry, loaded your file without problems, just had to browse to find the supermassive dll. It was on the default settings, did you save it like that?

No issue with preferences either. I'm on Win10 64.

rav
Posts: 98
Joined: Fri Sep 14, 2012 3:35 pm

Re: new pvst beta (updated 2-Jul-2020)

Post by rav »

IXix wrote:
Sun Jul 12, 2020 10:05 am
rav wrote:
Sat Jul 11, 2020 9:52 pm
Ok - i have made more tests. It looks like that i can't reload only projects with SuperMassive x64 - BMX attached
loadder.gif
I have had crash with going to preferences last tab 3 times more, but cant reproduce it for now. Today it crashed on Valhalla FreqEcho x64.
Sorry, loaded your file without problems, just had to browse to find the supermassive dll. It was on the default settings, did you save it like that?
I think so.

I have found 100% crash routine here:
Load any x86/x64 bit VST plugin and go to the preferences last tab (named as loadded plugin). Then load any x86/x64 bit VST plugin (could be the same one) and go again to the last tab in preferences. Crash :roll:
I was loadding plugins from the hard drive locations (edit: it doesnt matter - tested). It works ok if you are copying plugins, but after you load this 2 one and go to the prefs again - boom.

Edit2: it seems to be releated only to VST FX machine
Last edited by rav on Wed Jul 15, 2020 8:41 pm, edited 1 time in total.

User avatar
Buzztler
Posts: 197
Joined: Sat Jan 21, 2012 2:54 pm
Location: Faraway but near enough

Re: new pvst beta (updated 2-Jul-2020)

Post by Buzztler »

Hi Sir Polac,
just if you wonder what kept me awake today ... ;)

Beside the problem(s) that rav has discovered I found another thing which, let's say, seems to me a little strange.
I wanted to run Shred in a separate process, so that the gui updates regularly. I went to the global settings and marked "run in separate process" and restarted Buzz. The separete process was marked, but the gui of the plugin did not change. At first I thought I forgot how to handle the hanging gui problem, but on my other system the plugin runs fine.
So after a whole bunch of trial and error I found out that you have to mark "run in separate process" via the "edit" option menu, than it works like a charme, but via global 2 settings you are completely f...ed up.
So is it possible to have a look what else doesn't work via global 2 settings? Thanks in advance ... .

River Cricket
Posts: 84
Joined: Sat Dec 20, 2014 6:53 am

Re: new pvst beta (updated 2-Jul-2020)

Post by River Cricket »

rav wrote:
Mon Jul 13, 2020 10:28 pm
IXix wrote:
Sun Jul 12, 2020 10:05 am
rav wrote:
Sat Jul 11, 2020 9:52 pm
Ok - i have made more tests. It looks like that i can't reload only projects with SuperMassive x64 - BMX attached
loadder.gif
I have had crash with going to preferences last tab 3 times more, but cant reproduce it for now. Today it crashed on Valhalla FreqEcho x64.
Sorry, loaded your file without problems, just had to browse to find the supermassive dll. It was on the default settings, did you save it like that?
I think so.

I have found 100% crash routine here:
Load any x86/x64 bit VST plugin and go to the preferences last tab (named as loadded plugin). Then load any x86/x64 bit VST plugin (could be the same one) and go again to the last tab in preferences. Crash :roll:
I was loadding plugins from the hard drive locations (edit: it doesnt matter - tested). It works ok if you are copying plugins, but after you load this 2 one and go to the prefs again - boom.
I do have occasional hiccups with 64-bit plugins - primarily that sometimes the current settings on VSTi's (never had it happen with effects) won't actually save with the .BMX; no way of finding out that this has happened until I reload the .BMX and hear those lovely default patches - but I'm unable to replicate this one on my setup.

Just to make sure I'm doing it right, here are my steps in detail:

1. Launch Buzz
2. Type "vsti" in right searchbar, drag-drop a new VSTi 1.1 machine
3. Double-click VSTi machine
4. Load VST (Serum64, in this case)
5. Right click, preferences.
6. Click final of the three tabs (e.g. not Global or Global 2).
7. Click "okay".
8. Repeat steps 2-7 - going to the preferences tab of the new machine, not the old one.

rav
Posts: 98
Joined: Fri Sep 14, 2012 3:35 pm

Re: new pvst beta (updated 2-Jul-2020)

Post by rav »

I did not tested VST instruments in this respect before, but it seems to work stable here too.

Try to load VST effects.
River Cricket wrote:
Wed Jul 15, 2020 12:18 pm
1. Launch Buzz
2. Type "vsti" in right searchbar, drag-drop a new VSTi 1.1 machine
3. Double-click VSTi machine
4. Load VST (Serum64, in this case)
5. Right click, preferences.
6. Click final of the three tabs (e.g. not Global or Global 2).
7. Click "okay".
8. Repeat steps 2-7 - going to the preferences tab of the new machine, not the old one.
Second time clicking "okay" is not possible here, because it crashes just after clicking tab :lol:

rav
Posts: 98
Joined: Fri Sep 14, 2012 3:35 pm

Re: new pvst beta (updated 2-Jul-2020)

Post by rav »

Buzztler wrote:
Tue Jul 14, 2020 1:27 am
Hi Sir Polac,
just if you wonder what kept me awake today ... ;)

Beside the problem(s) that rav has discovered I found another thing which, let's say, seems to me a little strange.
I wanted to run Shred in a separate process, so that the gui updates regularly. I went to the global settings and marked "run in separate process" and restarted Buzz. The separete process was marked, but the gui of the plugin did not change. At first I thought I forgot how to handle the hanging gui problem, but on my other system the plugin runs fine.
So after a whole bunch of trial and error I found out that you have to mark "run in separate process" via the "edit" option menu, than it works like a charme, but via global 2 settings you are completely f...ed up.
So is it possible to have a look what else doesn't work via global 2 settings? Thanks in advance ... .
Maybe you need to unchecked "Embedded VST GUI" option?
There are two ways to do this and interestingly there are some other options in the end of each one.
Attachments
polac bridge.gif
polac bridge.gif (108.21 KiB) Viewed 981 times

User avatar
Buzztler
Posts: 197
Joined: Sat Jan 21, 2012 2:54 pm
Location: Faraway but near enough

Re: new pvst beta (updated 2-Jul-2020)

Post by Buzztler »

Maybe you need to unchecked "Embedded VST GUI" option?
There are two ways to do this and interestingly there are some other options in the end of each one.
@rav: I never before have seen the option you showed here. It seems pretty cool and the most utterly mindblowing experience is that since I have struggled with the "embedded vst gui" option and enabled it once ... I could mit reproduce the "hanging gui" again.
Even after I enabled the "embedded gui" option again the "Run in separate process" option also works via the Tab after global 2 options.
I'll think I click on every option I find in vst-loader, perhaps I find another " easter-egg" somehow ... Buzz is a strange Labyrinth sometimes :lol:

River Cricket
Posts: 84
Joined: Sat Dec 20, 2014 6:53 am

Re: new pvst beta (updated 2-Jul-2020)

Post by River Cricket »

Can anyone think of a reason why pVST would be sending F#4 instead of NoteOff?

I'm sending MIDI data to a KeyStep which then spits out some CV/Gate. Playing the KeyStep directly works as expected - press key, get noise, release key, noise stops - so I'm pretty confident ruling it out as the source of the problem here.

However, when Buzz is controlling the KeyStep, it sends notes as expected, but any time it's trying to send NoteOff, I instead get a long droning F#4, which lasts indefinitely, until I press a key on the KeyStep to get a "proper" NoteOff. There are no F#4's in the pattern, so it's not just a note that hasn't been properly cancelled.

It occurred to me that this might be a situation where the KeyStep isn't behaving properly when receiving external NoteOff, leaving the Gate open while reverting to a default note of some sort which happens to be F#4, but then I tried using CakeWalk instead of Buzz to send the MIDI, and it behaved as expected, with a proper NoteOff.

For what it's worth, F#4 is the 54th note where C0=0, and if C0=12 then it's the 66th - just two off from being 64, which might be significant in 0-127 MIDI-land.

User avatar
UNZ
Posts: 746
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: new pvst beta (updated 2-Jul-2020)

Post by UNZ »

River Cricket wrote:
Wed Jul 29, 2020 6:46 pm
Can anyone think of a reason why pVST would be sending F#4 instead of NoteOff?
there are two ways to define / send note offs in midi:

1) note off messages
2) note-on messages with 0 velocity

from midi spec:
"A receiver must be capable of recognizing either method of turning off a note, and should treat them identically."

it seems pvst sends the later, but your keystep doesn't properly treat them as note-off.

River Cricket
Posts: 84
Joined: Sat Dec 20, 2014 6:53 am

Re: new pvst beta (updated 2-Jul-2020)

Post by River Cricket »

UNZ wrote:
Thu Jul 30, 2020 4:39 pm
River Cricket wrote:
Wed Jul 29, 2020 6:46 pm
Can anyone think of a reason why pVST would be sending F#4 instead of NoteOff?
there are two ways to define / send note offs in midi:

1) note off messages
2) note-on messages with 0 velocity

from midi spec:
"A receiver must be capable of recognizing either method of turning off a note, and should treat them identically."

it seems pvst sends the later, but your keystep doesn't properly treat them as note-off.
I thought of the NoteOff velocity thing, but sending:

E-5 7F
Off 7F

E-5 01
Off 01

E-5 7F
E-5 01

All result in the same drone. The KeyStep is generally considered - as far as I know - a very software-rugged "plug it and it goes vroom" piece of kit, would be a shocker if its incoming MIDI implementation was off-spec, but I suppose stranger things have been known to happen!

(However, after fooling around a bit to confirm, it seems pVST can't actually send a velocity of 00, 01 is as low as the editor allows - and 01 really does mean MIDI 01, since 7F displays as 127 rather than 128. I guess pVST could stand to be updated to allow for 00 velocity, if Mr. polac is out there lurking this thread :))

User avatar
UNZ
Posts: 746
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: new pvst beta (updated 2-Jul-2020)

Post by UNZ »

7F in decimal is 127, so that's correct.
but yeah if note off sends velocity 1 instead of 0 it won't work.

polac
Posts: 319
Joined: Wed Nov 23, 2011 9:19 am
Contact:

Re: new pvst beta (updated 2-Jul-2020)

Post by polac »

I think so.

I have found 100% crash routine here:
Load any x86/x64 bit VST plugin and go to the preferences last tab (named as loadded plugin). Then load any x86/x64 bit VST plugin (could be the same one) and go again to the last tab in preferences. Crash :roll:
I was loadding plugins from the hard drive locations (edit: it doesnt matter - tested). It works ok if you are copying plugins, but after you load this 2 one and go to the prefs again - boom.

Edit2: it seems to be releated only to VST FX machine
Cannot reproduce this.
Just to make sure I'm doing it right, here are my steps in detail:

1. Launch Buzz
2. Type "vsti" in right searchbar, drag-drop a new VSTi 1.1 machine
3. Double-click VSTi machine
4. Load VST (Serum64, in this case)
5. Right click, preferences.
6. Click final of the three tabs (e.g. not Global or Global 2).
7. Click "okay".
8. Repeat steps 2-7 - going to the preferences tab of the new machine, not the old one.
Same here, no crash.
there are two ways to define / send note offs in midi:

1) note off messages
2) note-on messages with 0 velocity

from midi spec:
"A receiver must be capable of recognizing either method of turning off a note, and should treat them identically."

it seems pvst sends the later, but your keystep doesn't properly treat them as note-off.
The loader does send a note-off message(0x80), not the note-on message(0x90) with velocity 0.

River Cricket
Posts: 84
Joined: Sat Dec 20, 2014 6:53 am

Re: new pvst beta (updated 2-Jul-2020)

Post by River Cricket »

UNZ wrote:
Fri Jul 31, 2020 8:09 pm
7F in decimal is 127, so that's correct.
but yeah if note off sends velocity 1 instead of 0 it won't work.
Oh, definitely. Sorry if I wasn't clear, but I was meaning that since 7F is sending 127, then it's not a situation where "1" really means "0" (I've occasionally seen some 8-bit parameters displayed as 1-128, even though truly they're 0-127).
polac wrote: Same here, no crash.
Yeah, I didn't have a crash either, was just outlining my steps in case I was deviating from whatever rav was doing to trigger a crash.
polac wrote: The loader does send a note-off message(0x80), not the note-on message(0x90) with velocity 0.
Two questions:

1. If I have "Off" for note, and 7F for velocity, will this still be sent as velocity 0? Or is it just 0 by default, but overridable by whatever's in the Velocity field? I think some synths do actually use NoteOff velocity to shape various release curves - I think some of the high-end piano emulations do things this way?

2. Would it be possible (by which I mean, "not too much of a headache from the code-end of things") to update pVST to also allow Note-On with velocity 0?

Post Reply