VST SDK 2.4 SysEx planned?


#1

Is the support for midi message slonger then 3 bytes planned (Sysex), i’m playing with it and i got it to work with longer messages (witch i need for controlling older hardware) but i can’t understand everything right (most of all ensureMidiEventSize() in the VST wrapper). So i was wondering if this feature is planned at any point in the near future, if not i’ll continue my work and try to get this work 100%.

thanks


#2

TBH I had no idea that they’d added that yet! Sure, I imagine it’s fairly easy to add, so I’ll do it when I get chance.


#3

very cool, cause i don’t think that my version would be as good as yours.

there is a problem that JUCE assumes all messages to be 24byte (3bytes of data) and with longer messages it get’s messy with memeory pre-allocation in the mentioned method.


#4

Yes, it’d need some tweaks to make that more flexible.


#5

Greetings, Jules.
Listen, now we able to use long sysex messages?
My sysex data is 434 byte size (and the synth made in 2003).

I’m user of JUCE 1.45 with VST 2.4

Thanks,
Alex


#6

I’ve not done it yet, but you will be able to. Of course I don’t know if many hosts actually support doing it.


#7

Ok.
Thanks.

You can say, in what file I able correct this problem?

Cheers, Alex


#8

Well it’ll be done in the VST wrapper class.


#9

i use FLStudio and they say that it’s possible to send sysex from plugins and receive sysex to plugins, so that’s one host that does that. i’m pretty sure that reaper will support it knowing how fast that host is growing, i’m sure that cubase has to work with that.


#10

any progress on this ?

from what i’ve seen it’s not added, or am i wrong ?


#11

Sorry, no, haven’t had chance yet…


#12

I am also interested in this feature

Thanks…


#13

a few months have passed :slight_smile: and once again, beeign the annoying user i’m. i’m asking for this.

i tired to do this myself but there is some part on the pre-allocation of messages in the vst wrapper, and also i didn’t touch the VST in the juce library, so that the PluginHost could also handle those. It would be amazing to see this, all new hardware synth from DSI have sysex support for the controls.


#14

Ok, I’ll take a look at it today…


#15

Ok, I’ve checked something in - haven’t tested it myself yet though! Please have a go and let me know if it works!


#16

i have two issues

  1. when sending a midi message on the vst chain the last message stays, i have s simple vst midi monitor that just prints messages in hex, and when connecting it to the midi input of the PluginHost it keeps printing out the note-off messages when i press the keyboard (last note-off message)

  2. something changed in the library (?), i was using getSpecialLocation() to get the DLL path of my plug, now i’m getting the path for the Host application.

i was using rlatest ebuilt juce and pluginhost, no other software.

[look at the time, am i the only one crazy enough to be doing this at this time of this day? HAPPY NEW YEAR EVERYONE]


#17

Happy new year! But yes, I think you must have been the only nut who was coding at that particular moment!

Thanks for spotting those things - I’ve checked in a couple of changes that should sort it out (fingers crossed)…


#18

Looks ok, just a simple test, like on the screenshot

one bug (fixed it myself) is in the vst wrapper:

#if JucePlugin_Build_RTAS
BOOL WINAPI DllMainVST (HINSTANCE instance, DWORD dwReason, LPVOID)
#else
extern "C" BOOL WINAPI DllMain (HINSTANCE hInstance, DWORD ul_reason_for_call, LPVOID lpReserved)
#endif
{
    if (dwReason == DLL_PROCESS_ATTACH)
        PlatformUtilities::setCurrentModuleInstanceHandle (instance);

    return TRUE;
}

#endif

should be (to work for now, that has to change so that both DllMain and DllMainVST work)

#if JucePlugin_Build_RTAS
BOOL WINAPI DllMainVST (HINSTANCE instance, DWORD dwReason, LPVOID)
#else
extern "C" BOOL WINAPI DllMain (HINSTANCE hInstance, DWORD ul_reason_for_call, LPVOID lpReserved)
#endif
{
    if (ul_reason_for_call == DLL_PROCESS_ATTACH)
        PlatformUtilities::setCurrentModuleInstanceHandle (hInstance);

    return TRUE;
}

#endif

also i think that the inclusion of juce_VSTMidiEventList.h should be changed so that it’s relative to the juce main directory (i have the juce root as a dir to search for includes so that <juce.h> works).

and i guess that’s it, thank you very much for this.


#19

doh! Sorry about that typo, I was building as an RTAS too, so didn’t hit it myself.

Including that file isn’t actually needed any more - I’ve tweaked it now to avoid the problem.