How to Detect Increments of MIDI Value?

Is there a way to use Rules to detect an increase or decrease in MIDI value? I want to use a knob on my midi controller to output right brackets when turning it clockwise and left brackets when turning it counter-clockwise so I can control brush size in Photoshop.

Hi, yes the best way I’ve found is to use a global variable and then a timer to periodically set keystrokes.

The attached file illustrates this for some work I did for a Capture1 user that wanted Left Arrow and right arrow.

The first translator just documents the global variables I’m using so I don’t mess myself up later.

The second translator “Fader 1 Movement” compares the incoming value to the last known value and then uses that value to trigger a timer to send keystrokes by the value changed.

The third (Left) and forth (Right)  translators look at the value, only if the value is in the desired direction will it trigger a keystroke. So either the third or forth translator will fire a key stroke but not both.

The final one “Center Fader 1”. Suppresses the keystroke by pressing and holding the button while repositioning your fader in case you need to re-center your fader.

Of course you will need to adjust the incoming message for the fader you are using (Fader1 Movement) and for the “Center Fader 1” translator . You will also need to change your outgoing keystrokes for “Left” and “Right”.

To change the speed of the keystrokes, you can add a repeat delay to the outgoing action of “Fader 1 Movement” ( 1000=1 second)

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

I’ve been trying to figure out how to do that for like a year, thank you so much!

My pleasure!

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

In what way could I change this to output less than 127 characters? It works perfectly, but since it outputs 127 brackets it is very sensitive when changing brush size.

In the second translator you can adjust the amount of keystrokes to send by altering the value of qq

// Fix counter to positive
if qq

What exactly would I do? Because when I set qq=qq*-10 it doesn’t seem to make any change.

