Trigger keystroke when certain cc-range is passed

  • Q&A Forum
  • Trigger keystroke when certain cc-range is passed
0
0

I’m trying to figure out how to construct a rule which trigers a keyboard action when a fader passes a certain range. The fader in question sends midi cc.

When the fader is travelling downwards I want to trigger a keystroke when it enters the cc value-range: 0-9.

When the fader is travelling upwards I want to trigger a keystroke when it enters the cc value-range: 10-19.

The keystroke shall only be triggered once upon reaching a the new range.

Since the fader in question does not send all consecutive cc values I can not specify a certain cc value to trigger the event since that value may be skipped (probably as a kind of data thinning). Also since the direction of travel is crucial I find it hard to figure out how to do this.

The hardware Midi Event Processor Plus from Midi Solutions can do this by means of a function called “moves into range” and I’m trying to replicate this using Midi Translator but so far without sucess.

 

Marked as spam
Posted by (Q&A Forum: 1, Answers: 2)
January 27, 2019 1:07 pm
35 views

Please clarify whether you want to play a note or generate a computer keystroke action. If it is a note, we can do it with a single translator. Since keyboard actions are different for each key we will need 2 translators to do this.

( at January 27, 2019 7:44 pm)

It’s a computer keystroke.

( at January 27, 2019 8:48 pm)

OK, then you can use the same strategy as I provided but if they are separate computer keystrokes, you will need to have each keystroke in it’s outgoing action in a separate translator. The logic should be pretty similar though. Let me know if you still need help.

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

( at January 27, 2019 8:50 pm)
0
Private answer

OK, thanks. Very interesting.

Are ga and gb by definition set to zero initially?

The ga value will only be set when a shift occurs if I understand this correctly so the labels up and down dont’ really correspond to the “real” fader travel direction right?

 

Marked as spam
Posted by (Q&A Forum: 1, Answers: 2)
January 27, 2019 9:10 pm
Yes all global variables are initially known to be zero, so your initial fader movement will always be an up movement since you will never see a fader position of less than 0. You found a bug. In the abort label we need to update fader position before exiting rules. The direction will correspond to the last known fader position ”ga” and the current fader position recorded by the translator ”qq” which is a local variable. We evaluate that as the first two rules but don’t care about the value other than if it is higher or lower.
( at January 27, 2019 11:07 pm)

Thanks, I have sucessfully made he idea work but I believe there could be some efficency improvements if I could make global varialbles “between” translators. Am I right to assume that global variables are exclusive for each translator or is there a way to share values between active translators?

( at February 6, 2019 11:27 pm)

Global variables are visible to all translators. As a good practice it is best to minimize the number of translators that update the global variables. Not good to have multiple translators to try and update the same variable at the same time.

In contract local variables are just that. They are local to a given incoming trigger. Keep in mind if two translators have the same incoming action, the variables are essentially shared between translators with that EXACT incoming trigger.

Global variables are always initially zero (unless you change them otherwise at project open).
Local variables are “undefined” unless you set them on either the incoming action or rules. They can be anything so make sure something is setting them before you try and use them.

( at February 7, 2019 12:13 am)
0
Private answer

Whoops here is the example file described in the last answer.

 

Marked as spam
Posted by (Q&A Forum: 36, Answers: 3116)
January 27, 2019 8:19 pm
0
Private answer

Here is a way you can do it for sending keyboard notes. Basically we look at the direction we are moving the fader by comparing the incoming fader position to the last known value.

Then depending on whether the fader is moving up or down we go to it’s respective label (section).

We determine if we have already sent the note and if we have we abort. If not, we check it’s range and if it is in range we set the outgoing note value and flow to the “done” label which will execute the outgoing action with the note value.

In this example I use note 5 for down and note 10 for up. I set the global variable before exiting for comparing the values to the incoming cc range on the next iteration.

Incoming CC 48 on MIDI channel 1 set value to qq

// determine driection
if qq<ga then Goto “down”
if qq>ga then Goto “up”

Label “down”
// check if down sent
if gb==-1 then Goto “abort”
if qq>=9 then exit rules, skip Outgoing Action
// set down note
pp=5
// set down sent
gb=-1
Goto “done”

Label “up”
// check if up sent
if gb==1 then Goto “abort”
if qq<10 then exit rules, skip Outgoing Action
if qq>19 then exit rules, skip Outgoing Action
// set up note
pp=10
// set up sent
gb=1
Goto “done”

Label “abort”

exit rules, skip Outgoing Action

Label “done”
ga=qq

Outgoing: Note on MIDI channel 1 note pp and value 127

 


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

Marked as spam
Posted by (Q&A Forum: 36, Answers: 3116)
January 27, 2019 8:18 pm