MIDI_CREATE_DEFAULT_INSTANCE

[NicoHood]

Is it possible that you can replace this:
https://github.com/FortySevenEffects/arduino_midi_library/blob/master/src/midi_Defs.h#L172

With this now:
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/variants/leonardo/pins_arduino.h#L358

Even 1.0.6 compatible:
https://github.com/arduino/Arduino/blob/ide-1.0.x/hardware/arduino/variants/leonardo/pins_arduino.h

Not sure if the older 1.0.5 has this definition, but its outdated. This definition is more general and should work with more MCUs.

[NicoHood]

Another thing I want to mention:
I do not understand the use of namespace here. I never used it for AVR programming and to be honest I dont know 100% what it does. May you give me a quick hint, maybe this is something useful I can also use.

I guess its also related to the fact that you dont need an include guard? Or have you missed that too?

// example
#ifndef MSGEQ7_H
#define MSGEQ7_H
// code
#endif // include guard

[franky47]

Hi Nico,

I thought I updated the #define block that selects the default port, I might not have pushed it yet, I'll have to check. Thanks for reminding me.

Namespaces are used to separate definitions that might have the same name within a program. They are very useful to clean up some code, and to keep things tidy. The introduction of the midi namespace for example was to leave some freedom for users to define things like Start or Stop in their code, without conflicting with the library (here, in the Real Time Clock messages).

Namespaces are not related to include guards. The reason you don't see a classic C-style #ifndef/define/endif include guard block in the code is that I prefer using #pragma once, which does exactly the same thing, with a single line, and does not use a preprocessor name that could be defined by another part of another program by mistake.

Hope this helps :)

[NicoHood]

Thx! This gave me some new ideas. I will use the #pragma once in the future.

Change the definition if you like. I'd add something like

#ifdef SERIAL_PORT_HARDWARE
#define MIDI_CREATE_DEFAULT_INSTANCE()                                      \
        MIDI_CREATE_INSTANCE(HardwareSerial, SERIAL_PORT_HARDWARE, MIDI);
#else
#error SERIAL_PORT_HARDWARE not definied. Do you use an old IDE version?
#endif

Edit: By the way: Is it really needed to use a HardwareSerial pointer? Cant it be Stream or even Print? This would make it more flexible and perhaps usable with the USB Midi later on. (have no chance to test either of it, just had a quick look at your sources. Nice coding style!)

[svgeesus]

This seems to relate to
USBCON is an AVR-only register #29

[svgeesus]

It is not clear that SERIAL_PORT_HARDWARE would do the right thing on Arduino DUE.

On DUE, I see these

#define SERIAL_PORT_MONITOR         Serial
#define SERIAL_PORT_USBVIRTUAL      SerialUSB
#define SERIAL_PORT_HARDWARE_OPEN   Serial1
#define SERIAL_PORT_HARDWARE_OPEN1  Serial2
#define SERIAL_PORT_HARDWARE_OPEN2  Serial3
#define SERIAL_PORT_HARDWARE        Serial
#define SERIAL_PORT_HARDWARE1       Serial1
#define SERIAL_PORT_HARDWARE2       Serial2
#define SERIAL_PORT_HARDWARE3       Serial3

On Leonardo, in variants/leonardo/pins_arduino.h I see

#define SERIAL_PORT_MONITOR        Serial
#define SERIAL_PORT_USBVIRTUAL     Serial
#define SERIAL_PORT_HARDWARE       Serial1
#define SERIAL_PORT_HARDWARE_OPEN  Serial1

(note that HARDWARE1 is not defined)

On Robot, in variants/robot_motor/pins_arduino.h there is

#define SERIAL_PORT_MONITOR        Serial
#define SERIAL_PORT_USBVIRTUAL     Serial
#define SERIAL_PORT_HARDWARE       Serial1

(which is annoying, as SERIAL_PORT_HARDWARE_OPEN is not defined).

Similarly for Robot, in variants/robot_control/pins_arduino.h there is

#define SERIAL_PORT_MONITOR        Serial
#define SERIAL_PORT_USBVIRTUAL     Serial
#define SERIAL_PORT_HARDWARE       Serial1

For Teensy 3.0 and 3.1, in teensy/cores/teensy3/pins_arduino.h is

#define SERIAL_PORT_MONITOR             Serial
#define SERIAL_PORT_USBVIRTUAL          Serial
#define SERIAL_PORT_HARDWARE            Serial1
#define SERIAL_PORT_HARDWARE1           Serial2
#define SERIAL_PORT_HARDWARE2           Serial3
#define SERIAL_PORT_HARDWARE_OPEN       Serial1
#define SERIAL_PORT_HARDWARE_OPEN1      Serial2
#define SERIAL_PORT_HARDWARE_OPEN2      Serial3

[NicoHood]

