Dump state of mapped items

Midihub Feature Requests
1

Hello!

It would be very useful to be able to ask a Midihub to dump the current state of each item that has a MIDI mapping.

This could be used by controllers for synchronizing themselves with the internal state of the Midihub.

Ideally the MIDI message (or sequence) and channel that initiates the DUMP would be configurable to avoid conflicts with other devices.

The controller would send that message and the Midihub would respond by sending the value of each MIDI mapped item via the same CC message that is used for mapping.

Ideally the output port could also be configured.

2

So say if you have CC #13 on USB A input to Midihub mapped to some parameter, when triggering this function, you’d like Midihub to output CC #13 with its current value to USB A output from Midihub?

Would you like to have some global controls to say not output DIN-5 port mappings, as those might not be connected symmetrically to the same device, and might be misunderstood by some of the connected devices?

As I picture this, it’s probably most useful for USB MIDI mappings.

What ways of triggering this would you like to use, and would actually use in practice? Like trigger from Midihub editor, trigger via the button, trigger via some special MIDI message?

3

I actually would only use this with DIN-5 MIDI mappings at the moment. I have a setup where I have 2 Midihubs (big Midihub with more outputs, or generic ports that can be both input/output when? by the way) that both get the same input from a Kenton Merge – 4 which merges several MIDI devices, like a keyboard, transport/clock leader and a button controller and then splits them into two outputs.

The keyboard can go directly to one or more of my instrument via individual pipelines. The bypass of the pipelines is MIDI mapped so that the button controller can enable/disable them. This enables me to have route the the keyboard to any combination of instruments.

The Midihub remembers the last state of the bypassed pipelines after a power cycle. The button controller doesn’t remember the state of the buttons after a power cycle.

I would like to remedy this via syncing up the two with a “dump” message.

I think in general it would be useful to be able to redirect all mapping dumps to a specific output and perhaps with a change to the MIDI channel, but it would also be useful to use the same MIDI channel for all mapping dumps.

My current method to trigger this would be a dedicated button because my controller is dumb. The message would be delivered via a DIN-5 port and I would like the response on a specific port that doesn’t necessarily have the same letter as the one where the message came in.

In the future I would have something like the Electra One where I could script this message being sent out on startup or maybe periodically. The Electra One can act as a USB host which I will probably use to free up DIN-5 ports. In that case the message would be delivered via USB.

4

Ideally the dump “output” would just another virtual output that we could just process with pipelines and route wherever.

5

I have an alternative proposal that would still be valuable and might take less work to implement.

Add a way to send a specific message on a specific port when the Midihub powers on and is ready for accepting MIDI messages. (Similarly to how a message can be assigned to the button, but this would not require user interaction)

The idea is that I would use an Electra One as the controller.

The Electra One has support for Lua scripting. That would allow me to implement two things that are relevant here:

  1. The Electra One dumps it’s controller values that are relevant for the Midihub when it is powered on
  2. Additionally, trigger above functionality with a special MIDI message which would be coming from the Midihib

This would allow the Electra One to “reset” the mapped items to what the screen would show in case they are powered on at the same time, or the Midihub is powered on first.

This would also allow the Midihub to be reset in case it was powered on after the Electra One sent CC messages for the mapped items.

This could be further tweaked so that the Electra One waits a few seconds before it sends CC values on startup and if during that wait it receives the special message from the Midihub then responds immediately instead of at the end of the wait. This would avoid the CC messages being sent twice when the two devices are powered on at the same time.

This solution would keep the two devices consistent with each other as long as no changes are made with the MIDI cable unplugged.

1 Like
6

so would one of your Midihubs (let’s assume you have two) send a ‘handshake’ message saying

“MF-QF6... here, I’m on Preset6”
and the other
“MF-18P... here, I’m on Preset2”

whence the Electra One would reply maybe

to MF-QF6... : “Ch8.CC5=120, Ch3.CC15=67, …”
and MF-18P... something like Tune Request meaning “got nothing for you”

or would Electra One additionally send Preset Changes to hubs in the current project?

7

Let’s assume there are two Midihubs (I actually have two of them in use right now).

The message they would send would be more to say “hey, I am now powered on”. Something else might respond to it or it might be completely ignored. The Midihubs would stay ignorant about the true purpose of the startup message.

If you would have several Midihub presets used then the response could be a program change message followed by CC messages for the mappings.

In case you have several Midihubs, you would likely want to configure different startup messages so that whatever is responding knows what it should send.

When it comes to my Lua script on the Electra One, I don’t have to know what preset is selected on the Midihub, I just need to know that it is powered on and ready.

It is assumed that the desired patch on the Midihub is compatible with the patch on the Electra One.

Once it is established that a Midihub is powered on, I can ignore it’s internal state and just reset it to something known to me. The caviat is that I really have to reset everything.

This would be dependent on my current setup but when I detect the startup message, I would send a PC message to make sure the Midihub is on the right patch.

Most of the time this would not do anything I suppose, since I only have one patch used but for the sake of completeness it has to be considered.

