Hello.
Is there a way to limit the number of “translations” done in a set amount of time?
My use case : I have a midi controller firing up a translator that runs an applescript, with a variable in this script being changed by the value of the controller. This translator is used to control a fader. If I move the midi controller very quickly from the lowest value to the highest value, it will run the script for all 128 values, one after the other. Each time it runs the translator, it takes a while to execute(fraction of a second), but they add up, and the corresponding fader moves a lot slower then the action I did on the midi controller.
What I would like is a way to send fewer values to the fader, maybe even just the last maximum value if I were to instantly move the midi controller from min to max instantaneously. Realistically, something like sampling the midi controller only 5 times per second should be good for my use case.
What I understand is that you want to limit the outgoing MIDI message to your DAW when you turn the encoder. Yes you can do this. You would have the incoming trigger set a global variable and then the output trigger a timer with a delay. As long as you are moving the encoder, the timer would restart the delay time, but when you stop moving, the timer will trigger the outgoing message once the delay time is reached.
Your timer would read the global variable and send it’s value when triggered…
The attached is an example. When turn CC0 it sets the value of ga and sets a 250 ms delayed timer “CC0”. When the timer is triggered (after you stop moving the encoder for 250ms), it sends the value of ga.
I’ve tested the example : while I am moving the controller, the timer keeps getting fired. It will only send the value of the controller if I stop moving.
This is not quite what I need. With this setup, it is impossible to do a slow fade, for example.
Yes, if you want a slow fade while you are moving fast, that would take a different methodology. In the current case, we are just limiting the outgoing MIDI messages to when you stop moving the control.
Maybe you want something that you move the encoder fast but then use a timer to slowly send MIDI messages in the direction you moved the encoder so that it will eventually catch up to your current position? This is something entirely different. Let me know.
That’s not quite it. The script I am firing with the translator is quite slow, and it gets out of Bome slower then the midi control messages that enter it. For example, if I do a fast fade that lasts 0.5 seconds, the output will take about 3 seconds to do the whole fade, running my script on every value of the midi CC that entered Bome. I would like to maybe “drop” some translated outputs so that the end result is as fast as the input. Maybe use the timer to disable the input for a small period of time once triggered, say, 100 ms?
Can you post an example? With what I gave you it should work although your outgoing translator should probably be to fire your script as the outgoing action instead of sending a CC message. With what I sent you, the second translator will only fire when you have stopped moving your cc for 250 ms. Also if you don’t want to see the outgoing CC, you will need to make sure you do not have a MIDI thru path ore you have “Swallow” set for you incoming CC.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
This version has a preset enabled that sets at timer for 30ms so that if there is any MIDI message that comes in faster it will be ignored.
The first looks to see if timer is busy and if it is does nothing, otherwise it sends the CC
The second sets the watchdog timer that will clear the busy flag in 30 ms
The third clears the busy flag.
Hello Steve.
I was able to achieve what I want by using your first example, and tweaking it : I set the timer to 100ms, and I ticked “infinitely” instead of “once”.
This way, it fires my script every 100ms, regardless of it the times has been re-triggered or not, and it doesn’t way for my controller to stop moving to fire the script either. I think it achieves the same thing as your latest solution, in a simpler fashion.
I will keep your second example around as a great example of this kind of logic.
Thanks a lot for your quick responses and for sharing your deep knowledge.
I was getting “engine queue overflow” with the timer set to “infinitely”. I’ve set it to “Multiple Times” and the “repeat count” to 1, and it works as expected now.
I have developed something similar with a data choke and last value.
I had a bit of translators work om a single pedal input transforming it into data for 26 faders. At first try I had the same behaviour - the faders were ‘lagging’ because the amount of calculations to process became too high.
Eventually I resolved it satisfyingly by a couple of modifications:
‘Choke’ the amount of input to be processed. In the first version I had a simple choke that only allowed x out of y incoming pedal MIDI messages to start the process. My current choke is time-restricted: as long as the translators are processing input sequential input is ignored. After its done the process is available to accept another input. Amount of input to be processed can be tweaked by modifying the timer delays.
Additionally to make sure at the end of the MIDI stream always has to process the last input. Otherwise the fader can be in a different position than the pedal because the choke can eat the last input.
To solve this I included two translators: one that fires a delayed timer and stores the input value to a global variable. Then before that translator I included a translator with the same input that kills the timer so that every subsequent input kills /restarts the timer. This continues untill the last input - which logically is the only input that is not killed. That timer then triggers the process once more using the global variable as its input value.
Result is a process that reduces its own processing load depending on how much input it recieves. It always follows the input data as accurately as allowed - the faster the input goes the more input gets filtered. And it always ends by processing the last input.
I assume your controller had motorized faders and most controllers with motorized faders cannot handle more than 2 or 3 faders movement at the same time. I doubt if the lag was do to Bome processing but would like to see the project file with the original problem just to be sure. Bome MIDI translator is very fast and can handle many translations simultaneously without delay unless something has been introduce to force extensive processing. That is why I would like to take a look.
Compared to computing power (like Windows graphics which are handle many times by a graphics processing card), MIDI is relatively slow.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
My BCF has 8 faders - when I control them directly they move very responsive. This issue occured when I programmed some poorly structured code that generated a lot of rules. I remade that part to be more efficient and then it worked OK.
Possibly I may have introduced my own problem by having 1 ms delays in between the triggers? This was years ago when I didnt have as much grasp at how Bome processes stuff then I do now.
Currently I am running a similar script with all timers set to 0 ms delays and it keeps up fluently with 26 faders (at least in my DAW).
I dont have the old project in that WIP state anymore - I can set the delays in my current project to 1 ms again and check if that causes the delayed behaviour again.
This is good news. Yes, introducing delays or having too many rules, could indeed cause some issues. I’ve also seen some controllers that don’t have motorized faders that actually crash when you send back CC values to them. Unless there is some sort of motor movement or LED indication, it simply doesn’t make sense to send CC message back. With that said, the BCF I think has some encoders that have indicators so they SHOULD behave.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz