Thanks for the follow-up. Yes I can plug the USB cable from the Continuumini into a laptop (MIDI host)… send MIDI data to/ from Continuumini. In other words - the Continuumini shows up as a MIDI device within the VST setup screen.
But the FH2 (MIDI host) doesn’t even see the Continuumini as a USB MIDI device. Os from Expert Sleepers acknowledged this as being the fundamental problem.
However, I have had luck using a Raspberry Pi as a roll your own MIDI host… and then plugged in a USB-to-MIDI DIN adapter.
Was only asking here if anyone knew whether the new Blokas MIDI board could see the Continuumini. It might let me get rid of the separate USB MIDI adapter (I’ve had trouble with these before…in my experience adapters sometimes seem to go to sleep or get dropped if sitting idle too long.
The Blokas board just looked like a cleaner solution for getting to TRS MIDI faster.
It’s enough for Raspberry Pi to recognize the device - if it is recognized, you can use a simple ALSA sequencer connection, courtesy of amidiminder (soon to be named just midiminder), to get it forwarded between the Pimidi’s TRS MIDI and Continuumini.
I find myself needing more outputs than inputs. It’s probably too late now but it would have been really nice to be able to reconfigure the ports as input or output.
I have two Midihubs in my setup, and I cannot wait the day when you release something with more ports, or a Midihub that is stackable the way these PI hats are, so that they become “one”.
Hi! I’m new here and have a question about setting up a merger/router with these. I need (currently) a 3-iinput, 4-output DIN MIDI (TRS is fine) box to connect some old keyboards to some MIDI-2-CV converters in my Eurorack modular setup. Should handle basic MIDI messages but don’t need stuff like SysEx. Would I be able to build a stand-alone (after development) box with 2 Pimidi boards and a Raspberry Pi and some generic HAT for configuration buttons and status LEDs? I haven’t done any embedded work for several years now but it looks like it shouldn’t be too hard to get into this - especially with the MIDI library. I do know Python. Anyone know if this supports merging?
Can I do the development on a current MacBook Pro? Would I need to run Linux in a VM?
Oops - I just read more about the MIDIHub. I guess this might do what I need but couldn’t be customized or expanded past 4x4. I’d have to configure all my presets from a computer but then be able to switch between them with it stand-alone. Correct?
Yes, Midihub will do what you describe very well.
It has 4 USB inputs & outputs in addition to the MIDI DIN.
Yes, it has 8 presets which can be triggered by external Program Changes.
You will find, however, that a single preset can do many things via internal routing – especially as these can be conditional (parallel pipelines handling different messages, for example).
Try the editor – it can be downloaded and presets written (but not tested!) without access to a Midihub.
Which route to take is a personal thing.
Some users run their Midihub(s) from an rPi acting as a USB router with additional MIDI functionality.
You could opt for more Midihubs in your studio, but of course you would still have to ‘manage’ them individually, to upload the presets, etc…, but you can connect multiple Midihubs to a single host.
As to answer your original questions on Pimidi:
You can develop on your main computer, the actual scripts run on Raspberry Pi host, which can be edited remotely from your MacBook Pro.
Yes, this could be built with 2 Pimidis and a custom board for controls, you would just have to get your Python script to take the input(s) and write them to the necessary output(s), and interact with your controls. (or it could be done using any other language as well, Pimidis are seen as a standard MIDI device by the Linux OS on the Raspberry Pi, but Python ought to be a good choice for a project like this.)
Thanks for the info! I have a general firmware question since I haven’t worked with Raspberry Pis. How do you deal with multiple threads? Let’s say I have 4 MIDI inputs that each may or may not have active data coming in that needs to be routed to selected outputs (forget merging and filtering for now). Do I have to manually poll each input and process one at a time? If more than one is active, how does the firmware handle this? Do I need to manually input and buffer each one? Each byte should take about 300us so I could deal with 4 inputs in about 1.2ms but then have to write the data out. Does the OS or the programming language/library help with this or is it all done manually. I’m mostly an ASIC designer used to SystemVerilog where everything is truly in parallel so I’m trying to wrap my head around doing this in software/firmware.
Thanks!
I’ve looked into HDL languages and indeed the model of thinking is entirely different when things happen in parallel rather than sequentially.
Yes, the OS helps a great deal with this, thanks to buffering of events on the MIDI ports, no need to get the timings very tight. This also means that the processing logic can be a simple loop of polling for pending MIDI events, processing them one at a time, and writing to the output MIDI port’s queue, all done in a simple single thread.
The majority of use cases are handled by assigning a callback function that gets called automatically whenever there’s pending input. The polling loop is handled in the pimidipy.run() call.
You can keep some state in global variables, or make a callable class object, to be able to have some memory of past events.
Things get more complicated when you want to produce your own outputs at particular times, without respective input event, but it sounds like you currently don’t need this functionality.
