Saw bits and pieces but this is the issue
In cubse midi remote, using a normal cc for quick controls is way too coarse for eg eq freq
Im using an iconpad which sends relative cc (mackie control) but has a press encoder
Im thinking it would be good to press down for coarse 14bit and then fine 14 bit
Is this possible?
Cheers
Hi,
Something like the attached should work. I’m using VPOT-1 (turn CC=16) and push value is note 32.
The first translator sets the value of ga to 0 if released and 1 if pushed.
The second translator sends CC 16 with the 14 bit value of gb. We update the value of gb with the delta value of the turn when pushed but if we release the VPOT, then we multiply that delta by 128 (bit shift 7 bits left) so that it affects the course value.
Here are the rules of translator 0.1:
// Which VPOT 16-23
if pp!=16 then exit rules, skip Outgoing Action
// outgoing cc
tt=pp
if qq>64 then rr=qq-64
if qq>64 then rr=rr*-1
if qq<64 then rr=qq
// check button for course or fine
if ga==0 then Goto "Course"
// Fine
gb=gb+rr
Goto "Done"
Label "Course"
rr=rr<<7
gb=gb+rr
Label "Done"
if gb>16383 then gb=16383
if gb<0 then gb=0
Log "Log value = %rr%"
Log "Log outgoing value = %gb%"
I have not tested with quick controls so I don’t know if cubase recognizes 14 bit CC’s but if it does, then this should work.
VPOT-Course-Fine.bmtp (1.7 KB)
Steve Caldwell
Bome Customer Care
Brilliant as always Steve
I would still love it if a range or min/max was introduces to bmtp
ie
if pp! = range(16, 32) the exit…but anyway another discussion
It seems to be working on the cubase side but with issues unrelated to NRPN
So Steve, when you are scanning for a range of vpots ie 1-8 what is your best practice way to filter only those cc etc?
So say you have CC8 to CC 15 that you want to use
Incoming: Control Change on MIDI Channel 1 any CC set to pp and any value set to qq
if pp<8 then exit rules, skip outgoing action
if pp>15 then exit rules, skip outgoing action
// below we add what we want to do
...
Steve Caldwell
Bome Customer Care
Ah ok…yeah thats what i normally do, thought there was a better way
Also, if in the example, using globals for the push check, its likely there could be 2 down at same time, so you cant use locals becquse of scope which means u would need a global per press right?
Use locals where possible to avoid name collision. Only use globals if you want to share across translators and if you do make sure you only have 1 translator update the global.
Steve Caldwell
Bome Customer Care
Cheers
So how does RPN increment/dec work?
The issue I have is that the above is absolute…but I need it to be a 14 bit so there is fine resolution at the DAW end
How would best practice be to adapt the code that you did?
Hi, it really depends if Cubase understands NRPN increment and NRPN decrement. Right now I set it up for 14 bit CC absolute values from a 7 bit relative VPOT style controller.
14 bit CC has 13384 values so that should be fine enough tuning, however if Cubase doesn’t understand that or NRPN, I’m not sure what can be done. You might want to check with Steinburg on what MIDI messages you can learn besides 7 bit CC absolute.
Steve Caldwell
Bome Customer Care
It learnt the example without issue
also seems to understand nrpn
Im just wondering how that would amend the orig code you did. Surely there are others that would love to have the funcitonailty?
Currently it would be so simple to use 7bit relative with 16838 and type into the value max field but alas , when a 7 bit is chosen, there is no way to increase the increment finer
In the example I provided, if you do not push the encoder, it should increment and decrement by 256 however if you push and turn, it should increment and decrement by only one.
I set it up so V-POT push which is Note-on Note 32 MIDI channel 1. When you release it is Note-off Note 32 MIDI channel 1. It adjusts the value of ga so that the other translator will be have differently when pushed (fine tune) than when released (coarse tune).
Steve Caldwell
Bome Customer Care
Yep…totally understand…and it got me going…thanks…was quite simple the 14bit was what I didnt have down as not really used it previously except for PB
However I found, the push down was better mapping to a secondary encoder function so that eg with EQ, the freq is no press, gain is press and turn etc I just used ga to add to channel number; just need a double click and hold for Q but I have that in other code and will paste in once I get the framework settled in with a bit of use
the “feel” of eq is better being fairly immediate…push encoder is perfect
my hand is resting on the keypad most of the time so it was easier and more comfortable to use ctrl and shift for fine/coarse.
Its also context dependent…eg when doing time adjustments eg for a perc slab back delay, using host bpm sync does not take into account feel…by just a couple of ms either way it pushes or pulls the feel and the increment of 1 is really useful there…although when dialing in, you can use eg ctrl to get in the ball park then do the 1 unit increment
But the issue remains that scale/pickup is not anywhere near as good as relative so I was hoping to get that going in 14bit equivalent
Cheers
If relative works for you, we could probably set it up so when you press and turn, it takes 2 clicks to change the value by 1 thereby giving meaning you have to turn the knob more to get movement.
Not many vendors support NRPN increment and decrement and I don’t think there is such a thing as a 14 bit relative encoder.
If Cubase supports 7 bit relative then as I said, just make every 2 clicks of an incoming message send one click outgoing message.
Maybe I’m not understanding what you want correctly.
Steve Caldwell
Bome Customer Care
I guess its layered in Cubase quirks
Dont worry about the press at the moment…just the control
Ideally you would have 7bit relative spread out of a possible 16383 scale ie instead of inc/dec with a max of 128 steps, the relative would have a target of up to 16383
We have been chatting on the forum about it…it means that each encoder inc is capable of up to 14bit values because an inc/dec shouldnt care about a max…it just keeps going until target
Since cubase (most daw I imagine) just parametises between 0-1, we just want 1/max value = steps
Because we currently have to trick Cubase, I wanted to send a 14bit dec/inc controller instead of absolute…who knows if and when they ever do anything or whether they even understand it…but its not just me 
HTH?
When you are moving a relative encoder, you will seldom get any more than 1 or 2 increments or decrements unless you move the encoder really fast in which case maybe you will get up to 5. Theoretically there is no MIN or max value of a relative encoder. So there is not scaling needed. With that said, you can certainly either multiply or divide the number of clicks coming from the encoder using Bome MIDI Translator so that it sends more or less than what the physical encoder is sending.
I think we might be saying the same thing but in a different way. I don’t see any value of sending 14 bit NRPN over a 14 bit CC vs a 7 bit inc/Dec CC. If Cubase supports relative, it would just be easiest to send relative and let Cubase take it from there.
Steve Caldwell
Bome Customer Care
Yeah I havent been able to explain it well
In other words,
Yes, an encoder only need 1 inc per encoder detent
BUT
the range of the inc/decrement is only 128 values so each step of an inc/dec is 1/128 = 0.0078125
THIS is the problem
IF Cubase allowed a larger MAX value than 128 then the problem would be solved
BUT it doesnt
SO
I noticed there seems to be an inc/dec for RPN and Cubase should interpret this
THE solution is to send a 14bit inc/dec if it were possible
This is interesting and suggests a 14bit increment?
Actually this explains the whole lot really well
I would need to play with this, however, if Cubase only handles 128 steps for other parameters then it is likely that it would do the same for NRPN. So in essence you are looking for Cubase to handle better precision. For example instead of 1/128 (.0078125) increments/decrements for each tick, you want 1/16384 increments/decrements for each tick (.00006103515625). Or maybe just 1/256 (0.00390625) would be sufficient. Have you brought this up with Steinberg?
Steve Caldwell
Bome Customer Care
Hi, I had no luck with NRPN increment/decrement, however, I changed the fine tune frequency to 512 and adjusted the translator to match and it seems to work pretty good.
VPOT-Course-Fine.bmtp (2.3 KB)
Steve Caldwell
Bome Customer Care
Yeah the absolute tune I had no idea existing or the master tune as it seems to have disappeared from all master keyboards or plugins…but I use 428 for many reasons as it just seems a lot easier to sing too
Ill check it out today.
Yep its on the forum as a request but no return from Steiny
