--- doc/docbase/instrument_scripts/nksp/real_unit_final/01_nksp_real_unit_final.html 2019/09/17 17:37:51 3604 +++ doc/docbase/instrument_scripts/nksp/real_unit_final/01_nksp_real_unit_final.html 2019/09/17 19:44:02 3605 @@ -3,7 +3,7 @@
0.0
actually).
- Then there are functions, like e.g. the new functions sin()
, cos()
,
+ Then there are functions, like e.g. the new math functions sin()
, cos()
,
tan()
, sqrt()
, which only accept real numbers as arguments (and
always return a real number as result). Trying to pass integers will cause a parser error,
because those particular functions are not really useful on integers at all.
@@ -310,7 +311,7 @@
What about the other comparison operators like <
,
>
, <=
, >=
? Well,
- those other comparison operators all behave as with system level
+ those other comparison operators all behave like with system level
programming languages. So these comparison operators currently
do not take the mentioned floating point tolerances into
account and hence they behave differently than the =
@@ -430,7 +431,7 @@
- Having said that, these examples above were just meant as warm up scenarios.
+ Having said that, these examples above were just meant as warm up appetizer.
Of course you can do much more with this feature than just passing them
literally to some built-in function call as we did above so far.
You can assign them to variables, too, like:
@@ -523,6 +524,8 @@
$foo := 8ms
, but you must not change the variable ever to a different
unit type later on like $foo := 8Hz
. Trying to switch
the variable to a different unit type that way will cause a parser error.
+ Changing the fundamental unit type of a variable is not allowed, because it
+ would change the semantical meaning of the variable.
So getting back and proceed with an early example, this code would be fine: @@ -557,6 +560,8 @@
+ That's Ok because the built-in function change_vol()
+ optionally accepts the unit B
for its 2nd argument.
Whereas the following would immediately raise a parser error:
@@ -611,7 +616,8 @@
B
change_vol()
,
but rather a combination of that value and values of other modulation sources of volume
- like a constant volume factor stored with the instrument patch, as well as a continuously
+ like a constant gain setting stored with the instrument patch, as well as a continuously
changing value coming from an amplitude LFO
that you might be using in your instrument patch, and you might most certainly also use
an amplitude envelope generator which will also have its impact on the final volume of course.
- All these individual values are multiplied with each other in real-time by the sampler's engine core
+ All these individual volume values are multiplied with each other in real-time by the sampler's engine core
to eventually calculate the actual, final volume to be applied to the voices, like illustrated in the following
schematic figure.
@@ -865,7 +871,7 @@
whereas in use cases where you would always apply the
$volume
"finally" and probably need to pass it to several
change_vol()
function calls at several places in your script,
- then you might store the "finalness" directly to the variable instead.
+ then you might store the "finalness" information directly to the variable instead.
Unit Type | Relative | Final | Reason | +Unit Type | Relative | Final | Reason |
---|---|---|---|---|---|---|---|
None | @@ -988,7 +994,7 @@