So I'm working on a modified MIDI Fighter Twister mapping where if you press the encoder it either kills (0) or resets a STEM (0.5)
($enc_buffer is set to 0.03, the idea is that if you have the stem low you probably don't want it to go lower but reset to normal. enc_buffer determins how close to low you can be)
My issue is that when I run this action it works for going from no stem (0) to full, but not in reverse
Relevant code parts:
Interestingly, what does work is this:
The only difference I can tell is the addition of the variable in the second. I'm sure I'm doing something wrong I just don't see it
($enc_buffer is set to 0.03, the idea is that if you have the stem low you probably don't want it to go lower but reset to normal. enc_buffer determins how close to low you can be)
My issue is that when I run this action it works for going from no stem (0) to full, but not in reverse
Relevant code parts:
<map value="MD1_ENC_1_1" action="deck 3 stem Vocal " />
<map value="MD1_PUSH_1_1" action="var_smaller `deck 3 stem Vocal` $enc_buffer ? deck 3 stem Vocal 0.5 : deck 3 stem Vocal 0 "/>
Interestingly, what does work is this:
<map value="MD1_ENC_1_1" action="deck 3 stem Vocal & set_var $md1_1_1 `deck 3 stem Vocal ` " />
<map value="MD1_PUSH_1_1" action=" var_smaller $md1_1_1 $enc_buffer ? deck 3 stem Vocal 0.5 & set_var $md1_1_1 0.5 : deck 3 stem Vocal 0 & set_var $md1_1_1 0 "/>
The only difference I can tell is the addition of the variable in the second. I'm sure I'm doing something wrong I just don't see it
geposted Mon 02 Feb 26 @ 9:25 pm
you have params wrong way round for the verb, valid version
var_smaller VARNAME `ACTION`
var_smaller `ACTION` `ACTION`
var_smaller VARNAME `ACTION`
var_smaller `ACTION` `ACTION`
geposted Mon 02 Feb 26 @ 11:47 pm
locoDog wrote :
you have params wrong way round for the verb, valid version
var_smaller VARNAME `ACTION`
var_smaller `ACTION` `ACTION`
var_smaller VARNAME `ACTION`
var_smaller `ACTION` `ACTION`
So for my example, i would need to to this: (?)
<map value="MD1_PUSH_1_1" action="var_smaller $enc_buffer `deck 3 stem Vocal` ? deck 3 stem Vocal 0.5 : deck 3 stem Vocal 0 "/>
That did not work.
This also did not work:
<map value="MD1_PUSH_1_1" action="var_smaller `$enc_buffer` `deck 3 stem Vocal` ? deck 3 stem Vocal 0.5 : deck 3 stem Vocal 0 "/>
geposted Tue 03 Feb 26 @ 12:20 am
Your replies are the wrong way round.
var_smaller $enc_buffer `deck 3 stem Vocal` ? deck 3 stem Vocal 0.0 : deck 3 stem Vocal 0.5
deck 3 var_smaller $enc_buffer `stem Vocal` ? stem Vocal 0.0 : stem Vocal 0.5
Also a good habit is use 0.0 for zero, this case it doesn't matter but there are some cases when it does, and it can be hard to spot the error, so best to use it, if it's a float then write X.Y then the script engine can't misunderstand it as an integer.
var_smaller $enc_buffer `deck 3 stem Vocal` ? deck 3 stem Vocal 0.0 : deck 3 stem Vocal 0.5
deck 3 var_smaller $enc_buffer `stem Vocal` ? stem Vocal 0.0 : stem Vocal 0.5
Also a good habit is use 0.0 for zero, this case it doesn't matter but there are some cases when it does, and it can be hard to spot the error, so best to use it, if it's a float then write X.Y then the script engine can't misunderstand it as an integer.
geposted Tue 03 Feb 26 @ 1:49 am
I see many extra spaces in your code. Not sure where or when it matters, but it can cause problems.
geposted Tue 03 Feb 26 @ 3:37 am
Thanks Locodog, your advice helped.
I find it unexpected that the following work:
var_smaller VARNAME `ACTION`
var_smaller `ACTION` `ACTION`
but this does not:
var_smaller `ACTION` VARNAME
Anyways, thanks again for the help!
I find it unexpected that the following work:
var_smaller VARNAME `ACTION`
var_smaller `ACTION` `ACTION`
but this does not:
var_smaller `ACTION` VARNAME
Anyways, thanks again for the help!
geposted Tue 03 Feb 26 @ 8:49 pm
It's how the script engine is wrote at the programming level, there is no interpretation by the machine. Everything it does is because the programmer told it to act that way when it sees params in an order, and it's surprising how many ways they included.
When designed, the verb[function call] was only told "if you see 'var_smaller VARNAME DIGIT', check if value held under the name VARNAME is smaller than the DIGIT"
later the devs designed a separate bit of code, a variation of the verb [a function overload] that was told "if you see 'var_smaller VARNAME `SCRIPTACTION`', first figure out what SCRIPTACTION equals, then check if value held under the name VARNAME is smaller than it"
If the machine is sent a script that doesn't match an order it knows then it just doesn't understand it and it just says no.
Computers aren't smart, just fast and obedient to what the programmer wrote, smart programmers [which we have] write overloads to keep the command dictionary small for the user yet keep it flexible, but for them to anticipate just any old order a user might input would take a lot of time, and it would be a pig to change every variation if a change was ever needed.
At that point it's easier for user to just ask, there's no shortage of help on the forum so long as you show learning and don't treat people like GPT.
When designed, the verb[function call] was only told "if you see 'var_smaller VARNAME DIGIT', check if value held under the name VARNAME is smaller than the DIGIT"
later the devs designed a separate bit of code, a variation of the verb [a function overload] that was told "if you see 'var_smaller VARNAME `SCRIPTACTION`', first figure out what SCRIPTACTION equals, then check if value held under the name VARNAME is smaller than it"
If the machine is sent a script that doesn't match an order it knows then it just doesn't understand it and it just says no.
Computers aren't smart, just fast and obedient to what the programmer wrote, smart programmers [which we have] write overloads to keep the command dictionary small for the user yet keep it flexible, but for them to anticipate just any old order a user might input would take a lot of time, and it would be a pig to change every variation if a change was ever needed.
At that point it's easier for user to just ask, there's no shortage of help on the forum so long as you show learning and don't treat people like GPT.
geposted Tue 03 Feb 26 @ 10:46 pm
locoDog wrote :
there's no shortage of help on the forum so long as you show learning and don't treat people like GPT.
there's no shortage of help on the forum so long as you show learning and don't treat people like GPT.
yup, exactly why i posted and got a super fast and detailed reply.
I also fully understand the programming decisions.
However, that said, being that sensitive to order of parameters in an opertation is still very unexpected.
geposted Thu 05 Feb 26 @ 3:24 am
docb-dj wrote :
However, that said, being that sensitive to order of parameters in an opertation is still very unexpected.
However, that said, being that sensitive to order of parameters in an opertation is still very unexpected.
Remember, this is a DJ software, not a scripting tool :P
I mean for the most part VirtualDJ has a simple script language to aid the average DJ user to achieve more complex tasks.
The word average is the key here.
DJ's are not expected to be programmers. Therefore the scripting language has to be simple.
That being said, some scripts due to "popular demand" have become more complex than initially expected.
Variables comparison is one of them.
Initially it was var_compare 'VARIABLE' NUMBER
But then users asked to also be able to get the number via script
So var_compare 'VARIABLE' `SCRIPT` was introduced.
And later down the road, variables could hold text as well, not only numbers..
PS: The "correct" way to compare two scripts is param_compare param_bigger, param_smaller and param_equal
geposted Thu 05 Feb 26 @ 10:17 am
For what I'm trying to do (compare if a variable set on initialtion is equal or lower to a deck setting and if so do X, else do Y) what would the proper way of doing the compare?
geposted Thu 05 Feb 26 @ 10:01 pm





