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

lfo display caching #7901

Merged
merged 4 commits into from
Dec 4, 2024
Merged

Conversation

blancoberg
Copy link
Contributor

  • caches the lfo display
  • only redraws when parameters are changed, lfo switched or lua code is applied

addresses partially #7895

* caches the display to a bitmap
* only updates when parameters are changed or lua new code is applied
{
bool hasChanged = false;

if (paramsFromLastDrawCall[lfodata->delay.param_id_in_scene].i != lfodata->delay.val.i)
Copy link
Collaborator

@baconpaul baconpaul Dec 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to merge this, but the lfo data has params which are contiguous so you could also make this code

   auto *p = &lfodata->delay; // look in the definition of LFOStorage for which param is first
  while (p <= &lfodata->shape) // and last
   {
      if (paramsFromLastDrawCa[[p->paramid].i != p->val.i;
         hasChanged = true;
      ++p;
   }

We rely on this contiguity in several parts of the code so while it is not in general in C++ safe, in this instance i tis.

type thing. If you want to make this change now I can wait but I'm also happy to merge.

Thanks for doing this!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is much cleaner. I was looking for a way of doing that but Couldn't figure out how. I'll fix it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Not sure how to interpret the order here. Does this mean that rate is first and release last? Or is there some other list that sets the order of these?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rate is first and release is last yes.

@baconpaul
Copy link
Collaborator

Ahh I realized there's a few other places we invalidate from

  1. If transport beat count changes in a daw and we have the tempo synchon we paint the beats and that will need to invalidate on num/den and perhaps tempo change.
  2. MSEG edits update the display and I don't see that code here.

I haven't had a chance to run it to test but from a review I worry those would leave the display improperly uncached

@blancoberg
Copy link
Contributor Author

nope those are not included.
any hints on where I can catch those events?

* Repaints on tempo changed
* Repaints on MSEG editor change
@baconpaul baconpaul merged commit 1adcebf into surge-synthesizer:main Dec 4, 2024
13 checks passed
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

Successfully merging this pull request may close these issues.

2 participants