I have an Arturia Matrixbrute, lovely machine with an annoying fault: Program Change events take a couple seconds to process, and sometimes it’ll hang if it receives a second PC while not having completed the first. Then the only way out is to power-cycle the keyboard.
Informally, I’m after a “don’t interrupt the keyboard, it’s busy” operation. It has to recognize a trigger condition, optionally do something, then wait for a while, and then “do something else”.
For example: Recognize incoming PC, send it on to the keyboard and then block output towards keyboard; wait for 3 secs; then finally open output again.
The “do something” operations could be to generate input into pipeline mapping; e.g. when I want the output blocked, I could send some note that would trigger bypass of my output pipeline. Unblocking, the same.
So I’m proposing a “delayed event” component:
Selectable input trigger. For me PC is enough, but it could be generalized to CCs (single, range, specific with values in certain ranges) or notes (single, range, note-on/note-off, velocity range)
Configurable delay. For me, a number of (milli-)seconds would be fine, but could also be number of midi clocks?
“On trigger” event: Append note or CC after input event is passed on. Subject to map processing
“On expiry” event: As above, after the delay has expired
Buffering is complex, so I didn’t want to include that as a “requirement”. For example, if it was being used musically, Midihub would have to store the timing of the incoming events, increasing the amount of bufferspace required. I don’t know if MH even has that kind of capacity; some seconds of MIDI events can take up a good deal of storage space.
My needs are simpler, in the sense that I’m happy to just have MH discard events until the timeout expires, and I can accomplish this via the existing mapping feature of MH.
“On trigger”: When a particular thing happens, in my case the Program Change.
“On expiry”: Expiry of the timer, i.e. when the programmed delay time has passed.
If we assume that this feature I propose can be configured to generate a specific note on a specific channel, then I would do something like this (I’m not at my setup right now, so going by memory):
Configure my new “delayed action” component, have it generate e.g. NOTE ON for note 127 on channel 16 when triggered, similarly for when the delay times out. This way MH “pretends” to be an external controller, controlling itself
Insert filter element before my output port towards my synth
Filter everything out
Enable the Bypass
Add Mapping for channel 16, note 127 that I configured in my “delayed action” element
That way, when my incoming PC arrives, MH will generate a note event for itself and use it to deactivate the Bypass on the Filter element, thereby enabling all the filters and therefore discard all output to the physical MIDI port towards my synth.
Then, when the delay expires, MH will generate a second note event for itself, thereby activating Bypass which will allow MIDI towards my synth again.
Not having tried it out yet, that sounds like a good proposal ; I didn’t think about the LFO part. Only caveat is that I’m out of OUT ports…
Maybe a sufficient feature request would be to allow virtual inputs to be mapping sources, i.e. MH could learn Mapping from those as well as from USB/physical inputs?
I’m not 100 percent clear on what you are trying to do but by first glance it looks like the note length pipe set to note off will do sorta what you are looking for. You just need to transform your data in midi notes and then back if you are using other than notes. The length argument then becomes the delay time before your note triggers. I use this often to trigger mapped parameters AFTER I release a note.
To reiterate, the note length pipe with the trigger argument set to “note off” won’t send the “note on” until the note off is received. The length argument will add a delay before that note on is triggered.
If you want to use this with CC’s, use a transform pipe to transform CC into notes, go through note length pipe, followed by transforming back to its CC. As a loopback, you can map that output to be your delayed trigger.
Edit. Looking at this closer, you probably don’t even need the length pipe style delay. You could probably just use the delay pipe in place length pipe. I would try it both ways. The length pipe would only be needed if you wanted to trigger(immediate or delayed) exactly from the RELEASE of a the trigger.
Delay pipe alternative
Transform pipe your trigger into Note 127 ch16 velocity 127.
Using the delay pipe, set the dry wet to 50, feed back to 50, repetitions to 1.
Follow up with transform pipe. You are trying to catch just the delayed note at whatever specific velocity the delay pipe puts out(adjusted by the feedback argument)
Set it to note on off-note on off (changing note 127 to new trigger note), set “work with velocity range” high and low to the value of delayed note.
Output.
This should give you 2 trigger notes, one delayed by the “delay time” argument. Of course you could scale this up and have 20 notes if you wanted. I was working on something like this a while ago to create a virtual drummer of sorts
Hi Joey, thanks for the suggestion and details; after some fiddling I got it working using a USB-to-USB loopback. Now the first PC towards my MatrixBrute will make MidiHub discard everything for the next three seconds, and then open up again. Good times!
; I didn’t think about the LFO part. Only caveat is that I’m out of OUT ports…