Midi output weirdness

General JUCE discussion
1

Hello,

I use midi output to send out sysex of 4872 bytes.
But when I use scoped pointer it does not work anymore but truncate the sysex to 3840 bytes.
Let me explain :
It’s as if the midi output need time to open/close the device, and that if set the opening device / ‘delete’ the pointer in the same function of my sendMessageNow(message); it does not work (which is also what does scopedPointer if I understand).
But if I delete the pointer a little ‘later’ (outside the loop) manually, then it works.

Example :

    MidiOutput * currentMidiOutput = nullptr;
        switch (which)
    {
case 1:   
        {
            currentMidiOutput = MidiOutput::openDevice(midiOutputsList.indexOf(midiOut));                
            if (currentMidiOutput != nullptr && sysexDataSize!=0)
                currentMidiOutput->sendMessageNow(message);            
            
            if (currentMidiOutput !=nullptr)
                delete currentMidiOutput;
            break;
        }   
default:    
        {
        }

This FAIL, while JUST moving the deletion of the pointer ‘later’ WORK

    MidiOutput * currentMidiOutput = nullptr;

        switch (which)
    {
case 1:   
        {
            currentMidiOutput = MidiOutput::openDevice(midiOutputsList.indexOf(midiOut));              
  
            if (currentMidiOutput != nullptr && sysexDataSize!=0)
                currentMidiOutput->sendMessageNow(message);            
    
            break;
        }   
default:    
        {
        }
 if (currentMidiOutput !=nullptr)
                delete currentMidiOutput;

The problem, I’m worried about reliability now… Maybe on some fast computers this will work and fail on slower ?
Or is there any reason behind this ? Jules ?

Salvator

2

I’m not surprised that it doesn’t work!

If you send some data to a device, most device drivers will probably add it to a buffer somewhere and use some other thread to actually do the input/iutput, so closing the device immediately is a bad move!

3

Ok,thanks for the explanation,
So I guess the I need to add an ugly timer or callback of some sort to stop it later…

Salvator

4

For the record, I am getting SysEx truncation of exactly 3840 bytes as well – not with JUCE, but when doing some prototyping in Max. I am trying to send some medium-length sysex messages (around 6kb), on a Mac OS 10.8 system, and getting all kinds of weirdness.

I'm seeing different MIDI output devices respond (er, fail) differently. The EMU XMidi 1x1 USB dongle seems to stall partway through the sysex send, and leaves the hardware device hanging.

I'm seeing the 3840 byte trunction with a Profire 2626 MIDI output (the Profire is running the latest driver, v2.4.2). According to the MIDI Monitor app, it sends 3840 bytes, calls that a complete sysex message (although it does not end in a 247 byte), and then spits out the rest of the message in 256-byte (invalid) chunks. At least when the Profire MIDI output is done failing, it does not leave the hardware device hanging, but neither does it sucessfully transmit its message.

I'm attaching trying to attach a screenshot (but forum says "file could not be uploaded) of what the MIDI Monitor app shows - the port "To Profire 2626" that appears as the Source is found under MIDI Monitor's "Spy on output to destinations" device list.

These two types of failure for the two MIDI output devices consistently happen. I believe there is some weirdness in how different devices' MIDI drivers interact with CoreMIDI, but I don't understand the weirdness beyond that.

5

Finally got the 6k SysEx send to work, using a MOTU MicroLite interface. I changed nothing in my Max prototype, except for selecting a different MIDI output.

So, evidence suggests that on the Mac anyways, there is some bad MIDI driver mojo floating around. The MicroLite came with its own drivers, but the Emu XMidi just uses default CoreMIDI drivers (Emu wrote [url=http://www.emu.com/index.php/product-xmidi-1x1-tab?id=46#latest-downloads]a custom Windows driver[/url], but not a Mac one).

And thanks to MOTU for not dropping the ball on writing a solid MIDI driver!