You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my use of Rocket I generally have autonomous driving of variables which are also exposed as rocket tracks. It's becoming increasingly apparent that I could use the ability to take over and surrender Rocket-control of the variables on a row by row basis.
For example, I might have something like a light source that in the code has some continuous functions like sin/cos combinations varying the orientation with time. But then at some point I'd like to override these values briefly to explicitly orient the light in time to the music, before again giving it back to the continuous built-in function. It'd be great if when sync_get_val() on a given track returned NaN I could let the continuous function take over.
As-is, this is at best achieved (AFAICT) by just reserving some magic numbers that work as such for the variables in question.
But floating point variables already have something special that all the code can just recognize without having to constantly reserve snowflake variables applicable to whatever is happening: NaN.
So what I'm envisioning is the row data would just have a NaN value and any such values are implicitly STEP interpolated with regard to their neighboring values, since they can't be interpolated. It's just the save/load routines that have to recognize something like "NaN" as the value instead of strictly floating point numbers.
Please correct me if I'm mistaken on this not already working, I just haven't seen a way to specify NaN values in emoon's RocketEditor and figured this hadn't been considered.
I'd also prefer if when a track has no rows present, sync_get_val() would return NaN instead of the 0 it currently returns. Which for my use would default to self-driven variables for unpopulated tracks... but if that's too breaking a change from current behavior, it's not the end of the world if getting NaN would require sticking at least a single row of NaN at the start of the pattern data...
The text was updated successfully, but these errors were encountered:
This is intended as much as an [RFC] as [RFE].
In my use of Rocket I generally have autonomous driving of variables which are also exposed as rocket tracks. It's becoming increasingly apparent that I could use the ability to take over and surrender Rocket-control of the variables on a row by row basis.
For example, I might have something like a light source that in the code has some continuous functions like sin/cos combinations varying the orientation with time. But then at some point I'd like to override these values briefly to explicitly orient the light in time to the music, before again giving it back to the continuous built-in function. It'd be great if when
sync_get_val()
on a given track returned NaN I could let the continuous function take over.As-is, this is at best achieved (AFAICT) by just reserving some magic numbers that work as such for the variables in question.
But floating point variables already have something special that all the code can just recognize without having to constantly reserve snowflake variables applicable to whatever is happening: NaN.
So what I'm envisioning is the row data would just have a NaN value and any such values are implicitly STEP interpolated with regard to their neighboring values, since they can't be interpolated. It's just the save/load routines that have to recognize something like "NaN" as the value instead of strictly floating point numbers.
Please correct me if I'm mistaken on this not already working, I just haven't seen a way to specify NaN values in emoon's RocketEditor and figured this hadn't been considered.
I'd also prefer if when a track has no rows present,
sync_get_val()
would return NaN instead of the 0 it currently returns. Which for my use would default to self-driven variables for unpopulated tracks... but if that's too breaking a change from current behavior, it's not the end of the world if getting NaN would require sticking at least a single row of NaN at the start of the pattern data...The text was updated successfully, but these errors were encountered: