Hey Guys, now that there are no longer any GM5 chips available in small quantities, I was just wondering if anybody has experienced how the LPC17 core performs in comparison in terms of latency (with built-in Windows drivers for example)? I’m talking about the MIDIBox in USB MIDI mode of course… I believe it is even possible to enable 5-in/5-out on the LPC17 core with simple configuration flags.
Any thoughts?
Cheers from Montreal!
The IIC stuff could be used here as well, no? So that could allow tons of MIDI I/O at first guess 
I thought about using the STM32 core for MIDI I/O but it was too early in the design phase for it and overbuilt perhaps. Having an LPC doing MIDI I/O, maybe even with a neat display and routing capabilities would be pretty awesome I think!
Yes, from a hardware perspective, expanding to very many UART peripherals is easy enough with added ICs from Maxim or NXP…
I guess my question is more aimed towards the latency/speed (especially using multiple virtual ports with windows over a aingle USB cable to a single MIDIBox application using the port internally).
The reason I’m asking is because according to this page, when using Window’s built-in midi driver with a multi-port interface (such as the GM5, or in my case, the MIDIBox), the bandwidth of each port is bottle-necked to 1 ms between events…
Maybe the Ploytec drivers can be used by the LPC17 core MIDIBox?
Of course, the MBHP_CORE_LPC17 module can be used as a pure MIDI interface, MIOS32 is already prepared for this and there are also example applications, like this one:
or this advanced one:
which supports OSC via ethernet as well.
3 UARTs are natively supported by MIOS32, the 4th UART could be added as well if really required.
Of course, you could add IIC_MIDI interfaces in addition, or a hacker could implement some software based UARTs (like Ploytec did for the GM5), because the LPC17 has more than enough processing power.
BUT: such an interface would only work properly under MacOS and Linux, since the USB MIDI drivers are well supported and working flawlessly (and without latency issues)
Under Windows there are several issues with different OS versions.
E.g. Win7 in 64bit mode: USB MIDI works only properly if the USB interface is configured for a single port.
Once the USB MIDI interface is configured for multiple ports, MIDI transfers can sporadically get stucked.
Thats the reason why the Ploytec driver is still superiour.
And no, it won’t work with the MBHP_CORE_LPC17 module as it’s bundled with the GM5 hardware.
My own interest to develop an alternative solution is zero, since I don’t work under Windows (and own some GM5 interfaces anyhow :))
But somebody with Windows USB driver skills should be able to develop a proper solution.
Best Regards, Thorsten.
Hi TK,
Thanks for your reply… you confirmed everything I suspected… If I’m going to use Windows 7 64bit and want multiple MIDI pipes to my MIDIBox, I need a GM5, which has sadly disappeared
Is it possible to simply map different channels of a single logical MIDI port to multiple MIDI ports on the hardware? So like channel 1-4 goes to MIDI 1; 5-8, MIDI2, etc.? Obviously can cause problems when you have a device that can use all 16 channels, and I’m guessing it could be easy to saturate the data rate when using one logical port. Still, could be a potential work-around?
Is it possible to simply map different channels of a single logical MIDI port to multiple MIDI ports on the hardware? So like channel 1-4 goes to MIDI 1; 5-8, MIDI2, etc.? Obviously can cause problems when you have a device that can use all 16 channels, and I’m guessing it could be easy to saturate the data rate when using one logical port. Still, could be a potential work-around?
Thats possible and there is no bandwidth issue with this solution as USB MIDI transfers the data much faster than a HW MIDI interface.
I just had a look into the LPC1769 datasheet: the 4th UART is available at J4B of the MBHP_CORE_STM32 module, which is intended as a second IIC port, but I think that using it for an additional UART makes more sense.
This reminds me that I should add this option to the MBSEQ V4 firmware as well.
The 3rd UART is available at J5B
And for your interest: if you need a PCB for the MIDI sockets + optocoupler circuits: I’ve still some spare GM5x5x5 boards which could be re-used for such a solution 
Best Regards, Thorsten.
I mean the single MIDI port Windows sees would be limited to the speed MIDI typically runs at (if using a single port in Windows and using CORE to logically segment that out)? In regards to using multiple LPCXPRESSO’s, you mean independently or somehow connected together? (The LPCXPRESSO is still very new to me ).
This is more idle food for thought for me - I was fortunate enough to be able to get in on some GM5 action Though I had thought of retrofitting my SID and FM synths (once they are finished) so I can rock USB for them. GM5 makes that just a nice to have though.
I mean the single MIDI port Windows sees would be limited to the speed MIDI typically runs at (if using a single port in Windows and using CORE to logically segment that out)?
MIOS32 automatically interleaves the MIDI events, and IN/OUT ports are FIFO buffered, so that there is no performance drawback.
Means: the MIDI ports could still be handled at full speed over a single USB cable.
In regards to using multiple LPCXPRESSO’s, you mean independently or somehow connected together? (The LPCXPRESSO is still very new to me
Just connect multiple LPCXPRESSOS to a cheap USB Hub with integrated PSU (so that no separate PSU is required for the LPCXPRESSO modules)
Best Regards, Thorsten.
Alternative solution: order at least 4 GM5 chips to make the 6th bulk order happen - it’s even cheaper than buying a LPCXPRESSO module!
-> http://www.midibox.org/dokuwiki/doku.php?id=tk_gm5_bulkorder
Best Regards, Thorsten.
Added 4 chips and some PCB’s for me
Pardon the ‘double post’ but this thread really addresses something I’ve been pondering for a while now:
I want a *hardware* midi router that has an arbitrary number of IO ports. 16 will be enough for my setup at the moment, but in the future I could easily expand to more.
By routing I meant the basic stuff like routing all midi events from port 1 to port 2 along with much more sophisticated patches like:
port 1 channel 1 => port 2 channel 3
or
Note on/off and velocity from port 1 channel => port 2 channel 1 and port 3 channel 2
or
Mod wheel from port 1 channel 1 => CC#12 on port 2 channel [1, 2] && CC#14 on port 3 channel 4 (scaled to values 32-64)
Now I would also want this to act as a ‘standard’ midi interface (perhaps with the patching abstraction applied here too) but I *don’t* want any routing or patching to be done on the computer side! The latency or rather the inconsistency of latency introduced when signals hit the silicon metropolis of a modern desktop computer is unacceptable to me I certainly don’t want midi events to need to be piped across a variety of busses, protocols and driver code before they are parsed and routed. Even working with Ableton and 2 Gm5x5x5’s I sometimes find myself needing to accommodate 20+ milliseconds of lag 
Now, writing the code and drivers isn’t a problem for me.. but at the moment I’m a bit lost regarding how to accomplish an ‘arbitrary’ number of midi IO’s in hardware.. I see that the Gm5 supports 5… but why not more? Do we need to have an IIC chip for each or is there something simpler? .. how much of a noob do I sound like now? :rolleyes:
Yes’ date=’ from a hardware perspective, expanding to very many UART peripherals is easy enough with added ICs from Maxim or NXP…[/quote’]
Can you elaborate?
Count me in for some chips and PCBs too. I don’t need it atm but now I can make a 15io interface and utilize some cores with usb MIDI mmmm.
So mostly to help this happen, but also for future expanding of my units. Them ic are always useful to have laying around hehe.
Just need to get into wiki login first… Can’t do on my phone for some reason…
Can you elaborate?
Hey moogah, there are chips such as the MAX3107 and MAX3100 (or NXP has some dual channel ones which are more economical but slightly more elaborate to program). These allow you to “bit bang” serial UART communication (in this case each MAX310* ==> 1 x bidirectional MIDI In/Out). Part of what makes this possible is the built-in FIFOs on these UART chips. It means you don’t need to use up dedicated UART peripherals in the MIDIBox hardware… of course you would have to write some custom code to drive these chips, but once that’s done, it would be really easy to add many ports (probably even more than 16!) since MIDI is relatively slow compared to the LPC17 MIDIBox.
As TK also mentioned, this could also be done purely in software of the LPC17 MIDIBox (without even using those UART chips) by cleverly writing an app for MIDIBox (again because LPC17 MIDIBox is fast and MIDI is slow), but the success of such a method will probably depend much more on clever programming (streaming approach, sampling-strategy for the the incoming serial) and might not be feasible (read: fast enough) if you’re “super-router” has to do something more than a very basic routing of MIDI events.
The UART chips can ease the processing burden to allow your app to spend more CPU calculating your MIDI routes instead of merely handling the raw serial communication.
Either way, you’d need to write some code that I believe currently doesn’t exist for MIDIBox.
Hope this helps…
Hey moogah, there are chips such as the MAX3107 and MAX3100 (or NXP has some dual channel ones which are more economical but slightly more elaborate to program). These allow you to “bit bang” serial UART communication (in this case each MAX310* ==> 1 x bidirectional MIDI In/Out). Part of what makes this possible is the built-in FIFOs on these UART chips. It means you don’t need to use up dedicated UART peripherals in the MIDIBox hardware… of course you would have to write some custom code to drive these chips, but once that’s done, it would be really easy to add many ports (probably even more than 16!) since MIDI is relatively slow compared to the LPC17 MIDIBox.
As TK also mentioned, this could also be done purely in software of the LPC17 MIDIBox (without even using those UART chips) by cleverly writing an app for MIDIBox (again because LPC17 MIDIBox is fast and MIDI is slow), but the success of such a method will probably depend much more on clever programming (streaming approach, sampling-strategy for the the incoming serial) and might not be feasible (read: fast enough) if you’re “super-router” has to do something more than a very basic routing of MIDI events.
The UART chips can ease the processing burden to allow your app to spend more CPU calculating your MIDI routes instead of merely handling the raw serial communication.
Either way, you’d need to write some code that I believe currently doesn’t exist for MIDIBox.
Hope this helps…
Oh yea, that helps a lot! Bit-bang? LOL I need to get my mind out of the gutter :whistle: