Very simple sysex pipe

Hi all, i’m new to the community and kind of a new user of the midihub. (i’m an early buyer, but had to wait for a very long project to be prepared)

So i just started to try implementing my required messages to my midi chain. And… i was stunned to discover that there is no sysex pipe. Even after 2 years creating a midi related peace of gear.

I’m pretty sure most of the people waiting for sysex related features would be happy to see a simple pipe offering a simple string field letting them write any sysex messages to be sent. No fancy stuff. Just a string field, sending some hexadecimal values in chain.

I bought this midihub to replace my Midi Solutions Event Processor, made more than a decade ago, that can do those very basic things, but with a pain in the a… software and very limited memory (32 messages max).

Don’t get me wrong, the Midihub is cool, but without this very basic functionality, for me it’s like having an expensive brick in my studio.

1 Like

We know there are feature requests for SysEx support, but there’s a long list of other improvements too that would be useful to the majority of Midihub users, so first we’re prioritizing higher impact features, before we get down to more specific areas.

1 Like

I understand your point of view regarding improvement. Even if,to be honest, i consider sending basic sysex messages not an improvement, but a basic feature of the MIDI language that should be in the core of your device. Most of the hardware synth out there simply won’t be able to communicate without them (outside note off/on cc… i mean).

The problem is that the simple “send some hex string over” doesn’t allow you to do much anything. You’d want to be able to modulate etc, and then you run into checksums. See for discussion on the topic.

you can agree that It would allow more than today :wink: postponing a feature, because you want it to do more before you even launched it, is a trap. (i know, i’m a senior dev, and i fell in this trap many times).
And ofc every new feature is ment to be improved, and after that you can detect sysex, modulate, add variables, trigger on conditions, etc… but “better” is the ennemy of “good”.

For example, right now, i can’t use the midihub when i need to send a basic sysex to a virus when a specifc note is on on a channel. Even that would be a good start, and it can solve many issues, with an hour of development. At least it would exists. It would be good enough. Even if everyone wants better and more.

But hey, blokas devs are the master of their path. If they consider it’s not relevant, so be it. But it should be at least written as a warning somewhere. On my side, as i won’t have an estimation on any delivery date, i’ll pass my way, and build one of my own with a Teensy. It’s a pity, i didn’t want to go the hard way, but it seems i don’t have a choice now.

Massively agree. Even the ability to send a static string of SysEx is better than the current situation where no SysEx messages can be sent at all.

I don’t understand why there would be resistance to this, it would be up to the end user to correctly add the SysEx in this pipe and then further down the line there can be more complex SysEx pipes that offer modulation options or even pipes for specific instruments.

1 Like

This is just not true and it’s a misleading statement. :slight_smile: It takes much more effort to bring a feature to a high quality and ship-to-public ready state. A lacking feature supported by matchsticks won’t do any good for majority of users, and even worse, can turn them down.

Building some simple logic according to your needs using an Arduino can be definitely a quick and flexible solution to the issue at hand.

Let’s turn this discussion around, and please elaborate what’s your use case for static sysex data to be sent on notes? What length sysex messages would you like to be sent?

I’m assuming you passed the first great wall of your ecosystem : Your hardware is made, your software has most of the required bricks elements done and It can send midi messages following orders going through your pipes algorithms. Let me offer you an advice regarding your internal organization. It perhaps might be improved if it became more organic. Considering at least 2 types of end users : put a beta program in place, allow your community to become testers. Most of us would be fine with an early not gold painted beta version to be used at our own risk. This would allow you to take a bigger time to finetune the perfect public version, limiting frustration on your fan base. Just saying.

Regarding my personal needs i have plenty. But I can give you a summary of some use cases, but the basic thing would be to be able to send a sysex string when a note on or note off occured :

Using one of the green buttons of an UC4 Controller ( I could trigger a dedicated note on event to send a sysex message to a Virus Synth for it to load the second multiselect program :

F0 00 20 33 01 10 73 00 69 00 F7

Note, that i would require to filter that note, because i don’t want it to be played by the synth.

Another idea involving the clock :

for some reason, the Virus doesn’t stop its arpegiator running on a channel when the midi clock is stopped.
So, we could listen to the clock stop event, and send a sysex to the virus for it to stop the arpegiator of the midi channel 5.

F0 00 20 33 01 00 6E 04 7B 01 F7
F0 00 20 33 01 00 71 04 0F 00 F7
F0 00 20 33 01 00 71 04 0F 01 F7

These are in fact 3 chained messages for the arpegiator stop to really work

In later steps, we could imagine :

  • 1/ being able to detect a CC within a range to send a static sysex string.
  • 2/ detect a sysex to send another sysex
  • 3/ even more powerful, being able to keep a value you detected in a pipe in a variable (like VAR1). And being able to pass this variable later on (in a sysex string for example) using (placeholders like $VAR1 or {VAR1} for example.

F0 00 00 3F 22 01 77 00 10 33 41 5A 00 {VAR1} 54 32 01 22 5F F7

I encourage you to check the functions offered by the MidiSolutions Event processor here : Event Processor Guide

This guide is well written, and gives you an idea of the state of mind of their creators when building this little box.



I am following this Forum to evaluate the possibilities of this very exciting MIDI processor.

For me it is also very important to manipulate SysEx Strings with MIDI-Control Values.

I think it is a very amazing feature to activate parameters of old synth without expensive hardware controllers.

I agree with Griedrius, that this kind of features needs a bit more attention to implement then others which are easier and cleaner to integrate.

But it would make this Box to one of the most powerful projects in this field combining many possibilities with such a nice GUI on so many platforms.


Unfortunately, it doesn’t seem to move in the right direction. I personnaly decided to build one on my own using a diy kit.

this one offers 5 in & out, was not that hard to soldered. it uses a teensy (a kind of arduino clone) that can be programmed very easily, as the midi protocol is already implemented in the framework. Detecting input messages and redirect or transcribe messages to outputs is very easy to do.

I run the Midihub attached to a Raspberry Pi. The RPi serves as USB-Host for keyboards and controllers. It provides some barebone routing between interfaces and all the very special processing of midi data, like CC to NRPN conversion. I think CC or Note to Sysex is the same category. Programmed in Python, a piece of cake. If you are willing to go the Teensy/Arduino route, RPi might be an option as well, with some additional features, like OSC-bridge, Bluetooth, Wifi.
Why then a Midihub? The graphical programming is so easy and fast, and the ability to activate/disable pipes on the fly via any MIDI controls is unique and much less disrupting for the creative flow.It is really great to sketch ideas, without interrupting the ‘playing’.

Just my 2 cents.



Yep, Rpi makes for a nice Midihub companion as you can run the MH editor there as well.