Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] support for NaN values #112

Open
vcaputo opened this issue Oct 8, 2023 · 0 comments
Open

[RFE] support for NaN values #112

vcaputo opened this issue Oct 8, 2023 · 0 comments

Comments

@vcaputo
Copy link
Contributor

vcaputo commented Oct 8, 2023

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant