I’m wondering if it would be possible to implement a “double press” pipe.
The pipe would look for two consecutive messages of the same time that were received within a set amount of time.
The first message would arm the pipe, a second message arriving within the specific timespan would trigger a new message.
If no message arrives within the specified timespan then the pipe disarms itself.
There could also be an option to replace the second message with the new message.
The trigger message, timespan and new message would all be parameters.
A specific use case: Elektron boxes have functions that are triggered by double-pressing the stop button. Each press sends a MIDI stop message as well.
With this pipe, I could have my Midihub send a CC message once I double press the stop button on my Digitone.
The first and second message are specific and are the same.
We don’t have buttons of course, we hsve MIDI but the idea was that if I double press a button on a controller that sends the same MIDI message for each press then I could trigger something that otherwise wouldn’t be triggered with just a single press.
So , it’s like “Ch1 CC95 value127” each time?
If so, then I think it’s do-able with loopback-hack.
If you’re interested in going that route (& have the spare in-out), I’ll dig out the August patch. When I look at it again in this light, I’ll know how adaptable to your scenario it is!
In my case the message would always be MIDI transport stop, but in the future it could be a CC message with a fixed value.
I don’t have spare outputs however and I have no way to free any up.
Would be nice if there would be a Midihub with more than 4 outputs, or a way to connect them together in some sort of parallel way to avoid stacking the daisy gaining latency.
new pipe
Yeah, my apologies; I focussed intially on offering an possible immediate solution to your situation!
I agree that a general Delayed Action pipe could be a useful addition to the pipe ‘suite’. Can’t recall having seen anything in that area being requested before, so dunno if it’s on Blokas’ agenda.
need a loopback?
Think you do: You need to store a state: “1st tap received”, then do something conditional with that state. To my mind, this implies a ‘internally modified’ mapping.
thus needs a Midihub talking to itself (or one to a second!).
By “physical”, I was also including USB which is why I mentioned rPi as MIDI patchbay – allowing a USB-USB loopback. If practicable in your situation, this would give 8 more ports, including between the two hubs…
AFAI can see, virtual loopbacks are not allowed by the Editor (try it!). Probably precisely to avoid the infinite looping that can easily occur with ‘careless’ ‘physical’ ones . ( accidental BPMs of 2500.1 are generally not a good sign!)
I think I see what you are trying to achieve with mapping and loopback.
I haven’t thought a lot about it but an initial concern of mine is that I want the internal state to reset after some time, like 300 milliseconds because both a single message or two messages in succession would have a different meaning.
If I use a message to bypass/enable a pipeline then I would also have to have some sort of delay that bypasses the pipeline eventually.
Yeah, that’s what I was taking as the basis for the task. My mental sketch was a loopback which used an 300ms offset-sawDown LFO. Last few (near-0) values would Transform to the DO IT command. In addition the Trigger Event would also set up some form of toggle-analogy , so that the second event would arrest the process. (eg Bypass/Started OFF)…
…didn’t want to give it any more thought until I knew a loopback was a road you wanted to travel!
PS. Like the explicit description on your ps patch.
I’m thinking more of a hardware solution with a USB hub and an Arduino that can do USB hosting.
I didn’t measure the round-trip latency via USB if there is no OS involved but on my Linux box, with ALSA I got around 1 or 2 milliseconds of latency when I routed USB ports to hardware ports and bridged the hardware ports with a MIDI cable. I then connected the second Midihub into the loop which adeed about 1 more millisecond to the overall latency.
At 120 BPM, 1 millisecond delay between two Midihubs would mean roughly 0.2% of a beat.
At 320 BPM, 1 millisecond delay would mean roughly 0.53% of a beat.
Hm… I suppose my routing on the Arduino would add some milliseconds to the latency, but at the same time, I would keep it simple and just route the four inputs to the four outputs and vice versa.
Given Blokas’ experience with Arduino (via MIDIboy), it might be worth elaborating on what you’d want to Arduino/USB hub to do in conjuction with Midihub and sticking it in a new topic to get their advice…
