Launchkey on Gem

tobias_s

so the midi partly works now but there is a problem i just cant fix.

i have a novation launchkey 37 mk3 and a c++ bela program that uses it. the midi device has 2 ports, which on the old bela were hw:1,0,0 and hw:1,0,1. on the gem they are hw:0,0,0 and hw:0,0,1. the first port is for the regular keys, the second port is for advanced functions. i use the first one for key signals and the second one for example for pad signals and to make the led pads on the controller light up.
For that i first use
controlMidi->writeMessage(0x90, 15, 12, 127); //put controller in daw mode
controlMidi->writeMessage(0xB0, 15, 0x03, 0x01) //put controller in drum mode
controlMidi->writeMessage(0x90, 9, 40, 17) //pad number 40 to color green(17)

which is all according to the launchkey's programmer's reference guide.

i constantly parse the messages of both hw:0,0,0 and hw:0,0,1 and prettyprint them.
hw:0,0,0 works exactly like on the old bela (there it was hw:1,0,0)
for example i get the prettyprints on key signals.
hw:0,0,1 does not work at all.
no pretty prints, no led on/off

amidi -l and aconnect -i and aconnect -o both seem to be fine, no difference to the old bela, except the names are a little different:
on the old it was

root@bela ~/Bela# amidi -l
Dir Device Name
IO hw:0,0 f_midi
IO hw:1,0,0 Launchkey MK3 37 MIDI 1
IO hw:1,0,1 Launchkey MK3 37 MIDI 2

and on the new:

root@bela:~/Bela# amidi -l
Dir Device Name
IO hw:0,0,0 Launchkey MK3 37 LKMK3 MIDI Out
IO hw:0,0,1 Launchkey MK3 37 LKMK3 DAW Out
IO hw:1,0 f_midi

there is exactly one thing i can do to hw:0,0,1:
amidi -p hw:0,0,1 -S "9F 0C 7F" (equivalent to controlMidi->writeMessage(0x90, 15, 12, 127); //put controller in daw mode)
puts the controller into daw mode - but this only works after or during running my program so some priming by the Midi.h library is necessary. however my program does controlMidi->writeMessage(0x90, 15, 12, 127); and that has no effect so sending from c++ does nothing - only sending from amidi-p works.
any other messages over amidi -p do nothing but that is the same on the old bela.

I thought maybe the Midi.h lib has problems handling 2 devices on the gem but when i only init the hw:0,0,1 device in my program i have the same problem.

there are no error messages or warnings indicating something being wrong.

sorry for the long post, i would not do it if i felt i had any chances left debugging this myself without weeks of digging into it haha

i thought maybe someone who knows the Midi.h lib would have an intuition on what could be the problem.

giuliomoro

FWIW, just to make sure it's not a silly typo of some sort:

tobias_s . i quickly made a small example:

midi_byte_t statusByte = 0x9F; // control change on channel 0

that's not a control change status byte, despite what the comment says.

tobias_s amidi -p hw:0,0,1 -S "9F 0C 7F" (equivalent to controlMidi->writeMessage(0x90, 15, 12, 127); //put controller in daw mode)

this uses 0x90 instead of 0x9f above.

tobias_s amidi -p hw:0,0,1 -S "9F 0C 7F" (equivalent to controlMidi->writeMessage(0x90, 15, 12, 127); //put controller in daw mode)

Also here, the amidi and writeMessage arguments are not equivalent.

I am wondering what 'switching to DAW' entails on the device side: does it simply change its internal mode of operation or does it briefly disappear from the USB bus and reappear and/or change its USB descriptors?

Can you open a terminal, ssh onto the board and run dmesg -W while in a different terminal (or IDE) you do whatever is needed to switch it to DAW mode? Do you see anything printed when the switch happens?

tobias_s

p.s. i quickly made a small example:

	#include <Bela.h>
	#include <libraries/Midi/Midi.h>
	#include <string>
	
	Midi midi;
	Midi controlMidi;
	std::string midiPort = "hw:0,0,0";
	std::string controlMidiPort = "hw:0,0,1";
	
	bool setup(BelaContext *context, void *userData)
	{
		
		int ret = midi.readFrom(midiPort.c_str());
		if(ret <= 0)
		{
			fprintf(stderr, "Error %d when reading from device %s\n", ret, midiPort.c_str());
			return false;
		}
		ret = midi.writeTo(midiPort.c_str());
		if(ret <= 0)
		{
			fprintf(stderr, "Error %d when writing to device %s\n", ret, midiPort.c_str());
			return false;
		}
		midi.enableParser(true);
	    //errors from the following lines.
		//midi.getParser()->setCallback(midiMessageCallback, (void*)midiPort.c_str()));
		//midi.getParser()->setSysexCallback(sysexCallback, (void*)midiPort.c_str()));
	
		int ret2 = controlMidi.readFrom(controlMidiPort.c_str());
		if(ret2 <= 0)
		{
			fprintf(stderr, "Error %d when reading from device %s\n", ret2, controlMidiPort.c_str());
			return false;
		}
		ret2 = controlMidi.writeTo(controlMidiPort.c_str());
		if(ret2 <= 0)
		{
			fprintf(stderr, "Error %d when writing to device %s\n", ret2, controlMidiPort.c_str());
			return false;
		}
		controlMidi.enableParser(true);
	
	    //the following seems to do nothing
		midi_byte_t statusByte = 0x9F; // control change on channel 0
		midi_byte_t controller = 12; // controller number 30
		midi_byte_t value = 127; // value : 0 or 127
		midi_byte_t bytes[3] = {statusByte, controller, value};
		controlMidi.writeOutput(bytes, 3); // send a control change message
	
	    //this also seems to do nothing
		//midi.writeOutput(bytes, 3);
		//controlMidi.writeMessage(0x90, 15, 12, 127);
		return true;
	}
	
	void render(BelaContext *context, void *userData)
	{
		int num;
		
		while((num = midi.getParser()->numAvailableMessages()) > 0){
			static MidiChannelMessage message;
			message = midi.getParser()->getNextChannelMessage();
	        //channel 7 messages spam - dont show
			if(message.getType() == kmmNoteOn && message.getChannel() != 7){
				message.prettyPrint();
			}
		}
		
		while((num = controlMidi.getParser()->numAvailableMessages()) > 0){
			static MidiChannelMessage message2;
			message2= controlMidi.getParser()->getNextChannelMessage();
			message2.prettyPrint();
		}
	}
	
	void cleanup(BelaContext *context, void *userData)
	{
	
	}

maybe this helps. sorry for the hastily written code.
behaviour:

errors on:

	//midi.getParser()->setCallback(midiMessageCallback, (void*)gMidiPort.c_str()));
	//midi.getParser()->setSysexCallback(sysexCallback, (void*)gMidiPort.c_str()));

however i never used that before

hw:0,0,0 works perfectly.
None of the 2 puts it in daw mode:
```
	controlMidi.writeOutput(bytes, 3); // send a control change message

	//midi.writeOutput(bytes, 3);
```
...but if i send amidi -p hw:0,0,1 -S "9F 0C 7F" it goes into daw mode. HOWEVER: only if i initialize the hw:0,0,0. if i comment out all the hw:0,0,0 stuff from my code and restart everything and rebuild and send the amidi -p command nothing happens. then when i uncomment the hw:0,0,0 part of the code and run again it goes into daw mode. seems like the amidi -p message is in some queue that waits until hw:0,0,0 is initialized and then has an effect.
when in daw mode there are no prettyPrints() from hw:0,0,1 (as said above on the old bela they came)

sorry again for the long post!

tobias_s

giuliomoro that's not a control change status byte, despite what the comment says.

ah ups sorry yes it is not control change on channel 0 theose were comments i didnt remove, sorry! it should be the following - in the mean time i checked and it works on the old bela.

	    //works on 'old' bela
		midi_byte_t statusByte = 0x9F; // Note On on channel 15
		midi_byte_t byte1 = 12; // byte1 is 12
		midi_byte_t byte2 = 127; // byte2 is 127
		midi_byte_t bytes[3] = {statusByte, byte1, byte2};
		controlMidi.writeOutput(bytes, 3); // send a control change message
		
	    //this also works on the old bela
		//controlMidi.writeMessage(0x90, 15, 12, 127);

giuliomoro Also here, the amidi and writeMessage arguments are not equivalent.

isn't status Note On (0x90) on channel 15 (0x0F) equivalent to setting the first byte to 0x9F? then it would be equivalent no? to untangle:

writeOutput(...) sends the 3 bytes 0x9F, 12 (=0x0C), 127 (=0x7F)

writeMessage(...) sends
NoteOn (0x90) on channel 15 (0x0F) resulting in 0x9F
with byte1 12 (0x0C)
and byte2 127 (0x7F)

amidi -p sends 0x9F, 0x0C, 0x7F

all 3 put the device in daw mode on the old bela.

giuliomoro I am wondering what 'switching to DAW' entails on the device side: does it simply change its internal mode of operation or does it briefly disappear from the USB bus and reappear and/or change its USB descriptors?

I dont know what exactly the daw mode does on the device, i can observe the following:

when daw mode is successfully set all the leds turn off - this is how i can tell that it has been set.
after setting in daw mode hitting the pads sends messages from hw:*,0,1, i can tell because on the old bela the pad messges get received and on the gem not.
in daw mode i can send messages to the controller to set the led's otherwise the leds have predefined behaviour
from what i can tell from amidi -l nothing changes regarding what bela sees.

giuliomoro Can you open a terminal, ssh onto the board and run dmesg -W while in a different terminal (or IDE) you do whatever is needed to switch it to DAW mode? Do you see anything printed when the switch happens?

also here bela sees nothing. running the program - with or without setting to daw mode - only produces:
[ 1903.293984] rtdm_pruss_irq_open
[ 1903.299100] rtdm_pruss_irq_open
[ 1905.976752] rtdm_pruss_irq_close
[ 1905.976835] rtdm_pruss_irq_close

so i suppose daw mode simply changes it's internal mode of operation

All the above hold for the old bela. on bela gem the dmesg -w output is different:

[ 285.869267] remoteproc remoteproc1: powering up 30078000.pru
[ 285.875646] remoteproc remoteproc1: Booting fw image am62-pru1_1-fw, size 24012
[ 285.883064] remoteproc remoteproc1: remote processor 30078000.pru is now up

is the output of the program regardless if i put the device in daw mode (by sending the amidi -p message before running the program) or not

Thanks a lot for the help!

giuliomoro

tobias_s isn't status Note On (0x90) on channel 15 (0x0F) equivalent to setting the first byte to 0x9F? then it would be equivalent no?

Yes you are right.

tobias_s is the output of the program regardless if i put the device in daw mode (by sending the amidi -p message before running the program) or not

OK so it seems that it's an internal change and no change is visible on the USB.

The manual states that the device can respond to Universal Device Inquiry SysEx messages:

It doesn't quite mention whether both devices are meant to respond or only one, but it's worth a try.

The behaviour where the data is not sent out unless you run the Bela program is quite weird and, I assume, unrelated to the Bela program itself, which does nothing else than opening the device file descriptor. I would try with four terminals: in one you open amidi -d -p hw:0,0,0, in one you open amidi -d -p hw:0,0,1. These will print any incoming messages. Then in the other two terminals you can send messages to each device and see what you get back. You can try sending the Universal Device Inquiry SysEx to both, or the 0x9F, 0x0C, 0x7F message on the second one. See if the fact that the input is open (by amidi -d) makes it so that the outputs are sent immediately?

Ultimately, it seems that something changed as kernel or operating system level, rather than something specific to the Bela library or application code. FWIW, writes on Bela are not performed from the thread that calls write*(), rather they are pushed to a queue that another thread then reads and writes to the actual device. As such, if you are ever expecting a response at a specific time, make sure you sleep briefly (if not on the audio thread) to ensure that the output queue is flushed to the device) before you wait for the incoming message.

tobias_s

p.s. just fyi on the gem if i turn off the bela the connected midi device still receives power and is on. On the old bela the power was cut and the device turned off in that case. i dont think it has anyhting to do with this problem and maybe it's just a difference between beaglebone black and pocketbeagle 2 but i thought i'd add the info maybe it's relevant to you.

tobias_s

okay thanks a lot, this 4-terminal method really helped!
so in the 4 terminal check everything works perfectly.
amidi -p -S messages only go out when the midi device is opened (whatever that means) so either when the program is running or when amidi -d -p is active in a terminal.

After digging deeper i found that the device is never opened. the function readFrom in Midi.cpp has the following code. I hope this is the right backup - i overwrote the original and on github there seems to be a different version of Midi.cpp. could it be that the bela gem shipped with different version of Midi.cpp than what is on github/was it maybe shipped with an old version? I copied the github version of Midi.cpp to bela but it is not compatible due to xenomai_wrapper.

int Midi::readFrom(const char* port){
	if(port == NULL){
		port = defaultPort;
	}
	inPort = port;
       if(!exists(inPort)
		return 1;

i changed the return value to -1 and then i get an error, so the inPort is not in ListAllPorts() and therefore alsaIn was null and this is why no messages were received.

anyway Midi::listAllPorts() was buggy and after fixing that everything worked.
The old version was:

std::vector<Midi::Port> Midi::listAllPorts(){
	std::vector<Port> ports;
	int card = -1;
	int status;
	while((status = snd_card_next(&card)) == 0){
		if(card < 0){
			break;
		}
		snd_ctl_t *ctl;
		char name[32];
		int device = -1;
		int status;
		sprintf(name, "hw:%d", card);
		if ((status = snd_ctl_open(&ctl, name, 0)) < 0) {
			error("cannot open control for card %d: %s\n", card, snd_strerror(status));
			return ports;
		}
		do {
			status = snd_ctl_rawmidi_next_device(ctl, &device);
			if (status < 0) {
				error("cannot determine device number: %s", snd_strerror(status));
				break;
			}
			if (device >= 0) {
				snd_rawmidi_info_t *info;
				snd_rawmidi_info_alloca(&info);
				snd_rawmidi_info_set_device(info, device);
				// count subdevices:
				snd_rawmidi_info_set_stream(info, SND_RAWMIDI_STREAM_INPUT);
				snd_ctl_rawmidi_info(ctl, info);
				unsigned int subs_in = snd_rawmidi_info_get_subdevices_count(info);
				snd_rawmidi_info_set_stream(info, SND_RAWMIDI_STREAM_OUTPUT);
				snd_ctl_rawmidi_info(ctl, info);
				unsigned int subs_out = snd_rawmidi_info_get_subdevices_count(info);
				//number of subdevices is max (inputs, outputs);
				unsigned int subs = subs_in > subs_out ? subs_in : subs_out;

				for(unsigned int sub = 0; sub < subs; ++sub){
					bool in = false;
					bool out = false;
					if ((status = is_output(ctl, card, device, sub)) < 0) {
						error("cannot get rawmidi information %d:%d: %s",
						card, device, snd_strerror(status));
						return ports;
					} else if (status){
						out = true;
						// writeTo
					}

					if (status == 0) {
						if ((status = is_input(ctl, card, device, sub)) < 0) {
							error("cannot get rawmidi information %d:%d: %s",
							card, device, snd_strerror(status));
							return ports;
						}
					} else if (status) {
						in = true;
						// readfrom
					}

					if(in || out){
						Port port = getPort(info);
						port.hasInput = in;
						port.hasOutput = out;
						ports.push_back(port);
					}
				}
			}
		} while (device >= 0);
		snd_ctl_close(ctl);
	}
	return ports;
}

and the new version is


std::vector<Midi::Port> Midi::listAllPorts(){
	std::vector<Port> ports;
	int card = -1;
	int status;
	while((status = snd_card_next(&card)) == 0){
		if(card < 0){
			break;
		}
		snd_ctl_t *ctl;
		char name[32];
		int device = -1;
		int status;
		sprintf(name, "hw:%d", card);
		if ((status = snd_ctl_open(&ctl, name, 0)) < 0) {
			error("cannot open control for card %d: %s\n", card, snd_strerror(status));
			return ports;
		}
		do {
			status = snd_ctl_rawmidi_next_device(ctl, &device);
			if (status < 0) {
				error("cannot determine device number: %s", snd_strerror(status));
				break;
			}
			if (device >= 0) {
				snd_rawmidi_info_t *info;
				snd_rawmidi_info_alloca(&info);
				snd_rawmidi_info_set_device(info, device);
				// count subdevices:
				snd_rawmidi_info_set_stream(info, SND_RAWMIDI_STREAM_INPUT);
				snd_ctl_rawmidi_info(ctl, info);
				unsigned int subs_in = snd_rawmidi_info_get_subdevices_count(info);
				snd_rawmidi_info_set_stream(info, SND_RAWMIDI_STREAM_OUTPUT);
				snd_ctl_rawmidi_info(ctl, info);
				unsigned int subs_out = snd_rawmidi_info_get_subdevices_count(info);
				//number of subdevices is max (inputs, outputs);
				unsigned int subs = subs_in > subs_out ? subs_in : subs_out;

					for(unsigned int sub = 0; sub < subs; ++sub){
						bool in = false;
						bool out = false;
						int statusOut = is_output(ctl, card, device, sub);
						if (statusOut < 0) {
							error("cannot get rawmidi output information %d:%d:%d: %s",
							card, device, sub, snd_strerror(statusOut));
							return ports;
						}
						else if (statusOut){
							out = true;
							// writeTo
						}

						int statusIn = is_input(ctl, card, device, sub);
						if (statusIn < 0) {
							error("cannot get rawmidi input information %d:%d:%d: %s",
							card, device, sub, snd_strerror(statusIn));
							return ports;
						}
						else if (statusIn) {
							in = true;
							// readfrom
						}

						if(in || out){
							// Refresh ALSA info for this exact subdevice before creating the name.
							snd_rawmidi_info_set_device(info, device);
							snd_rawmidi_info_set_subdevice(info, sub);
							snd_rawmidi_info_set_stream(info, in ? SND_RAWMIDI_STREAM_INPUT : SND_RAWMIDI_STREAM_OUTPUT);
							if ((status = snd_ctl_rawmidi_info(ctl, info)) < 0) {
								error("cannot get rawmidi information %d:%d:%d: %s",
								card, device, sub, snd_strerror(status));
								return ports;
							}
							Port port = getPort(info);
							port.hasInput = in;
							port.hasOutput = out;
							ports.push_back(port);
						}
					}
			}
		} while (device >= 0);
		snd_ctl_close(ctl);
	}
	return ports;
}

So the problem was that in setting the ports for the subdevices, the info was not updated.
thanks a lot for the help in looking for the problem!! and maybe this can be included in the next update!

giuliomoro

So it looks like the old code for listAllPorts() was mistakenly assuming that a device with output capabilities would also have input capabilities and did not properly return devices with only input capabilities. Seems reasonable, as I never had one input-only device to test. The fix seems to make sense.

Why is this relevant here, though? Is there a device that is input-only? The first one perhaps?

I'll add the fixes to the next release, thanks.

tobias_s

Thanks for the quick reply!

Both ports are IO not input only. Small clarification on why it affected my case:

listAllPorts() had two issues:

The function reused status in a way that automatically sets a device that has output capabilities automatically to also have input capabilities, right, and i changed that but that was not the problem. hw:0,0,0 and hw:0,0,1 both have input and output.

What caused the error in my setup: the snd_rawmidi_info_t *info used in the initialization Port port = getPort(info) was not refreshed for the new value of sub .
So subdevice metadata never changed and the std::vector<Port> ports probably contained something like {"hw:0,0,0", "hw:0,0,0", "hw:1,0,0"} when it should be {"hw:0,0,0", "hw:0,0,1", "hw:1,0,0"}.

Thanks for putting it into the next release!