Sysex on on the usb/packet side is actually pretty braindead since everything is still encapsulated into 4 byte blocks. I will take a crack at cleaning up and fleshing out some of the convenience functions tomorrow.
libmaple - MIDI USB
(33 posts) (3 voices)-
Question is should we make it compatible with pteichman's maple midi (lgpl) or scratch write to something more mit/bsd compatible.
https://github.com/pteichman/MapleMidi
If we went with that would we make two separate classes (USBMidi, and SerialMidi) or mung them into a single class with separate instances.
Going to try to do a merge of your usb_midi class with the pteichman. Also since I am using the libmaple I need to clean up the code into a few files so you can try to merge it into something that will work with the ide.
Posted 2 years ago # -
mlundinse
MemberI have lots of pay'd work keeping me busy at the moment *grins*
Its perfectly possible to try out a few versions of MIDI classes on top
the basic USB transport layer. So my focus has been to make that stable.It might be simple to adapt the Arduino MIDI stuff, wether you like it or
not there is some interest in such compatibility.Making this work with libmaple should be as easy as a single buildflag
-DUSEMIDIUSB, this should hardly affect any other parts of libmaple.Getting it into the IDE is a whole different problem and depends on any plans from leaflabs to overhaul the IDE.
/Magnus
Posted 2 years ago # -
"Getting it into the IDE is a whole different problem and depends on any plans from leaflabs to overhaul the IDE."
Yeah as has been the usual for the last 6 months which finally they have admitted is not on their table while they try to pay the bills.
I suspect we will have to move that forward ourselves as well.
Which is why I was kind of bummed when I couldn't get your fork to build on osx.
I could not get the usb to work without disabling the usbserial in the startup code.
Posted 2 years ago # -
I agree about the pick your what you want to put on top of the transport. As far as the Arduino Midi stuff; I am starting with the pteichman port which is based on the lgpl code. The current midi library is gpl3. Gpl3 is not only offensive to me personally (and thanks to the earlier licensing, I don't have to like it or use it) It is also incompatible with libmaple's licensing in general.
Posted 2 years ago # -
So I tried to merge our git code together after taking your code and making it 32 bit but the resulting cluster f**k is a pretty good example of why what is good for kernel developers is really f**king the general community. Basically it took a working code base and trashed it.
Are you working any more with this or should I build on what I had before trying my lame git foo?
Posted 2 years ago # -
mlundinse
MemberI havnt touched this code in a couple of months, I did implement your midipacket (32bit) changes in my code, removing all the serial char stuff, but not the SysEx stuff yet.
This code works well for my needs, sending MIDI packages from my OpenPipe to my PC synth.
The build setup is still using a mess of local hacks to the IDE together with some libmaple mods, cleaning this up for public use is low on my priorities list. If the winter evenings becomes long, cold and boring I might have a go at it.
Posted 2 years ago # -
gbulmer
Moderatorfeurig/mlundinse - I don't understand USB-midi, so would you please answer a few questions?
1. What is a good source for information on how USB-midi differs from old-serial-midi, so that I could "get up to speed"?
2. Is there enough flexibility in the USB-midi protocol that it would be practical to bootload an underlying STM32F over USB-midi?
3. If the answer to 3 is "YES", roughly how big might a USB-midi-capable-bootloader be, i.e. would it likely be comparable in size to e.g. LeafLabs Maple bootloader?
Posted 2 years ago #
Reply »
You must log in to post.