usbMIDI and MIDI 4.x?

Status
Not open for further replies.

oddson

Well-known member
Has Paul discussed a plan for usbMIDI to be updated to match the MIDI library on things like getType() and sysex handling (beyond the TODOs in the source code)?

It seems to me the current situation is making it difficult to use usbMIDI calls to handle things like software MIDI-thru/merge, MIDI over Bluetooth and anything where you need to move data between them or process all non-sysex in the same manner regardless of type.

While one can work around these I think it potentially detracts from Teensy's advantages for MIDI and even Audio projects if there's no simple solution to simple MIDI issues when dealing with both libraries.
 
Last edited:
@oddson

I have a pull request with Paul to address part of this .... The USBMIDI event numbering (i.e. the numbering for noteon PC CC etc) and the MIDI 4.x event numbering are different ...the thing is that a change to the USBMIDI code would break current applications that rely on the USBMIDI event numbering ...and I guess it is a low priority for Paul, given the K66 project he is undertaking ...
 
That's more or less what I thought... I wonder if something like a second library like bounce2 where the library takes a different name so the old stuff still works would be a good resolution.

It looked to me like there were pull requests for most of the needed changes...
 
I hope there can be a generic public send function added as well so it would be simple and obvious how to pass non-sysex MIDI messages from usbMIDI to MIDI...

In the meantime I'm hoping its possible to call the send_raw function to make a loop that doesn't need a bunch of case statements
(Is there more to it than adding the namespace string?)


@Adrian... I noticed the pull request to add stop/start bytes for sysEx includes an optional, Boolean parameter to request the alternate behaviour without breaking existing code... perhaps you could/should do the same with yours.

Something like highNibble = TRUE returns the channel 0 offset for the stats byte instead of the three-bit (0-7) value.

I know there are other priorities at the moment for PJRC but MIDI and audio projects seem to represent a lot of the interest in Teensy so I hope it can become higher priority once the current hardware project is shipping.:)
 
Hey I was looking for that thread...


edit- yeah maybe the internal function has been renamed since the GIThub page... it looks to do the same thing but all your bit fiddlin' confounded me.

I was looking at: usb_api.cpp where the send functions end up each calling the same send_raw for normal midi messages...

I'd assume if we could send them directly you we could write loops that didn't need to 'case' through to a bunch of calls that then just call the same code anyway...
 
Last edited:
@oddson.... I think you are looking at an old library in the sense that the teensy 3.x library you want is here.

_send_raw is effectively replaced, in fact, by the "packed" function .... the bit twiddling isn't too hard to understand .... the packed function takes a 32 bit unsigned int ... each block of eight bits is 'orr'ed together in the right order to give a 4 byte midi message all ready for the usb TX...
 
Thanks... was just coming here to post that I'd finally figured that out.

For my own purposes I can use the packed function ...but a generic public 'send' with byte parameters would be nice to see in any update. :)
 
Thanks... was just coming here to post that I'd finally figured that out.

For my own purposes I can use the packed function ...but a generic public 'send' with byte parameters would be nice to see in any update. :)

True enough a generic public send would be nice.

edit: perhaps I will do a pull request, day job, family and current teensy midi project willing . :D...
 
Last edited:
Status
Not open for further replies.
Back
Top