Try this (substitute 1/3 for the fraction you want to use // scale it to 1/3 original value // and put into rr rr=qq*1 rr=rr/3 // make it at least once if rr==0 then rr=1 qq=rr

Like this?

Yes that looks right. Note that when you get to the either end, it will always move 1 click no matter how far you turn it.

It behaves the same way as before, am I missing something? What I specifically want it to do is only output a right bracket every time the MIDI value increases by 5 and only output a left bracket every time the MIDI value decreases by 5.

This will be more difficult as every time the incoming trigger happens, it will automatically adjust the last value so you will never see a trigger more than one unless you set a delay time. So there will have to be a timer set and you will need to move it more than 5 within a defined timeframe. If you only move it 1-4 within that timeframe, you want nothing to happen. I will see what I can do to re-work it.

So right now moving it just 1 tick right or left sends more than 1 [ or ] ?

This should get you closer. You need to change it to your own input MIDI CC value.

In this version, we use the global variable gf to determine the amount of time needed to count your difference from last position and curent postion (ge) for the count.  In other words, you must turn the wheel at least ge times within gf milliseconds for the outgoing keystroke to complete.

We use a one shot watchdog timer to give us time to count the increment/decrement amount of ge. When the watchdog timer goes off, it then triggers the Fader1 timer, if the amount is greater than ge and triggers the keystroke  count/ge times.

 

 

Only one of  the fader timers send  keystrokes either [ or ] .

I set up 3 other translators to manage the global variables.

 

 

Ah I see, this is more complicated than I thought it would be. As it is right now, Each time I move it 1 tick it will send one [ or ] but the problem is that halfway through the knob turning I will reach maximum brush size due to the amount of brackets it sends which makes the other half of the knob essentially useless until I turn it the other way. Changing the repeat delay does not fix the problem as it makes the knob send an amount of brackets relative to the speed of the knob turn (the slower the turn, the more brackets it instantly sends) and if I turn it too fast then it instantly sends a small amount of brackets then outputs brackets one by one at the rate of the repeat delay until all 127 have been output.

Maybe if you center the knob, it will fix your issue. Another approach is to make it slowly send ] when value is greater than say 70 and send slowly [ when the value is less than say 60. Use that with an “right” timer and a “left” timer. When the value < 70 you make sure the right timer is killed. When the value > 60 make sure the left timer is killed.

Timer >70 : Right timer running Left timer killed
Between 60 and 70 : Both timers killed
Timer

This is much closer to what I’m going for, the only issue I have with this is that the control is tied to the rate I’m turning the knob which is jarring because it is hard to always turn the knob at a consistent speed.

Now it is your turn to do the final tweaks. For a complete (with fee) solution, feel free to send me an email and I can spend more time with you.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

After some more experimenting I’ve discovered that the main issue I’m having is not with the fact that it is incremental, but because there is some latency when turning the knob on my midi controller. I’ve made a new project where the brush size is controlled by two knobs (one for [ and the other for ]) I kept the knobs absolute and made them output a keystroke every 8 midi values from 0 to 127. However, the same problem as the incremental solution you gave persists; the faster I turn the knob, the less keystrokes are output. Do you have any ideas why I may be experiencing latency?

P.S. Forgive my repeated use of if statements, this is my first time writing my own rules.

The most likely suspect is that the keystrokes are being sent too fast for the application receiving them. You might want to use the outgoing keystroke timer to put a an additional delay between every outgoing keystroke and play with the delay time increasing the delay until it is long enough for the application to capture them.

I think it has to do with the midi input skipping values because the log window visibly shows skipping in controller values. I don’t know if it’s an inherent thing in the software that some controller values will be skipped if you change a controller too fast, but in my DAW if I assign the same knob to a control there is pretty much no latency regardless of how fast I am moving the knob.

I agree, I just tested with my LX25+ and if you turn the knob fast, the controller skips values. This means that you will need to determine if a given value has been skipped over and send keystroke if one of your target values has been passed.

I don’t have any other MIDI controllers to test this with, is the problem exclusive to Nektar products?

This will get you closer but not perfect. It will determine if you have moved more than 7 clicks since last movement and if so, will output character the amount moved divided by 7. Unfortunately it does not test whether you have “passed” an desired click value so if you move 6 then 6 again, nothing happens. Will need to determine logic on when we have crossed over given points moving both up and down to make it completely what you want.

 

Here is another shot. Unfortunately due to timing issues I have to put a 180 ms delay on output so that we have enough time to evaluate the move of the knob. and then send out up to 18 keystrokes output.

 

This one uses a timerto figure out how many times, the knob has passed a trigger mark (every 7 ticks) when the knob has moved.

It then uses the count to determine how many keystrokes to send (either left or right).

 

Let me know what you think.

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

This one should be even cleaner. Instead of using a timer to figure out how many clicks to turn, I figured out the proper math thereby reducing the number of timers required.

 

When setting the delay to 0 ms this is absolutely perfect. I’m not sure why you made the initial delay 100 ms because it works just the same without a delay. Thank you very much.

This is even better than I realized because I can easily set the amount of keystrokes it outputs by changing g0=gd/(integer) g1=ge/(integer). What an absolutely beautiful solution you have provided, I could not find a single thing on the internet that works even remotely as well as this.

I’m glad I could help. For me, if I did not set a delay, I would get too many keystrokes in a single direction if I set the delay too low. For the calculations, you should never get more than 18 keystrokes in one direction. Without the delay, I was sometimes getting twice that as I don’t think the translator was giving enough time to calculate the number of clicks.

That’s strange, for me it always puts out 18 keystrokes with a 0 ms delay no matter what I do.

Glad to hear it. That should work perfectly for you then. I’m not happy with Nektar for skipping MIDI values though. I guess they were trying to reduce MIDI traffic. Maybe it is a parameter that can be changed. I often deal with idiosyncrancies of various manufacturers’ MIDI implementations.

It looks like this is a switchable feature with shift-null. Look at page 10

https://system.na3.netsuite.com/c.1289520/Downloads/Impact_LX+_User_Guides/Impact_LX25+_User_Guide_ENG_1.0.pdf

I am unsure if the shift-null makes a difference as it seemed to react the same regardless of whether it was turned on or not, however an alternative solution I’ve found is to change the Data 2 value of the knob using the instructions on page 16 to a desired value of keystrokes I would like to output.

Actually nevermind, even when I set it to 9 CC values there is still some skipping when I turn the knob quickly.

Right, reading on with shift null it looks like it is really a different function and is to handle takeover mode locally in case a DAW can’t handle it. I don’t know any DAW that can’t handle it’s own takeover.

I think it’s so the parameter doesn’t jump to the value of the knob or fader when you link it to a control in a DAW.