Can you read on serial and send on usb?

[fapplin]

OK. With the changes I'm reading about - here's what I'm trying to do? I'm using a Raspberry Pi Pico and Earle Philhower's Arduino core.

I need to read from a 5 DIN Serial (with RX and TX pins defined) and if possible use callbacks. In the callbacks, I will be changing notes based on certain criteria and then sending the new/changed notes out via USB connected to a computer (hopefully within the callbacks using sendNoteOn and sendNoteOff).

Is this possible using only this library?

Currently, I am reading midi data via the serial port (pins 16, 17 on the pico) and parsing the midi data myself. I'm using your USB capability via

// USB MIDI object
Adafruit_USBD_MIDI usb_midi;

// Create a new instance of the Arduino MIDI Library,
// and attach usb_midi as the transport.
MIDI_CREATE_INSTANCE(Adafruit_USBD_MIDI, usb_midi, MIDI);

and using MIDI to do the sendNoteOn and sendNoteOff. I need all other midi messages to pass to just pass through (which I was hoping to use your new filter capability).

So, basically I'm asking can your library do all of this or do I need to just travel the path I've been traveling?

Sorry for all the questions and confusion.

Frank

[franky47]

Yes, if you create two instances of the library, one bound to USB and one to DIN / HardwareSerial, you can register a callback on the DIN instance and call send methods on the USB instance, they are independent.

As a matter of fact, this is what the DualMerger example does.

[fapplin]

OK. A Pico has 2 serial ports. I have one (the default) in use accepting commands from a touch screen device. So, I have to use the other serial port for the midi, which I do on the RX/TX on pins 16 and 17. Does your serial transport allow me to define the pins of where its receiving and transmitting?

And, truly, thank you for all of your help.

[franky47]

Not the pins directly, but you should have a HardwareSerial instance associated with those pins, and then it's just a matter of telling the library which one to use (the DualMerger example also shows how to do this with the MIDI_CREATE_INSTANCE macro).

[fapplin]

OK. I have the sendNoteOn() and sendNoteOff() passing between the serial and the USB!! Soooo, much easier. But, now, come the filter part.

This was your proposed filter from a discussion in August.

bool everythingButNotes(const midi::Message& message)
{
  return message.type != midi::NoteOn && message.type != midi::NoteOff;
}

// The usual callbacks to handle Note messages:
void onNoteOn(byte pitch, byte velocity, byte channel)
{
}

void onNoteOff(byte pitch, byte velocity, byte channel)
{
}

void setup()
{
  MIDI.setThruFilter(everythingButNotes);
  MIDI.setHandleNoteOn(onNoteOn);
  MIDI.setHandleNoteOff(onNoteOff);
  // ...
}

That doesn't work. Has this filter part been implemented?

[fapplin]

OK. It compiled. So, should this handle all other messages like pitch bend? Or, do I still code for that? I commented my pitch bend callback out to see if this handled it, but it doesn't seem to.

[franky47]

This should forward all incoming message types but NoteOn and NoteOff to the associated output (if it supports Thru, this would only work on serial transports).

[fapplin]

OK. The incoming midi is serial, but outgoing is USB. So, I guess the filter doesn't buy me much. Getting the callbacks and just doing a simple midiSerial.read() in the loop() without the need to parse anything is great, though. Saved a hundred or so lines of code!

[franky47]

Ah, indeed this filter/map thing only works for Thru on the same interface, but there's a way to Thru on another interface, by hacking the filter callback and sending from there:

bool everythingButNotes(const midi::Message<128>& message)
{
  const bool forward = message.type != midi::NoteOn && message.type != midi::NoteOff;
  if (forward)
  {
    usbMidi.send(message);
  }
  // Thru back to the Serial output
  return forward;
}

[fapplin]

That seemed to do it. I commented out the following:

//  midiSerial.setHandlePitchBend(handlePitchBend);
//  midiSerial.setHandleAfterTouchPoly(handleAfterTouchPoly);
//  midiSerial.setHandleAfterTouchChannel(handleAfterTouchChannel);
//  midiSerial.setHandleControlChange(handleControlChange);
//  midiSerial.setHandleProgramChange(handleProgramChange);
//  midiSerial.setHandleSystemExclusive(handleSystemExclusive);
//  midiSerial.setHandleSystemReset(handleSystemReset);

And, I know at least the pitch bend and mod wheel are working with just the filter! Cool! Thanks.