Hello I am using my encoder with cubase and it is set up so that turning the encoder one way send a midi cc, turning it the other way send another midi cc. Although this works fairly ok for most applications it appears to have a lot of jitter when I use it for zooming my cubase window.
It's not smooth. it jitters and keeps jittering for about 1/5 a second after I release the encoder knob. Sometimes, if i move the encoder very fast it jitters for longer. It works better if I move the encoder very slowly but this is inconvenient.
I have attached pic of the the log windows incoming messages when turning the encoder (fast and slow turning).
I wander if there is a way to stop this behaviour by adding a translator.
You should be able to do this with a timer. See the attached example.
The first translator will take the incoming message but will ignore this if the timer is in process (ga=1). Then it looks for incoming value of 0x6a (106) or 0x6b (107) and if not within the target range, aborts. Once you know it is in the target range and ga=0, then you set ga to 1 to prevent the next incoming message until the timer completes. You set the delay of executing the timer to 50 ms (you can change this if you want to your liking).
The second translator when fired sets ga back to 0 allowing for the next incoming message and then sends out the controller value; gb (captured in the first translator) and value; gc (also captured in the first translator).
I had to use global variables for the cc number and value since these are in separate translators. Local variables would not have worked.
So essentially any spurious incoming messages that come in within a 50ms interval will be eaten.
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist bome@sniz.biz
Thank you very much Steve. I have tried and I set the timer up to 3 seconds (juts to try) and I still gets outputs inbetween as you can see in the pic. The rule are met but MT is outputting MIDI cc. I have never used timers before in MT so I am certainly missing something.
Hi,
Do you have any default MIDI paths? If so, this could be problematic with what I sent you. Maybe you can post the project file and I will have a look.
Keep the following in mind
MIDI IN checked – This will always show the incoming MIDI whether or not a translator is checking for it.
MIDI OUT checked – This will always show outgoing MIDI either by a translator or MIDI through path set.
Incoming checked – This will only show incoming MIDI messages that have a translator that will be triggered. If no translators are triggered, you see nothing.
Outgoing checked – This will only show outgoing MIDI message handled by a translator. MIDI thru messages will not show here.
So if you see MIDI OUT with no Outgoing, it is usually (if not always) means a MIDI through path that is passing the message
If you see MIDI IN but no Incoming, it means that you do not have a translator that handles the trigger of the incoming message.
Note also that Outgoing also shows non-MIDI activity (Timers, Keystrokes and mouse activity)
Incoming also shows non-MIDI activity (Timers, Keystrokes)
But again Incoming and outgoing are always translator type actions, where MIDI IN and MIDI OUT are not always due to translators.
Another thing to consider. If you have a translator that aborts output, the the thru path will still execute (there will be no swallow). So if you want to avoid passing through a message that you want aborted (no MIDI thru) , you need to create another translator with the same incoming trigger and an outgoing of NONE and swallow it.
Again, if I look at your project file, I can probably figure out what is happening.
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist bome@sniz.biz
OH... I see.... If i remove the midi through link in the router section it is working. However now all the other midi messages are not going through. Is there any way around this? Like having an exception just for this midi cc?
Otherwise the alternative is to leave the midi through connection and change my setting in cubase (so that these midi cc (106 and 107) don\'t do anything and increase the output variable (ie. +10) to change the midi cc -(ie from 106 to 116 and 107 to 117 for example) and use that as my controller for zooming.
I’m not seeing a problem however you could change where you set the delay and maybe that would help.
Instead of setting the second delay (execute action after delay), try setting the initial delay instead. I think I’ve been tripped up on the difference before but cannot remember the subtleties.
Below is the text from the manual that talks about this.
“Note that for starting a timer, you can specify an initial delay, and there is
also the possibility to specify an action delay (see Delaying Outgoing
Actions). Those two delays add up, but there is a big difference: by delaying
the outgoing action, the timer will not exist before the outgoing action delay
has passed. So during that time you cannot kill or override that timer! Consequently, you should avoid delaying an outgoing timer action, and rather use the timer’s (initial) delay.”
So if I read it correctly using the first box can cancel the timer (initial delay) for a new incoming message while the second section (action delay) you cannot so any pending timers would still fire.
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist bome@sniz.biz
Yes, you create another translator with the same rules after this with the output of NONE. Then add the default path back in.
When the first translator aborts, the second translator will swallow the message to stop the jitter but all other MIDI messages should go through untouched.
both delays work well only when I delete the link between my controller and the MT midi output in the router. but that means I loose all the other midi data and only messages from the translators are going through. I found this strange because in the translator I have ticked the box “swallow MIDI message” so if I keep the link it should not send the midi message but only the output set in the translator (?)
PS I have tried the way round from my previous post (changing the output to gd (gd=gb+10) and it does the trick so the matter is now resolved. Thank you for your support Steve!
The attached has a MIDI thru path from My Controller to Application.
The 1st translator handles the de-jitter.
The 2nd translator stops the de-jitter aborting actions from getting thru the defined midi thru path. Note, it still qualifies the cc numbers but does not set or clear any other variables. Since output is none, only these CC’s are swallowed.
I just posted another.
Remember swallow only works if MIDI through paths are set if either the outgoing action executes or the outgoing action is none. If you have a condition to exit rules, skip outgoing action, then the thru path will still kick in, so another translator with output of NONE is necessary with same input conditions in order for swallow to work.
I’ve been burnt by this rule before and is primarily the reason I usually do everything with translators instead of using MIDI thru paths. I use MIDI thru paths if I am doing something quick and dirty.
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist bome@sniz.biz
](https://www.bome.com/wp-content/uploads/cma_attachments/1573676449495_fast.PNG){kind=link}
](https://www.bome.com/wp-content/uploads/cma_attachments/1573676450786_slow.PNG){kind=link}
](https://www.bome.com/wp-content/uploads/cma_attachments/1573767058984_Capture.PNG){kind=link}
](https://www.bome.com/wp-content/uploads/cma_attachments/1573770828962_delay.png){kind=link}