Once I establish that I know which patch is selected on the Midihub (and here I would make the assumption that if I send a PC message for a specific patch then that is what will be selected) I can start getting the mapped items into a known state, which I would do by setting them to the same value that they currently have on the Electra One.

This method can be scaled for several Midihubs with the use of different startup messages, or by reusing the same startup message and using unique CC messages across the different Midihubs.

After this point the two devices should be consistent with each other and remain that way as long as the MIDI communication is alive and there are no additional devices that change mapped values on the Midihub without also telling the Electra One about the change.

8

I didn’t have the chance to try but I am thinking of tinkering with a one-shot LFO and some filters. That might be able to do what I need.

9

I have this a try and I couldn’t do it with the LFO. A single shot LFO needs to be manually triggered and there doesn’t seem to be a way to make it triggered from the start.

10

message me your patch with notes of a couple of the mappings you require & I’ll have a shot at it, then send you some details.

11

Thanks, but it is not the mapping that isn’t working.

I was trying to create pipeline that would send a single MIDI message every time the Midihub is powered on.

I was trying to achieve this with the LFO and that is what didn’t work.

I was going to listen for this message via an Electra One MIDI controller and would have responded with CC messages for the mapped items.

12

Ahhh, I see my misunderstanding & what you’re trying to.

Does it have to be a One-Shot?

If you have, say, a very long period PWM with a Transform using the 127 value to create your Electra “I’m on” Message

and one of the Electra Set-up maps being to disable that LFO,
then it’ll fire just once on each start-up won’t it?

1 Like
13

I didn’t consider that but it would totally work. It would have the added benefit of automatic retries until the Electra One responds.

I would use the USB port to connect the Midihubs to the E1 and I would not use those ports for anything sensitive, so it would be fine to send a message once a second.

1 Like
14

Nice one.

once a second.

I hadn’t thought of repeated polling so was going for a pulse with the option of adjusting phase so could control how long fter MH boot before pulse sent

15

I think this “reverse-polling” would work just fine. I just need to make sure that I handle it correctly in the Lua script on the E1.

Once I detect the messageI need to turn off the LFO ASAP, then send the rest of the CC messages.

I could also leave the LFO on and use it to implement my equivalent of active sensing.

On the E1, would listen to the LFO’s message.

I would keep track of whether or not I’ve sent the mapped CC messages.

Once I receive the LFO’s message, I would send the mapped CC messages and I would set a flag somewhere so that next time I get the message, I know I already sent everything.

If I hadn’t received the message for a while, say 2-3 seconds then I would clear the flag.

Now I just need to make sure I can get the value of some running timer on the E1 so that I can store when the MIDI messages come in.

This would make the system more resilient against unplugged MIDI cables and would support syncing the internal state in the following cases:

  1. E1 and Midihub are turned on in any order, the delay between the two turning on doesn’t matter
  2. E1 or Midihub is rebooted
  3. MIDI connection is broken and then re-established
16

I had a quick look at the E1’s timer and there is no way to expose some internal running counter, so the next best thing I can do is to implement my own and then use that counter to establish the relative delay between when the two MIDI messages arrived.

It will not be that precise but I don’t need it to be.

Whenever a MIDI message from the LFO is detected I would store the value of my counter.

In my timer I would then compare the running counter with the stored counter and if the difference is too great then I would assume the Midihub was disconnect and “re-arm” the CC-dump logic.

17

I created a pipeline that sends active sensing messages, which is essentially what I need.

Here is the link on patchstorage.

Active Sensing messages via an LFO

TL;DR

This preset implements a pipeline that generates active sensing messages via an LFO,

The standard frequency of active sensing messages is “once at least every 300 milliseconds” which works out to about 3.33Hz. The frequency of the pipeline can be adjusted via the frequency of the LFO which should be half of the desired frequency.

Implementation details

The pipeline starts with a random MIDI port. This can be anything because the messages are filtered out with the next, Filter pipe. The Filter pipe is followed by the LFO pipe which is used for the initial message generation.

The LFO is creating a PWM waveform with 50% duty cycle and 64 depth. This generates two messages, one with value 0 and another with value 127. These messages are generated within a single period. The consequence is that the frequency of the messages will be double of the frequency of the LFO. This is offset by setting the LFO frequency to half of the desired message frequency.

Active sensing message should be sent once at least every 300 milliseconds. 300 milliseconds work out to about 3.33Hz, halving that works out to about 1,67Hz.

The LFO generates CC messages, which are then replaced with active sensing messages via the Transform pipe.

The pipeline doesn’t use any incoming data but since there is no way to have a pipeline with no input port, I just picked a random one and filtered every message out.

If you need to forward the active sensing messages to multiple ports, instead of duplicating the pipeline you can send the messages first to a virtual MIDI port, and then route that port to the desired MIDI ports.

18

there is no way to have a pipeline with no input port, I just picked a random one and filtered every message out.

now that you’re not using a One Shot you can use a Generator LFO to start the line

Screen Shot 2023-09-09 at 11.44.18

19

Thanks for that! It makes the whole pipeline even cleaner!

Edit: I updated my patch over at patchstorage.

1 Like