Problems with sysex messages (not solved)

[carpenzano]

Fingers crossed!

Thanks for your fingers crossed , but I haven't found anything.
All the old archive's files dealing with sysex messages simply use the StrSysex primitive but there is no mention about the fact that they have been compiled as standalone or as VST.
Some files and many posts in the old archive make reference to a possible bug in the StrSysex primitive but it consisted "only" in sending different values from those received under certain circumstances.
I am in an impasse.
Could you try to compile the simple test file I have attached to my first post as a VST and check if it works?
I am using FlowStone 3.0.8.1 Skylark. Is it possible that everything is ok under a different release?
Many thanks for your help.
Giovanni

[carpenzano]

This issue is becoming a nightmare.
I have tried not to use the StrSysex primitive, writing a very simple Ruby code, the same shown at pag. 205 of the FlowStone user guide:

m = Midi.new "F0411000006412180020250023F7"
output m

and I have got the same results: the standalone (exe) version works, the VST not at all.
So it's not a problem with the StrSysex primitive.
I can't imagine where the problem is.
Any idea?
Thanks
Giovanni

[tektoog]

Hey,
Unfortunately, I also run FS 3.0.8.1... and I never used Sysex…
By pure hasard, have you tried to pass the message thru a text prim or a string prim before sending it to the output?
If yes, remove it. If not try to put one…
Put an Sample and Hold prim and an afterload prim, so you can be sure the data is sent on opening… Most of the time projects work well in FS but need afterloads to run well in DAWs…
Hope this helps

[trogluddite]

That confirms that the problem is exactly as guessed in the Reaper forum thread I linked to.

The VST plugin standard handles "normal" 3-byte MIDI events and SysEx events using two separate buffers - so that 3-byte events can be time-stamped for precise timing, which would be inappropriate for very large SysEx dumps which might take a long time to send.

What the bug indicates is that FS is trying to send SysEx using the buffer intended only for 3-byte messages, instead of the proper SysEx buffer. Hence it's fine for executables and inside FS, because the data is then sent straight to the hardware driver without buffering.

Unfortunately, it also means that there's nothing that we can do about it - the "wrapper" that turns a schematic into a plugin is hard-coded by DSPr, so only they could change it, which certainly isn't going to happen for any of the current versions (though I will sound out the Alpha-testers to see if it might be fixed for the new version when it's released).

[carpenzano]

Many thanks to both of you.
Trog, I am sure you a right. So we have to wait for a new release of FS, hoping that this big bug will be fixed.
I have to confess that, remembering the 64bit problem, I can’t feel very optimistic (moreover three emails on the matter to the dspr support without any answer).
Thanks again
Giovanni

[adic]

The same problem occurred, when I tried to make a VST for DX7 sysex controller.
As to sysex plugin, I think JUCE is better.
https://forum.juce.com/t/how-to-make-a- ... lved/15231
I tried it. See the picture (VST on Reaper).
If you are interested, I'd upload the c++ source file.

[Walter Sommerfeld]

Hi Luddite,

i also had a problem with sending SysEx Data...

After trying different ways of communicating between two FS Appz and wasting two days

I found out that SysEx only accepts values of 0..127, hex 00..7F between F0..F7.

Your Midi Monitor accepts even higher = wrong values

So please: detect values > 7F and show a SysEx error

btw: i like ur Monitor anyways - nice showing the SysEx Data after dblclick

Keep on doing!
Walter

Hint: I use MSB/LSB values from now on...

[trogluddite]

Hi Walter, nice to see you around again!

TBH, I don't think it ever occurred to me that FS would allow illegal content in the messages (though, of course, there's nothing to stop the hex string from containing them!) Thanks for pointing this out - a warning would certainly be useful!

[MichaelBenjamin]

.

[MichaelBenjamin]

.