MIDI_CREATE_DEFAULT_INSTANCE

Question

MIDI_CREATE_DEFAULT_INSTANCE

NicoHood opened this issue 10 years ago · 19 comments

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.

Answer 1 · 2015-04-20T12:51:13.000Z

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

Answer 2 · 2015-04-20T14:01:12.000Z

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 :)

Answer 3 · 2015-04-20T20:31:23.000Z

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!)

Answer 4 · 2015-04-21T14:34:16.000Z

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

Answer 5 · 2015-04-21T14:39:59.000Z

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

Answer 6 · 2015-04-21T15:27:11.000Z

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.

Answer 7 · 2015-04-24T06:12:43.000Z

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.

Answer 8 · 2015-06-12T19:32:31.000Z

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??

Answer 9 · 2015-06-21T19:22:01.000Z

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.

Answer 10 · 2015-09-26T05:08:00.000Z

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

Answer 11 · 2015-09-27T21:52:06.000Z

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();
}

Answer 12 · 2015-09-28T09:25:46.000Z

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

Answer 13 · 2016-08-05T23:44:13.000Z

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 ;)

Answer 14 · 2016-08-08T19:44:18.000Z

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]

Answer 15 · 2016-08-09T07:30:38.000Z

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

Answer 16 · 2016-08-12T12:07:13.000Z

I am busy writing a sketch for a midi controller using both this and the MIDIUSB library, including functions for forwarding midi between usb and 5pin din. Everything is working pretty smoothly so far but I was wondering how hard it would be to update the midi library to use the MIDIUSB library and transmit/receive/thru on both?

Answer 17 · 2016-10-06T07:19:40.000Z

I'm considering changing UseRunningStatus default value to false for 4.3, as some devices can't handle it, and I'll leave it up to the user to enable it at their own risk.

Even the very recent Web MIDI API does not implement Running Status it due to incompatibilities.

Answer 18 · 2016-10-06T07:23:51.000Z

@CaptainCredible, see #52.

Answer 19 · 2016-10-06T07:36:12.000Z

Good idea, I always disable it on everything I make.

On 6 Oct 2016 09:19, "Francois Best" notifications@github.com wrote:

I'm considering changing UseRunningStatus default value to false for 4.3,
as some devices can't handle it, and I'll leave it up to the user to enable
it at their own risk.

Even the very recent Web MIDI API
https://webaudio.github.io/web-midi-api/#methods-2 does not implement
Running Status it due to incompatibilities.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#33 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMQ0Fbn38QygQLvlGgiX3kngmg1ez2pGks5qxKEPgaJpZM4EEQSo
.