Polac VST crashes in certain circumstances.

[onecircles]

A vst I'm working with, (geist) can accept midi data into different "engines" of the vst by using different midi channels. Today I configured the akai mpd to transmit each of it's 4 pad banks on a different channel, and the vst started crashing as soon as it received midi input. Buzz would crash immediately afterward. The vst loader is set to receive on all channels. I'm transmitting on 1a 2a 3a and 4a.

I eliminated the mpd as the cause of this crash by loading another preset where all the pads were transmitting on common channel(1a), which never gave me problems before.

I initially was using the 64 bit version of this vst plugin. The problem is less common in the 32 bit version of the plugin but still occurs. The 64 bit version of the plugin crashes immediately upon receiving data now. Could the plugin file be corrupted?

Does it even make sense to use 64 bit plugins in 32 bit buzz? That's what I'm using, and I'm running windows 7 x64. Maybe you can answer that question too.

I've done some experimentation. Now I'm running the 32 bit version of geist. It behaves well if I hit one pad at a time. If I hit 4 pads simultaneously it crashes almost immediately, 3 pads slightly less frequent, and I was able to get it to crash hitting 2 pads after hitting them for a bit.

Sir Polac, I don't know if this is a related crash, as I'm doing some things differently, but tell me if you want me to try any arcane bug testing procedures, I'd be glad to help. I'm running the mpd through polac midi bus.

[onecircles]

Welp I found a workaround fix. I moved the mpd to another usb port and I'm unable to reproduce the crash in the 32 bit version of the plugin, even when mashing all the pads at the same time. I'm sort of scared to try the 64 bit version tonight, as this hiccup interrupted my creative flow. But I'll try it tomorrow.

[onecircles]

I've found another way to produce a crash. If I play the pads and send midi note data while also playing the sliders and sending cc data, it causes a crash. This happens regardless of what machine I place within the vst wrapper. I tried it with m4w2 and jacinth anyway.

And I have discovered something else interesting. When I open midi ox and watch the midi monitor there's a new sort of message that's getting interleaved within the cc data. Here's what it says throughout the range of the control. It also transmits sysx when playing midi notes. I don't know much about midi at all :\ I tried resetting the mpd to factory defaults and am still getting the same thing.

TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT
Opened MIDI Input
Opened MIDI Output
00000A56 10 2 F0 Buffer: 10 Bytes System Exclusive
SYSX: F0 47 00 78 41 00 02 0B 00 F7
00000A57 1 -- F0 Buffer: 10 Bytes System Exclusive
SYSX: F0 47 00 78 41 00 02 0B 00 F7
00000A74 10 2 B0 19 01 1 --- Control Change
00000A75 10 2 F0 Buffer: 10 Bytes System Exclusive
SYSX: F0 47 00 78 41 00 02 0B 01 F7
00000A76 1 -- F0 Buffer: 10 Bytes System Exclusive
SYSX: F0 47 00 78 41 00 02 0B 01 F7
00000AA6 10 2 B0 19 02 1 --- Control Change
00000AA7 10 2 F0 Buffer: 10 Bytes System Exclusive
SYSX: F0 47 00 78 41 00 02 0B 02 F7
00000AA8 1 -- F0 Buffer: 10 Bytes System Exclusive

[onecircles]

Today I woke up with this problem still vexing me, so I tried another solution. I took the mpd and plugged it into the midi port of my sound card, rather than running it through the USB.

This is kind of weird because I don't have the power supply for the mpd, so I had to keep the usb plugged in. So it's possible that midi data was transferred through both protocalls.

Anyways, the midi monitor in midi ox immediately started giving normal data without sysx commands interleaved in them although I wasn't actually able to get the mpd to transmit any data over the midi cable itself when I isolated it in midi ox.

Then I jumped into pvst and mashed all the pads and flipped the sliders and turned all the knobs with my toes at the same time and wasn't able to get it to crash.

So hopefully it resolved itself, who knows. We'll see if it returns when I practice the pads today. I restarted several times while working on this issue last night, so I don't think it was the restart that fixed it. This is the arcane world I find myself in. Maybe what I need is a lucky rabbits foot.

[onecircles]

Happy to say I've solved the issue on my end. I can say for certain that the sysex data was crashing the plugin, because when I figured out how to remove the interleaved data the crashes disappeared.

It turns out that saving a preset to the the MPD in vyzex, (which is the program that's used to edit the MPD on your computer), is what was causing that behavior to occur. The very workable workaround fix I discovered was just unplugging the mpd from the usb and plugging it back in. If I write a preset from my computer to the mpd the sysex data appears in my midi monitor, but after unplugging and replugging the MPD, it's gone.

Also disregard my earlier post about the midi cable, that was likely just a coincidence. It turns out my breakout cable wasn't attached to my sound card *facepalm*

Hopefully this information might be useful to another user going down the same path, or to Polac, since this is an edge case scenario that very reliably produces tons of crashes. I forgot to mention that I'm using the most modern version of the plugin as well as the latest buzz build.

fin

[onecircles]

Update: Everything was so stable that I tried using the 64 bit plugin again. With the sysx situation fixed it was stable for a while. I could mash on the pads and I was actually able to get some work done, but when I switched midi channels to begin playing drums I had a complete system freeze. I left the computer alone for an hour and a half and when I came back the mouse was still frozen so I switched it off.

It's becoming clear now, though, that something with either vyzex or the mpd itself is fishy. I think it's going to be stable from now on if I use the 32 bit plugin, but I've had my mpd presets switching and not saving correctly, and I also figured out that what causes the mpd to start sending interleaved sysx data is any interaction with vyzex, but it's then cured by unplugging and replugging the USB.

I also haven't updated my usb drivers in maybe 4 months, so I'm going to do that tomorrow or soon.

fin?

[polac]

Does it even make sense to use 64 bit plugins in 32 bit buzz? That's what I'm using, and I'm running windows 7 x64. Maybe you can answer that question too.

I wouldn't load the x64 version to a x86 Buzz unless you are really huge amounts of samples in Geist.
As a rule always use x86 version in x86 Buzz to avoid the additional bridgeing.

It also transmits sysx when playing midi notes.

The sysex stuff does not get to the loaders or other machines because Buzz filters them out, so they shouldn't cause a crash in loader code.

[onecircles]

Hmm, interesting. On my end it seems like that is definitely either a cause or a correlation, but of course I'm just a musician guy.

The crash is very reproduceable and always occurs after the mpd interacts with vyzex and begins spewing sysx data, the crash goes away if I unplug and replug the mpd, which also removes the sysx data for some reason.

Thank you, that's good to know about 64 bit plugins.