When using the plugn wrapper, long messages don’t come all to the plugin. If a messages is split only the first portion is delivered the rest not, here is an example.
This is a waveshape dump request to a DSI evolver, and it’s response using raw devices (a simple app that opens MIDI IN/OUT) and the same thing using the plugin wrapper
and parsing the messages in the process() loop. This is in standalone build in terms of the plugin wrapper.
the second part of the messages when using raw devices the one that starts with [60:74] comes in the handleIncomingMidiMessage() not the handlePartialSysexMessage() method, witch is weird i think.
No idea why that’d happen, but also can’t really think of anything that could be done to change it. You’re rather at the mercy of the OS when it comes to message delivery.
Perhaps i wasn’t clear when i’m saying i’m using the devices directly i’m still using JUCE classses.
It doesn’t work only when used in the wrapper (those messages should appear in the process() loop since they appear in the MidiInput callback). I doubt this has anything to do with the OS, it works, just not in the case of the Audio Plugin Wrapper. MidiInput class works fine.
well no, since it’s in standalone mode and i’m using the standalone wrapper part i think it might be the wrapper’s fault. i didn’t check that in VST mode, cause i know that most of the hosts are broken in terms of MIDI SYSEX, but it has to work in standalone mode i need to send large amount of waveform data and download it too.
Well, looking at the standalone wrapper class, it should be fine… There’s really nothing in there, it just takes the message from the device and shoves it into the buffer. Can’t really see how it could go wrong…
my manager sends the dump request, the handleIncomingMidiMessage callback gets called twice with both the messages, but the audioDeviceIOCallback sends only one message to the process() loop for the filter, the second message gets lost somewhere in the midiCollector.removeNextBlockOfMessages (midiBuffer, numSamples); call.
This is the code block i inserted in the IO callback
if (midiBuffer.getNumEvents() > 0)
{
Logger::writeToLog (T("AudioFilterStreamer::audioDeviceIOCallback"));
MidiBuffer::Iterator i(midiBuffer);
MidiMessage m(0xf0);
int p;
while (i.getNextEvent (m, p))
{
Logger::writeToLog (String::toHexString (m.getRawData(), m.getRawDataSize()));
}
}
filter.processBlock (output, midiBuffer);
maybe the numSamples is causing the midiCollector to discard the second message, or maybe that the first message is 255 bytes long (i guess the 255 is the driver limit on one midi message).
I can’t figure out what’s going on there, and don’t have a device to test that sends out such large blocks. It must just be a buffer limit somewhere - maybe you could trace it through and spot where it’s getting cut off?
findActualEventLength() returns 0 on the second part, so it doesn’t get added to the queue in the MidiMessageCollector, looks like MidiBuffer does not like those messages, it should be treated as a partial sysex message and appear in the second callback handlePartialSysexMessage(). that looks to be the problem.
Ah, I see. Looks like the MidiMessageCollector hasn’t got anything to handle multi-part messages. I’ll make a note to take a look, but am a bit busy on other code areas at the moment.
No… pretty sure that it didn’t. I certainly wouldn’t have removed something like that. If you can find an old version that works, I’d love to be proved wrong!
I guess the answer would be for me to investigate, but I don’t have any kind of midi equipment set up to test with right now, and have a million other pressing things to do… If you want to do some digging I’d be glad to help with ideas!
I misread atoms post. Its actually the opposite thing. If i compile a VST plugin I do receive the complete sysex message (>256 bytes)
w/o any problems (Cubase 5.1). As a stand alone app, I receive both parts of a splitted message via handleIncomingMidiMessage
using juce midi input.
First call includes sysex start byte F0 and the second call includes sysex stop byte F7 cause the message length is only 267 bytes…
Is this the normal behaviour? If yes, what if messages are bigger than 512 bytes?
I’d expect to receive parts of a message >512 bytes within the handlepartialsysex callback if these parts neighter
contain F0 nor F7.
I could live with the above behavior but I want to also compile a MAC version and you said that the handlepartialsysex is only for MAC.
That makes me a bit nervous cause I thought I can use same code for both, MAC and Windows.
I have some code that handles incoming sysex for both Windows and Mac, and while I can’t say that I’ve completed tested it, it has worked on both platforms in all of my testing. I hope this is helpful. Here is a code snippet:
[code]
void DK10EditorJuceComponent::receiveDk10Data( int sysexBufferLen, unsigned char* sysexBuffer )
{
// if the data fits in the internal buffer
if( mSysexCurOffset + sysexBufferLen < kSysexBufferSize )
{
// if it the start of the msg, and it’s the start-of-sysex, or any byte after the start
if( ((mSysexCurOffset == 0) && (*sysexBuffer == 0xf0)) ||
(mSysexCurOffset != 0) )
{
memcpy( &mSysexBuffer[ mSysexCurOffset ], sysexBuffer, sysexBufferLen );
mSysexCurOffset += sysexBufferLen;
if( mSysexBuffer[ mSysexCurOffset - 1 ] == 0xf7 )
{
if( mDk10Data.putSysexData( mSysexCurOffset, (unsigned char *)&mSysexBuffer[ 0 ] ) )
{
// send a message to update display
//displayCurrentData();
}
// reset the buffer
mSysexCurOffset = 0;
}
}
else
{
// ERROR
// wrong data
// reset the buffer
mSysexCurOffset = 0;
}
}
else
{
// ERROR
// too much data for the buffer
// reset the buffer
mSysexCurOffset = 0;
}
thank you for the code snipped!
I do have code that works perfect in Windows but I didn’t realize that MAC uses different
methods then Windows. I am talking about handlePartialSysexMessage.
That is my concern because I thought that if I strictly use juce classes (and that is what I do),
then it will work on both, MAC and PC using the same code.
Anyway, I’ll implement the handlePartialSysexMessage code as you did.
when i’m saying i’m using the devices directly i’m still using JUCE classses.