Page 24 of 24

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

Posted: Sun Jul 12, 2020 10:05 am
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.

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

Posted: Mon Jul 13, 2020 10:28 pm
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

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

Posted: Tue Jul 14, 2020 1:27 am
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 ... .

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

Posted: Wed Jul 15, 2020 12:18 pm
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.

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

Posted: Wed Jul 15, 2020 8:39 pm
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:

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

Posted: Wed Jul 15, 2020 9:49 pm
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.

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

Posted: Thu Jul 16, 2020 3:18 pm
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:

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

Posted: Wed Jul 29, 2020 6:46 pm
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.

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

Posted: Thu Jul 30, 2020 4:39 pm
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.

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

Posted: Fri Jul 31, 2020 1:49 am
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 :))

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

Posted: Fri Jul 31, 2020 8:09 pm
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.

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

Posted: Fri Jul 31, 2020 8:10 pm
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.

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

Posted: Sat Aug 01, 2020 1:39 am
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?