next topic »

[on:]

Hello to the forum and let me first say: Arduino is greeeeaaat!

I am currently planning, developing and building a specific Midi-Controller for the Elektron Octatrack. For that I prefer(ed) to use the Midi Library written by Franky. In general this one works for me (sending CCs, NoteOn/Off) and is also greaaat! Thanks to Franky for his work!

BUT, I came across the following issue: When I use this library and power up first the Arduino Uno and afterwards the receiving device it is not possible for the receiving device to receive any midi-data. For test purposes I use the Jomox MBase, but also already checked that with the Octatrack - always the same behaviour. When I power up the receiving device first or after I pushed the Reset-Button of the Arduino Uno everything works fine.

I cross-checked that with the standard serial library - there this failure does not occur.

Anyone ever noticed this / knows a solution?

Greets,
Bruce

[Reply #1 on:]

Hi,

Very strange issue, did you try to connect your Arduino to your computer (with midi) and use a midi monitor ? (and power the arduino after launching the midi monitor to see what happen)

if you post your code here, it will help people to dig into your prob

[Reply #2 on:]

Thanks for your answer. Sure I forgot the code ... it happens also with this small piece:

Code:

#include <MIDI.h>

int poti=0;
int last=0;

void setup() {
  MIDI.begin();             // Launch MIDI with default options

}

void loop() {

   poti=analogRead(0);
   if(abs(poti-last)>2){
   MIDI.sendControlChange(101,poti/8,1); //Controller#, Wert, Kanal
   last = poti;
   }
}

When I program the same with the Serial library, as I said, everything seems fine. The code:

Code:

int poti=0;
int last =0;

void setup() {
  Serial.begin(31250);
}

void loop() {

   poti=analogRead(0);
   if(abs(poti-last)>2){
   midi(0xB0, 101, poti/8); //Midi-Typ (B=ControllerChange) + Kanal (0=1), Controller#, ControllerWert - Division durch 8: Skalierung auf Midi
   last = poti;
   }
}   

void midi(int cmd, int pitch, int velocity) {
  Serial.write(cmd);
  Serial.write(pitch);
  Serial.write(velocity);
}

Monitored it with MidiOx while resetting / powering the Arduino:

Serial library:

Code:

00001047   8  --     B0    65    7F    1  ---  CC: RPN MSB

Midi library: 

Code:

0001C4C8   8  --     B0    65    7F    1  ---  CC: RPN MSB

...Sends the current value, only differs in the timestamp.

Greets

[Reply #3 on:]

While I searched for another problem I found the solution for this ^^^.

I don't understand the background, but if I change

Code:

00041 #define USE_RUNNING_STATUS      1

to

Code:

00041 #define USE_RUNNING_STATUS      0

in Midi.h the above described issue is fixed! Also refer to http://arduinomidilib.sourceforge.net/a00004_source.html

... maybe one day this helps someone else ...

Greets,
Bruce

[Reply #4 on:]

Running status was a way to deal with hanging notes produced by unstable MIDI connections. It should not be needed normally, so it is odd that it is on by default.

Having said which it is not clear why enabling it would cause the behaviour you describe. But thanks for reporting the fix!

[Reply #5 on:]

I finally (think I) found the reason for the described "bug": It isn't a bug - especially not a bug within the Midi Library. The reason for the above described behaviour is in the way how "running status" works:

I always tested my hardware & program with only one potentiometer routed to one cc# - so (maybe) this is how it goes: I power up the UNO, it gets the value from the potentiometer on the analog-in pin, sends the status via midi one time and afterwards only the databytes. So when I later power up my midi receiving device (i.e. the Jomox MBase) it never gets the status byte.

I confirmed this by changing the midi-cc# within the program-loop, result: everything works flawless, I can power up the receiving device whenever I want.

My final box will contain 16 pots - so I think the "bug" will go away.

edit: ^^ THIS was somehow wrong. My last test was incorrect - I didn't notice that I still had running status switched off while testing. When I switch it on, changing the cc# does not remove the "bug", but - thanks to a hint of "Franky" - changing the channel does it (because the status byte does change when the channel is changed, but does not change when changing the cc# as this is included in the databytes)...

Anyway .. for me this is a "bug" of the running status concept ... (?)

I guess it could be solved by sending something like an "interrupt" while no "real" midi-data is sended ...

Bruce