I would like to be able to implement simple logic.
I have one example where I would like chords to be routed differently from single notes, so that I can play a mono synth and a polysynth at the same time and the note allocation is automatic just depending on how many notes I hold down.
But being able to add simple conditional statements such as “if number of notes > 1 choose pipe A; Else chose pipe B” have an enormous potential.
I understand that the interface is made to be simple and that most users do not want to engage with actual coding, but I think this can be done in a block in a very clear and intuitive way, with boxes of options and not in a completely free “code” fashion.
But just opening up the possibilities of comparing different states and conditions would be really powerful.
Even just implementing it as a more advanced Bypass control would be great.
So instead of a MIDI mapped bypass it would be a condition: “If numbers of notes held> 1: Bypass = TRUE”
“If CC 01 > 64 AND Note Number <56: Bypass = TRUE” and so on.
Conditional Statements Upvoted!
I have a vague memory this was discussed before and I got the sense from something @Giedrius wrote that they were on it, but only want to roll it out when they can make it really intuitive and not put non-logicians off. But maybe I’m just imagining that…
(it’s a nice little thought exercise, though eh, imagining how you’d break it to really discrete pipe-size chunks? I’d start with one or more Condition Pipes… )
+1 from me too
I think the simplest implementation would be a conditional router pipe
It would look like a virtual output pipe, but would play the part of either one or another virtual pipe depending on an IF clause
The conditions definition could look something similar to the input definitions for a transform pipe
I think this would limit things to only one or two conditional statements in a row, because the number of virtual busses is small, but it would still be a powerful addition
+1
I also would like some kind of logic. Even something as simple as a conditional pipe with ability to trigger/disable a pipeline would be amazing.
The mapping on Disable is not good enough. I’ve noticed in a typical fashion it forces you to hold the key to enable/disable something. There is no direct way to use it as a toggle.
I’d like to be able to toggle certain pipelines with mapped buttons.
E.g., I’ve got a a button, which remaps channels on my midi controller to be able to play multiple synths, allowing me to flip between different channels.
(Hi & Welcome to Midihub!)
dunno what Blokas have in mind, but pretty sure the much-anticipated Firmware Update With Scaleable Mappings will include at least this level of functionality.
In the meantime, if you want a fix and are willing to use a loopback (and able, in terms of available MIDI/USB ports…), you could simplify Giedrius’ elegant switching solution here then place it in a loop such that the CC that leaves the line presents itself as an external event ready for mapping.
(patch worth looking at anyway as a way of using Dispatcher as a simple state cycle!)
That would be enough for “On/Off on successive presses” and more.
Other loopback solutions can go a lot further.
If you decide to go down this route, @Hipstere, let me know via a Message/ Support topic and I’ll post the _LoopbackMapSetGenerator.mhp patch which makes it a breeze to set mappings from loopback.
Hi,
Thank you for your input! 
I like this approach, but I don’t want to change scenes, I actually want to have more flexibiility in a particular scene.
I have sort of solved this issue by using virtual ports - I convert a note on my keyboard to a CC and then map it to the channel mapping pipe. It is doable, but the problem is it is overly complicated and if I use this up just for this one function, I don’t have a lot freedom left to create something more complex, as even the virtual ports are very limited.
while the version Giedrius wrote for that users needs was about scene changing, he’s employed for a variety of purposes. (including a sequencer!)
The key bit is that each time the “trigger event” goes in, the Dispatcher moves to a different channel, so Transforms the (now) note into whatever you want.
So with say a 3-channel Dispatcher, it would go
- Transform1A, Transform1B, etc
- Transform2A, Transform2B, etc
- Transform3A, Transform3B, etc
- back to 1 again…
I recommended it for your use-case (within a loopback to make it control stuff in Midihub rather than just externally) as e.g
- Turn BypassX ON, BypassY OFF, Trigger One-shot LFOZ, etc, etc
- Turn BypassX OFF, BypassY ON, Stop LFOZ running, etc, etc
This is quite powerful and uses no virtuals (but like all loopbacks uses MIDI port pair 
or USB port pair
Does that make sense?
Feel free to send more detail what you want to do that Midihub-as-is can’t. There’s likely a way. Might even keep me away from the deep dark rabbit hole that is currently beckoning me…
unless you have a device which is linking to-from Midihub (with care also do-able)
Long time since I was here, but YES, conditional statements, hooorrrraaayyy!!
Right now I have a setup where I need to toggle between a Korg SQ64 being the master clock, or where the DAW (Studio One) is the master clock, and Korg SQ64 then follows. And it would be amazing if I could have conditions in Midihub instead, using the SQ64 clock in a standard pipeline, and then if a clock shows up on another input (the DAW clock) mute the clock from the SQ64 and use DAW clock instead etc.
There’s a few more constraints than this but in general if there were conditions available in a pipeline, that could be based on data in any pipeline, this would become a VERY powerful addition, imho, it’s a game changer!
So this “switch” would need to constantly poll the DAW input and make the inverse action if no clock was detected during some defined time-interval?
Not knowing how anything works technically, I am just thinking, something that instantly recognize the message “Oh here’s a clock coming”, and triggers stuff based on that.
Another important thing is that conditions are global, and have access to all data from all pipelines, in order to build autonomous “intelligent” solutions.
Say I have a pipeline routing the SQ64 clock permanently, and WHEN there’s a DAW clock popping up, the pipeline for that input then shuts down the SQ64 clock (using a transformation or something etc.) and then the pipeline routes the DAW clock to chosen output (in my case, same as the SQ64 clock was routed to).
Yeah, got that.
My q was more on a logic basis (which would lead to a technical consideration beyond my capabilities!), namely:
-
in addition to “Oh here’s a clock coming”
-
it would also need “hey, there’s no longer any clocks”
to then know to switch back…
That’s a very good point, potentially another condition “If this clock is running and stops, go back to the pipeline with the SQ64 clock” or something in that direction.
indeed!
particularly cos a general pipe design might want to listen to an on-condition and an off-condition at different sources, then send a yet-to-be-implemented internal mapping to carry out the action.
Pretty sure your specific case could be written with a loopback now, but the more general idea is quite appealing…
Feel free to elaborate (loopback solution etc.), but yeah, the concept of conditions would be a total killer!