And where is the problem? The due has a different USBSerial, not named Serial. I guess he never used/tested it on a due. I dont have one neither.

For the missing robots definition you may open an issue on the Arduino Github page, this could really be missing or was attended, because something is connected to it. However almost nobody uses the robot and SERIAL_PORT_HARDWARE is defined anyways.

[franky47]

In any case, MIDI_CREATE_DEFAULT_INSTANCE was provided as a quick & simple way of keeping compatibility with old sketches.

If you want a specific port to be used, you should use the custom macro:

#define MIDI_CREATE_INSTANCE(Type, SerialPort, Name)                            \
    midi::MidiInterface<Type> Name((Type&)SerialPort)

As the library is template on the serial port type, any class with begin, available, read and writemethods will work (HardwareSerial & SoftwareSerial are immediate candidates).
For the USB part, that would be an intermediary interface between the library on one side, and the USB endpoints buffers on the other.

[sanotronics]

Hello!

Has anybody had any trouble on the reception of MIDI messages, when compiling and uploading the sketch with a Mac computer?

The only way to get through the compilation without errors like "MIDI not defined" when using the latest Arduino IDE is to add right after the includes the line

MIDI_CREATE_DEFATULT_INSTANCE()

but whenever I do this and upload the sketch, the MIDI IN doesn't work properly.

Specificly, i have a midi controller, which has buttons next to LEDs, and the button sends a NOTE message, and when the receiver replies with the same note, the corresponding LEDs turn on or off, according to the parameter state in the computer application.

If I compile on a Mac, the LEDs turn on but never turn off, thus I think NOTES OFF are not arriving. I tried Live Ableton, Isadora and PureData and it's all the same.

If, however, I compile on a PC with Windows 7, I am not required to add that line of code, so I comment it out and everything works perfectly!!

I have no clues if the library has some issues when compiling on a Mac computer, or if the problem is the Arduino IDE running on a Mac.

Any clues??

[sanotronics]

Now, I also realized that if the library on my PC is installed on

C:\Users\User\Documents\Arduino\libraries\MIDI

that line is not required. On the other hand, if I place the library on

C:\Program Files (x86)\Arduino\libraries\MIDI

I am required to uncomment that line, for the compiler to work.

I tried the same (installing the library either on the Package folder in Applications, or in Documents) on a Mac computer, but it needs that line uncommented in both cases.

The only true thing I know is that:

If I compile without that line, MIDI IN works perfectly. Otherwise, it doesn't.

[rveitch]

I appear to be having the exact same MIDI In issues when compiling on a Mac.

[rveitch]

Update: after checking my output with MidiOx, Midi In/Out/Through was sending, however none of the messages (only program changes) were actually taking effect on the pedals (Eventide H9, Strymon Timeline, Mobius and Bluesky) I had connected after the Arduino Uno R3, the PC's would just pass through to MidiOx without triggering any action on the pedals.

After I added a call back to send a control change (specifcally a bank change message of MIDI.sendControlChange(0, 0, 1);) along with any incoming program change it solved the problem. Is this a bug, or is there a reason this should be the case? I don't think it should cause me any issues to just continue to include this, but it strikes me a bit odd that it is needed.

Here is my small test/debugging code for reference, thanks in advance for verifying if this is a bug or not!

#include <MIDI.h>
MIDI_CREATE_DEFAULT_INSTANCE();

void handleProgramChange(byte channel, byte number)
{
  // Do this whenever a Program Change (0xC0) is received:
  // Control Function: Bank Select, USED AS: MSB
  MIDI.sendControlChange(0, 0, 1); // Needed for Program Changes to work?
}

void setup()
{
  MIDI.setHandleProgramChange(handleProgramChange);
  MIDI.begin(MIDI_CHANNEL_OMNI);
}

void loop()
{
  MIDI.read();
}

[franky47]

It looks to me like your devices could be confused by running status, can you try to set UseRunningStatus to false in your preferences ?

[MrHaroldA]

I found this thread because my Midi devices (Lexicon MX200, VOX Tonelab LE) also didn't respond to my Arduino midi switcher. Well, the first PC works, all following don't.

Adding sendControlChange(0, 0, 1) fixed this.

        midiInOutInstance.sendProgramChange(_activePatch, MIDI_CHANNEL);
        midiInOutInstance.sendControlChange(0, 0, 1);

It looks to me like your devices could be confused by running status, can you try to set UseRunningStatus to false in your preferences ?

That fixes it too ;)

[mink99]

The controlchange 0,0,1 is in fact half a bank change message which is cc0 MSB cc32 LSB . So this might fix the issue as it switches to bank 0 (or not), but this is highly dependent on the receiving device.

To send a full program change the sequence would be cc0 cc32 [program change]

[MrHaroldA]

I've set UseRunningStatus to false to fix all my issues. Well, all my Midi issues to be exact ;)