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.

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 https://community.blokas.io/t/extra-transform-options-nrpn-sysex/ 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 (http://www.faderfox.de/images/UC4%20side%20view.jpg) 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.

Cheers

1 Like