I’ve recently purchased a Yamaha CK61 keyboard to use alongside my laptop virtual setup (MainStage). The CK is fantastic because its MIDI implementation is pretty deep and thorough, and in a specific use case, a little too thorough.
When I change Live Sets (essentially Combos / Programs) on the Yamaha CK, it sends out very useful Bank and PC messages which I can pick up in MainStage (via Bome) to change the corresponding patch there. Problem is, the CK then follows these Bank and PC messages with a whole series of CC and Sysex messages to communicate the initial values of the knobs and faders and buttons. I have configured MainStage to respond to these messages because I want to be able to modify some of the parameters later on after I’ve selected the Live Set / patch - what I DON’T want, is for MainStage wholesale change all these parameters just after the CK Live Set / MS patch has been selected. I want MainStage to ignore the initial flurry of ‘initialisation’ CCs and Sysex messages from the CK.
There doesn’t seem to be a way to turn off this initial CC and Sysex dump from the CK each time a Live Set is selected, so I need to filter them out in Bome. In my mind what I want is something like;
- If Bome receives a Bank or PC message, for the next 500ms, swallow all CC and Sysex messages coming through
I know there is a Timer Action in Bome but I would appreciate some help how to build this in Bome. I also want to make sure that I minimise the risk of the ‘swallow’ action happening indefinitely under edge cases / conditions and instead, if it crashes or fails somehow, it should just let everything through like normal.
Appreciate if someone could point me in the right direction of how to do this - thanks very much.
Please find the attached. The first preset (0) I use for most of my projects for housekeeping purposes and won’t be discussed here but you can look at this tutorial.
The second preset (1) provides an example of how this can be done.
Translator 0.0 take a Program Chane as input and checks if the one shot timer ‘Blocking Timer’ (0.1) is running. If it is, then ga will be 1 and we do nothing. If the timer is not running, then set the value of ga (timer running) to 1. We then trigger translator 0.3 which disables MIDI thru path. We also trigger ‘SendPC’ (translator 0.6) to allow the incoming PC message to get through. We do both of these in the rules of translator 0.0. Then for output of translator 0.0 we start a 500ms timer ‘Blocking Timer’ (0.1).
Translator 0.1 is our blocking timer. When it triggers (in 500ms) it will set ga back to 0 and trigger 0.1 to enable the thru routes again.
Translator 0.4 triggers translator 0.5 in rules allowing CC to go through if the timer is not running. (ga=0)
If perform actions don’t work for you, please update to the latest Bome MIDI Translator Pro release.
Now if you have other translators that are used for CC’s or PC’s you will need to add this rule to determine if you want them to work.
if ga==1 then exit rules, skip outgoing action.
Keep in mind that if a MIDI thru route is enabled, the message will still get through. To prevent this you might need additional blocking translators with the same incoming action and an output of ‘None’ to prevent this (only if the MIDI thru route is enabled at the time). Timing can be a bit tricky here which is why I used Perform CC instead in my example.
I’ve looked through your example in detail (I assume you meant to refer to the Translators as 1.x not 0.x, since the 0 Preset is the Init one in your attached example) alongside your notes below and want to clarify a few things;
1.1 Blocking Timer I guess is really an ‘unblock’ procedure, or ‘Release Block’ - basically set the ga flag back to 0 (no blocking in place) and call the Perform Enable Translator (procedure)
What’s the reason for having a separate ‘Perform Enable’ translator that simply re-enables the MIDI Route previously disabled? Why not have re-enabling action be the Outgoing action of 1.1 above?
Similarly, what’s the reason for having a separate Send PC message in 1.6 to assure it gets through no matter what? Would this not be achieved by simply unticking the ‘Swallow MIDI message’ option in 1.0 which is already being triggered by a PC event? Actually, aside from my curiosity about separating this out, I realise I may still need to keep 1.6 regardless, and script similarly for Bank LSB and Bank MSB, which are all required to go through unimpeded for my use case to work
Why are 1.4 and 1.5 required? If the MIDI route is no longer disabled, then all traffic would pass through like normal, so why is there the need to call out specifically the CCs to be checked against the ga=0 state
Many thanks for this. I’m as interested in solving my immediate functional problem, as I am in understanding the best practices in order to improve my Bome scripting ability going forward. So thanks for this.
Indeed, all of the translators related you your request are in preset 1.
While the timer is running (ga=1) the path is disabled. When it triggers 1000 ms later it becomes enabled. Translator 1.0 starts the timer setting ga to 1 and translator 1.1 completes it, setting ga back to 0 and then re-enables the path.
Although I didn’t use it, I though in the future I may want to have a separate translator with a different incoming trigger that enables the path. This way I can have different triggers that can perform the same function and by using perform, I only have to use edit one translator if the there needs to be a change in rules. For instance, what happens if the path was disabled when you shut the project down?? The path would be disabled when you re-start the project. You can add a translator with incoming trigger Perform ‘Init’ and ougoing action Perform ‘Enable’ to ensure the path is always enabled at project start (when Perform ‘Init’ runs).
Great question. I first tried turning off swallow but the PC message didn’t get through probably because the thru path was already disabled by the rule above it. This was my quick workaround. I’m finding perform quite useful for things like this. Perform was introduced in V 1.9.1 of Bome MIDI Translator Pro.
Yes, as mentioned before, perform is a great addition to allow multiple triggers to handle the same outgoing action and avoid having to weed through a bunch of translators when the defined processing and outgoing action needs to be changed.
1.4 is a blocking translator. It is used to make sure nothing get through the defined MIDI through path (if enabled) by having the outgoing action set to none. It turns out that if you use a rule like ‘exit rules, skip outgoing action’ then the incoming MIDI message will still go through the defined MIDI routes because the translator did not execute. The MIDI thru will always happen unless a put in a separate blocking translator with outgoing action of ‘None’ so that the translator executes. In a nutshell, swallow on translators only work if a given translator executes. It took me about 6 months to learn the subtlety. For this reason, I typically do not use MIDI thru paths in my projects unless I have to (for instance, allowing SysEX with possible varying length as in this project).
So translator 1.4 ensures that swallow always works (the outgoing action of ‘none’ completes, yet if the path is enabled (ga=0) we use perform to send the CC through manually with a separate translator.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz