Nicotux
look like param_add does not receive parameter anymore
once upon a time it was simple:
get_var a & param_multiply 6 & param_add 'get_var b'
or alternatively after things started to go bad
param_add "param_multiply 'get_var a' 6" 'get_var b'
they now return wrong result 6 or 0
get_var a & param_multiply 6 & param_cast & param_add 'get_var b'
does not help because param_multiply is working as needed
then alternative works again with additional cast
param_add "param_multiply 'get_var a' 6" 'get_var b' & param_cast
but needs an alternative to be used as a text entry between quotes
param_add `param_multiply 'get_var a' 6` 'get_var b' & param_cast
And now as an action between backquote i.e. in get_text it's impossible to define anymore
once upon a time it was simple:
get_var a & param_multiply 6 & param_add 'get_var b'
or alternatively after things started to go bad
param_add "param_multiply 'get_var a' 6" 'get_var b'
they now return wrong result 6 or 0
get_var a & param_multiply 6 & param_cast & param_add 'get_var b'
does not help because param_multiply is working as needed
then alternative works again with additional cast
param_add "param_multiply 'get_var a' 6" 'get_var b' & param_cast
but needs an alternative to be used as a text entry between quotes
param_add `param_multiply 'get_var a' 6` 'get_var b' & param_cast
And now as an action between backquote i.e. in get_text it's impossible to define anymore
Posted Wed 21 Apr 21 @ 1:10 am
locoDog
you're on to a problem here, I really struggled with something with something similar but forgot to report it.
Posted Wed 21 Apr 21 @ 8:16 pm
Adion
param_add "param_multiply 'get_var a' 6" 'get_var b'
works fine on a custom button here.
(with a and b set using "set a 1" and "set b 6")
There is no 'once upon a time' for
get_var a & param_multiply 6 & param_add 'get_var b'
Using param_add with actions instead of values only ever worked when 2 parameters are specified. With a single parameter it never supported actions.
works fine on a custom button here.
(with a and b set using "set a 1" and "set b 6")
There is no 'once upon a time' for
get_var a & param_multiply 6 & param_add 'get_var b'
Using param_add with actions instead of values only ever worked when 2 parameters are specified. With a single parameter it never supported actions.
Posted Tue 27 Apr 21 @ 8:26 am
locoDog
something has changed though, I think 6372 changes broke something.
hard to say exactly what, but one thing I was working on with more advanced script.
something like using param_add as an action/param for/inside a param_multiply
I had to use intermediate vars to get it to work, kind of thing I could think up, but this time I had to work & test a lot harder.
I also found,
set var `number wrangling with get_ , multiply etc etc`
becoming harder, sometimes impossible as to what I know worked
just done a quick check with my calculator padpage [which worked @ release] and now it has errors
http://www.virtualdj.com/user/locodog/blogs/5715/mathsRef_xml.html
divide being one, suspicion on dividing a int = float is broken [likely other things]
this used to work
I think it might be an idea, to have a dev built calculator padpage as an error check, I know this level of scripting is niche, but arithmetic needs to work.
and to be honest it's easier & better to have a dev padpage & script; press pad, result is expected ? type of error check as opposed to users testing 1 in 100 scripts
also this used to work, minus, bad way to do it, but it worked
now I get a wrong answer
I feel I've let the side down, a while back I noticed slid3r padpage partially broke, and didn't mention it but honestly figuring out; wait & reverse was a nightmare,
and how do you explain it, other than "use the build this page with the same release date [circa 5046]", than "try it with a new build" [not sure when it broke]
hard to say exactly what, but one thing I was working on with more advanced script.
something like using param_add as an action/param for/inside a param_multiply
I had to use intermediate vars to get it to work, kind of thing I could think up, but this time I had to work & test a lot harder.
I also found,
set var `number wrangling with get_ , multiply etc etc`
becoming harder, sometimes impossible as to what I know worked
just done a quick check with my calculator padpage [which worked @ release] and now it has errors
http://www.virtualdj.com/user/locodog/blogs/5715/mathsRef_xml.html
divide being one, suspicion on dividing a int = float is broken [likely other things]
this used to work
set 'var1' 5 & set 'var2' 4 & get_var 'var1' & param_1_x & set "var1/x" & param_multiply "get_var 'var1/x'" "get_var 'var2'" & param_cast & set 'var3'
I think it might be an idea, to have a dev built calculator padpage as an error check, I know this level of scripting is niche, but arithmetic needs to work.
and to be honest it's easier & better to have a dev padpage & script; press pad, result is expected ? type of error check as opposed to users testing 1 in 100 scripts
also this used to work, minus, bad way to do it, but it worked
now I get a wrong answer
set 'var1' 5 & set 'var2' 4 & get_var 'var1' & param_invert & set '1-var1' & param_add "get_var '1-var1'" -1 & param_cast & set '-var1' & param_add "get_var '-var1'" "get_var 'var2'" & param_cast & set 'var3'
I feel I've let the side down, a while back I noticed slid3r padpage partially broke, and didn't mention it but honestly figuring out; wait & reverse was a nightmare,
and how do you explain it, other than "use the build this page with the same release date [circa 5046]", than "try it with a new build" [not sure when it broke]
Posted Tue 27 Apr 21 @ 6:11 pm
Adion
Will have a further look, but it seems param_1_x when used on an int always returned an int as result as well. (Did a quick look and this hasn't changed since at least 3957 from 2017)
What did change and what probably affects this and similar scripts is that variables now have a type as well, whereas before they could only be float. So "set 'var1' 5" used to implicitly convert and store as float 5.0, where it is now stored as an integer 5.
I think it might make sense to have param_1_x convert to float in this case though, would have to check if there's a chance this breaks current uses though...
For param_invert it appears to be a similar problem, but with a different reason.
param_invert when used on a float returns (1-x), as can be used with sliders/knobs.
param_invert when used on a int returns -x, since it was expected to be used on endless rotaries for example, where +1/-1 would be expected.
It was originally constructed with controllers in mind, where writing it would be natural, but it indeed breaks down when scripts can use different types of variables.
What did change and what probably affects this and similar scripts is that variables now have a type as well, whereas before they could only be float. So "set 'var1' 5" used to implicitly convert and store as float 5.0, where it is now stored as an integer 5.
I think it might make sense to have param_1_x convert to float in this case though, would have to check if there's a chance this breaks current uses though...
For param_invert it appears to be a similar problem, but with a different reason.
param_invert when used on a float returns (1-x), as can be used with sliders/knobs.
param_invert when used on a int returns -x, since it was expected to be used on endless rotaries for example, where +1/-1 would be expected.
It was originally constructed with controllers in mind, where writing it would be natural, but it indeed breaks down when scripts can use different types of variables.
Posted Tue 27 Apr 21 @ 7:27 pm
locoDog
thanks for checking, I can confirm everything in my calculator pad page worked as of
17 Jul 18 [publish date]
I might rewrite it to be more centred of error check instead of "how to guide" as it was written initially.
17 Jul 18 [publish date]
I might rewrite it to be more centred of error check instead of "how to guide" as it was written initially.
Posted Wed 28 Apr 21 @ 1:42 am
Nicotux
thanks both to take interest to this
if restore param_1_x and param_invert back to float breaks current uses... with controllers
maybe it would be simpler to add some new math verbs such as param_sub, param_sum, param_div.... with action and auto cast ;)
As the doc specify :
"If you have a macro with several commands, each commands will have the implicit parameter added."
There is mostly no usable implicit parameter anymore as return values mostly need cast (i.e.: constant) or became a boolean status or unchanged initial parameter
Not only issues but some benefit either : "& &" seems to now remove any "Implicit parameter" from the script chain giving "No Parameter" making it possible now to use actions such as "effect_select" without parameter in scripts
"set" changed again in b6418 (as a fix)
- now returns nothing (and parameter is not relative anymore when negative) but some scripts used to use the result that is now unavailable even with a cast
- negative var is affected to destination var (not added anymore)
- but still no easy way to deal with negative values and variable
constant -2 & param_cast_absolute & set v & debug
v becomes 1 and "no param" ^^
constant -2 & param_cast & param_cast_absolute & debug
Int -2 (relative) ^^
constant -2 & param_cast & param_cast_absolute & set v & debug
decreases v by 2 and Int -2 (relative) ^^
constant -2 & param_cast & param_cast_absolute & set v & param_cast & debug
decreases v by 2 and Bool: 0 ^^
in fact there were tiny changes with many implications and (un)predictable implications
@locodog: if calculator pad page refers to your MATHREFS
was working ... as far as vars were positive values
(maybe issues with relative auto cast with set and param_add came after 17 Jul 18 though)
if restore param_1_x and param_invert back to float breaks current uses... with controllers
maybe it would be simpler to add some new math verbs such as param_sub, param_sum, param_div.... with action and auto cast ;)
As the doc specify :
"If you have a macro with several commands, each commands will have the implicit parameter added."
There is mostly no usable implicit parameter anymore as return values mostly need cast (i.e.: constant) or became a boolean status or unchanged initial parameter
Not only issues but some benefit either : "& &" seems to now remove any "Implicit parameter" from the script chain giving "No Parameter" making it possible now to use actions such as "effect_select" without parameter in scripts
"set" changed again in b6418 (as a fix)
- now returns nothing (and parameter is not relative anymore when negative) but some scripts used to use the result that is now unavailable even with a cast
- negative var is affected to destination var (not added anymore)
- but still no easy way to deal with negative values and variable
constant -2 & param_cast_absolute & set v & debug
v becomes 1 and "no param" ^^
constant -2 & param_cast & param_cast_absolute & debug
Int -2 (relative) ^^
constant -2 & param_cast & param_cast_absolute & set v & debug
decreases v by 2 and Int -2 (relative) ^^
constant -2 & param_cast & param_cast_absolute & set v & param_cast & debug
decreases v by 2 and Bool: 0 ^^
in fact there were tiny changes with many implications and (un)predictable implications
@locodog: if calculator pad page refers to your MATHREFS
was working ... as far as vars were positive values
(maybe issues with relative auto cast with set and param_add came after 17 Jul 18 though)
Posted Wed 28 Apr 21 @ 3:29 am
locoDog
I've just remembered what I was doing that I found much more difficult.
I was trying to append a tag with both a history folder name [to grab the date] and also add a string.
I was trying to append a tag with both a history folder name [to grab the date] and also add a string.
Posted Wed 28 Apr 21 @ 12:46 pm
Adion
@nicotux: To cast to absolute, it is "param_cast absolute", there is no "param_cast_absolute"
With that change your examples seem to work fine here.
With that change your examples seem to work fine here.
Posted Wed 28 Apr 21 @ 2:28 pm
Nicotux
didn't notice the underscore
yes that is what was fixed
yes that is what was fixed
Posted Wed 28 Apr 21 @ 5:05 pm