I am trying to create a remote panel with my Mackie C4 for the Novation A-Station. The incoming side from the A-Station is working and everything is reflected on Mackie C4 properly. So turning a knob on the A-Station, shows the value and the Led ring. The values are also stored in variables. I followed this tutorial here: https://www.youtube.com/watch?v=yjgmIUIS0SI
to make my Mackie C4 encoders working. This solution works only partially. The incremental value part works, but the decremental part does not work as expected. From a full 127 value, i am down to zero in two ticks turning the encoder to the left. The rule looks like this:
// This will make 127=-1 and 126=-2 etc
if pp>64 then rr=pp-128
// This subtracts the current value of ga (absolute out)
if pp>64 then ga=ga+rr
// This will add to current value of ga (absolute out)
if pp<=64 then ga=pp+ga
// This ensures output never goes less than 0
if ga<0 then ga=0
// this ensures output never goes more than 127
if ga>127 then ga=127
What is wrong, that the decremental values dont work as expected?
I believe Mackie VPOTs us different logic for negative values. For instance a value of -1 is depicted as 0x41 (65), a negative value of 2 is 0x42 (66) etc.
The below logic should work assuming that the in coming VPOT number is set to the value of pp and the incoming velocity is qq.
In this example, we set the global variables g0-g7 for the values of 0-127. The single translator handles 8 VPOTS.
We scale the valued from 0-11 for the VPOT Rings.
The outgoing value for the rings should be set to qq.
Rules:
// vpots0-7 only
if pp<16 then exit rules, skip Outgoing Action
if pp>23 then exit rules, skip Outgoing Action
// normalize for eveluation later
rr=pp-16
// set increment/decrement
tt=qq
if qq>64 then tt=64-qq
// get from global variables
if rr==0 then uu=g0
if rr==1 then uu=g1
if rr==2 then uu=g2
if rr==3 then uu=g3
if rr==4 then uu=g4
if rr==5 then uu=g5
if rr==6 then uu=g6
if rr==7 then uu=g7
// add increment/decrement
uu=uu+tt
// Set limits
if uu<0 then uu=0
if uu>127 then uu=127
// put back into global variable
if rr==0 then g0=uu
if rr==1 then g1=uu
if rr==2 then g2=uu
if rr==3 then g3=uu
if rr==4 then g4=uu
if rr==5 then g5=uu
if rr==6 then g6=uu
if rr==7 then g7=uu
// display 1-8
rr=uu+1
Log ‘Log outgoing value of VPOT %rr% = %tt% value=%uu%’
// set cc for vpot ring
pp=pp+32
// scale it from 128 to 12 for vpot rings.
qq=uu*12
qq=qq/128
Hi Steve ,
First I seriously thank you for looking into this. I will try to adapt your approach and will report back. While your code is very nice for repeating V-Pots in a row, like emulating faders of a mixing console etc. I will need to add some stuff, so that it can work for my scenario too. Since i am trying to create a remote control for the A-Station, the Vpots are very often different next to each other, i.e. there are different value-ranges (and limits) for a Vpot row, going from 0-127, ±63, ±50, ±12 etc. and because of this, the LED rings use also different display setups i.e. wraped, boosted, centered etc.
Because i already covered all these scenarios for the incoming midi from the A-Station, i was only interested in the increment/decrement function of a Vpot. Still thank you for your code, it will help me tremendously to keep the project organized.
Read only if you are not bored : Why i am doing this? While the A-Station has plenty of knobs, that can be played and also recorded with, they are still not enough, when it comes to creation of a new patch. The Oscillator section for example covers only one Oscillator. If you want to change another Oscillator, you need to use a switch and then using the same knobs you used in the first place. This has the downside, that these knobs are not reflecting the actual values and you will likely getting ‘jumping’ values. The same is true for the LFOs and other parameters. Therefore a patch creation is a blind, walking wild in the jungle process. This is one of the main reasons, why i am doing a remote control with the C4. Here i can reflect all Oscillator states properly in one go or clearly seeing which LFO needs a little slowdown etc.
Hopefully this project will not be too complicated to realize. Once finished, i want to add other hardware from my setup, like a Roland alpha Juno for example. The final goal is to create a menue, where i can choose which synth i want to control and once i am done, going back to the menue and choose another synth etc.
Using a Bome box with the C4 means, i am not in a need of a PC to control my gear, which is a very big bonus here.
PS: I wish that we could have global variables, that have a letter and TWO digits, i.e. g15, g16 etc. This would make organizing 32 Vpots more easier and having pages organized a lot more easier.
At the end of the A-Station project, i am pretty sure that i will need to use more than 120 global variables to reflect a complete patch. Keeping track of them and what global variable is storing what, is currently a big challenge for me. The same is true, for creating the paging from the first 32Vpots to the next 32Vpots, to the next etc.
I agree and this is on our roadmap but not sure when it will be implemented. In the mean time I create a single translator and put rules in that translator that documents all global variables used.
Ohhh thats wonderful news. I liked the last update a lot. The new ‘Else’ and ‘Else if’ statements, the expanded global variables and the new action ‘Perform’, are very nice to have.
While we are at it, please, please consider adding these rapid tables as a floating window tool into your software:
Both tables helped me tremendously while working with Bome MTP and the rules window. The ASCII to hex table could have a Prefix option. The Prefix could be fed with different vendors for different displays. Most vendors will use the MCU protocol anyways, just with slight differencies.
Anyways, i just wanted to inform you, that your code is working. There is only one thing, that is not perfect regarding the LED rings: a value of zero or less than ‘one’ as a result (in the scaling process), will turn off the rings, which is something a user dont want to happen. And i am not sure if 12 is right here, because i only have 11 LED segments. Adding a limit again here, solves the problem. I mean this code here:
// scale it from 128 to 12 for vpot rings.
qq=uu*12
qq=qq/128
My first row of Vpots is working perfectly now (thanks to you ) and muscle memory is slowly coming back . Now doing the next rows (2nd, 3rd, 4th) brings a problem to me. It has to do with NRPN values and i wanted to ask you now, if it is better to open a new thread or to ask here for further help? Because the topic of this thread is solved and the problem is not really MTP related. It is mainly because i dont fully understand the A-Station NRPN midi implentation and how it works.
These are all good suggestions, I will forward them.
Hex to decimal.
If you type the value 0x10 in the rules, it will take that. Then the next time you open your project it will display 16.
For reverse calculation I generally use a downloaded hex calculator or in google chrome you could just enter something like this in the search bar ‘16 in hex’.
With a String to hex ascii to hex converter inside of MTP, you are not far away for having a ‘virtual’ display that emulates a MCU display for example.
But should i open a new thread regarding the NRPN problem?
,
) and muscle memory is slowly coming back 
.