Translate Channel values for a given profile.

The plugin doesn't know which profile it is in; Elgato doesn't give us that information.

Do you mean that the translation file itself should include some channel information and that you'd use different translation files for different profiles?

Yes. If there was a way of specifying the translation file being used from within a profile (some kind of global perhaps?) and providing a way for the translation file to modify channel information would be one idea.

So you mean, like, if there were some kind of script language where you could define global variables that other actions could use?  

But even with scripts, it would be impossible to solve this since the buttons don't know which profile they're in. The base information you want everything to be relative to doesn't exist.

I understand that the base information is not there. I was thinking something along the lines of: if there were to be an initialization button in a given profile that had a script that would init a global variable (@g_translationFile:"somefile") that would state what translation file to use and then the file itself would allow for channel mapping.

Another idea would be working with variables in CC actions. If a variable could be used in the {cc:##,###,###} event, I could change the channels based on a global variable assigned on a given profile.

jtints wrote:Another idea would be working with variables in CC actions. If a variable could be used in the {cc:##,###,###} event, I could change the channels based on a global variable assigned on a given profile.

Yes, you can do that.

I thought it was not possible, reading back to a previous exchange I had with you but it was for events and I was trying to use math directly in the cc event.

https://trevligaspel.forumotion.eu/t317-scripting-using-variables-and-math-in-ccs

so I could do something like this?

assign a global on button of each page on a given profile - lets say [(init) {@g_profile:2}], use it to calculate the channel number in local variable and then use that local variable in an action.

ah...as I am writing this I realize why I was interested in the translation files. The dials can't be scripted. 

Anyways. I appreciate you engaging with me on this. I am still trying to avoid manually changing hundreds of dial channels and trying to figure out how to build one profile and then use some method to modify channel number programmatically on other profiles.

Yes, you can do what you describe.

Dials could possibly be solved with background scripts, but I haven't looked into the details.

Just looking at BG scripts. This looks like it might be the ticket for me. 

Just so I understand this correctly: 

The BG scripts would receive midi information from a midi port  and then send to another mid port. For example: 

- the SD controller buttons and dials are set up with a midi out channel called sdSend and midi in channel called sdReceive

- the BG script receives midi in from SDsend, processes information and then sends the results to another midi port ... lets call it sdScriptSend. 
- conversely, there would be another BG script that would receive midi from my host environment from a port like sdScriptReceive and output to the Streamdeck on sdReceive.

If this is the case. Do the scripts run in the BG across profiles and devices or would one have a different bg script for each profile/device? I am using 3 devices, each has 4 different profiles. 

Do globals work with BG scripts?

Yes, you understand it correctly.

BG script receives on one port and sends to another port. Please note that the BG script action can create "internal ports" that are not available outside the plugin. The benefit is that you don't need to create "real" midi ports, and there is no risk that other programs will intercept and act on messages only meant for the BG scripts.

So, messages between buttons/dials and the BG scripts can be made on internal ports, while the messages between BG scripts and your daw are made on real midi ports.

BG scripts are always active across all profiles and pages, and the variable features are the same as for button scripts. There are some restrictions for BG scripts since they are not associated with a button, but you can read more about that in the doc.

Amazing. I think my plan would be to add a global flag to each button to let the script know what profile (I'm calling them tracks) the button is coming from and then do the the translation based on the profile flag.

This is super cool functionality!

I am working through the bg script here and have come up against a math issue. It seems I cannot add two variables together:

[(cc:*,*,*){@l_channel:#@e_ccchannel+@g_track#}]
[(cc:*,*,*){cc:#@l_channel#,#@e_cc#,#@e_ccvalue#}]
just returns the @e_ccchannel information.

if I do this:
[(cc:*,*,*){@l_channel:#@e_ccchannel+2#}]
[(cc:*,*,*){cc:#@l_channel#,#@e_cc#,#@e_ccvalue#}]
the addition works and it returns @e_ccchannel+2.

I could build this with a series of condition events like this (which works):

Code:

[(cc:*,*,*)(@g_track:1){@l_channel:#@e_ccchannel#}]
[(cc:*,*,*)(@g_track:2){@l_channel:#@e_ccchannel+1#}]
[(cc:*,*,*)(@g_track:3){@l_channel:#@e_ccchannel+2#}]
[(cc:*,*,*)(@g_track:4){@l_channel:#@e_ccchannel+3#}]
[(cc:*,*,*){cc:#@l_channel#,#@e_cc#,#@e_ccvalue#}]

but the math would be simpler.

Is there a way of adding variables together?

The additions work when I test. Are you sure @g_track has a value when the command is run?

Well it's working now. Classic.

Thanks for your feedback. This is all working well. I relabeled the global and for better clarity and put it all into one line.

Code:

[(cc:*,*,*){@l_channel:#@e_ccchannel+@g_trackOffset#}{cc:#@l_channel#,#@e_cc#,#@e_ccvalue#}]