Problem wih linux midi


#1

Hi, I have a proyect made in juce that runs fine in windows and osx, but now I’m testing it on linux (ubuntu 10.04 amd64), and having problems with the midi comunication.

to make it easier to spot out I’ve made a small program to send a midi sysex to a device that made that device answers with another sysex (like a network ping)

if I send the sysex using amidi everithng works:

$ amidi -l
Dir Device    Name
IO  hw:1,0,0  DigiTech GSP1101 MIDI 1
$ cat /dev/midi1 | hd &
$ amidi --port=hw:1,0,0 --send-hex="f0 00 00 10 7f 7f 7f 01 6e f7"
$ 00000000  f0 00 00 10 00 5f 01 02  00 00 5f 01 00 12 f7 f0  |....._...._.....|

but if I try doing so in juce it doesn’t work, what is worse it seams to not been any mesg send neither to the midi device (/dev/midi1) or the usb port where it is connected (sniffing using sudo cat /sys/kernel/debug/usb/usbmon/2u)

where is my juce test code:

String const GSP_1101_MIDI_ID = "DigiTech GSP1101";
struct MyCallback : public MidiInputCallback {
	bool received;
	MyCallback() : received(false) {}
	virtual ~MyCallback() {}
	virtual void handleIncomingMidiMessage (MidiInput *source, const MidiMessage &message) {
		received = true;
		cout << "Midi input received" << endl;
	}
};
int main_ (int argc, char* argv[]) {
   	const ScopedJuceInitialiser_NonGUI juceSystemInitialiser;
	MyCallback* cb = new MyCallback;
	StringArray midevs = MidiInput::getDevices ();
	MidiInput* mi = MidiInput::openDevice(midevs.indexOf(GSP_1101_MIDI_ID), cb);
	StringArray modevs = MidiOutput::getDevices ();
	MidiOutput* mo = MidiOutput::openDevice(modevs.indexOf(GSP_1101_MIDI_ID));
	if (!mi || !mo) return -1;
	mi->start();
	unsigned char const echoTest[]= { 0x00, 0x00, 0x10, 0x7f, 0x7f, 0x7f, 0x01, 0x6e };
	MidiMessage midiMessage = MidiMessage::createSysExMessage(echoTest, sizeof(echoTest));
	mo->sendMessageNow(midiMessage);
	cout << "Midi output sent" << endl;

	while (!cb->received) {
		Thread::sleep(200);
	}

	mi->stop();
	delete mo;
	delete mi;
	delete cb;
    return 0;
}

it runs untill the while loop where it never left

please any help would be very appreciated.
regards


#2

I don’t actually have any midi devices in my linux box to test with, so most of the linux midi code was contributed by other people - not really sure what to suggest. If you get some breakpoints inside juce_linux_Midi.cpp it should be pretty easy to see where it’s failing?


#3

Since I (and other Juce users) encountered the same issue under Linux, I spent some time to debug this.

I noticed that iterateMidiDevices() attempts to create connections between virtual Juce, and physical MIDI IN/OUT devices, but the connection for MIDI OUT didn’t work as displayed by aconnect:

This happens, because iterateMidiDevices() uses the wrong function to create the MIDI Out connection.

Solutiuon: replace

  snd_seq_connect_from (seqHandle, portId, sourceClient, sourcePort);

by:

if( forInput )
  snd_seq_connect_from (seqHandle, portId, sourceClient, sourcePort);
else
  snd_seq_connect_to (seqHandle, portId, sourceClient, sourcePort);

and it will finally work!
MIDI transfers are very reliable, even SysEx under stress conditions. :slight_smile:

Btw.: since this is my first positing here, I would like to thank Jules for the great work! Ca. 15 months ago Juce inspired me to get rid of “modern” OO programming languages, and to learn C++ instead. I like the ideas behind Juce, and I like C++ since it can also be used for microcontrollers w/o real performance drawbacks.

Best Regards, Thorsten.


#4

That’s great, thanks very much for the tip! I’ll take a look and get that sorted out!


#5

MidiInput needed to play a midifile?


#6

No, to program MIDI Controller Hardware :slight_smile:

Best Regards, Thorsten.


#7

T.K thanks

know how to play a midi file on Linux or Kar juce?

I need and I could not implement it on linux, in windows I had to use octar winmm.dll APIs

in windows as I can.
play
pause
stop
file load Kar or midi
set and get the playback position in milliseconds
get playing time in milliseconds.

my class for player midi in windows http://www.rawmaterialsoftware.com/viewtopic.php?f=6&t=7105