How to properly use M1 ProMotion with Juce 7

[pajczur]

Hello,
actually I have bunch of questions related not only to M1 ProMotion, but at all to Hardware Synchronised Drawing.
I found out in Juce 7 “what’s new” there is some implementation of hardware synchronised drawing. But I can’t find more details about that. And I am even not sure if that new feature is something that I have any control over that or is it something in the depth of Juce repainting algorithm which is independent of me?

The main of my issues is concern to drawing audio wave form. At the moment I use juce::Timer started with startTimerHz(30) and inside timerCallback() I prepare path and call repaint().

But as Juce documentation says “The time interval isn’t guaranteed to be precise to any more than maybe 10-20ms”. And in addition repaint()“will not do any repainting immediately, but will mark the component as dirty”.

Those two facts are of course understandable but they cause my waveform is not repainted as smoothly as I wish.

I see in Juce AudioPlaybackDemo.h the waveform works in exactly the same way. I mean repaint() is called in timerCallback(), which is set to 40 Hz (I feel like for me it works better with 30 Hz).

But I still have hope that I can improve the smothness of my waveform repainting and I wonder if those new Juce 7 features can help me in that case. And how to do that?

For any advice greate thanks in advance.

Best Regards.

[PluginPenguin]

@pajczur

I found out in Juce 7 “what’s new” there is some implementation of hardware synchronised drawing. But I can’t find more details about that. And I am even not sure if that new feature is something that I have any control over that or is it something in the depth of Juce repainting algorithm which is independent of me?

I guess this refers to the new VBlankAttachment class?

[sudara]

I believe hardware sync / animation stuff is currently in development but this might help:

FR: Callback or other mechanism for exposing Component debugging/timing

You’re right, it’s called at every VBLank event, and it’s main use case is to update the Component’s state in lockstep with the screen refresh and have smooth animations that way. So you’d actually call repaint() from inside a VBlank callback when necessary. The Component relationship is indeed for deciding which peer to attach to. I can see now that it’s not exactly useful for your use case, because it doesn’t in any way line up with the paint times of one particular Component. In fact first …

My experience is animations generally look best at 60fps unless your paint calls are too slow…

[pajczur]

Hey.
Thanks for reply. I’ve already tested VBlankAttachment class, and it’s really great.

But as I found on other thread there is lack of information about exact refreshing interval. It seems reasonable becaous as I’ve heard in example on new Macbooks the refreshing interval can change in dependency of current graphics/animation to display.

But due to that fact I still have problem with drawing audio wave form played by host. Because I can’t synchronise my drawing reading head with writing head (by head I mean some int index which read buffer in cycle).

Of course I can use exactly the same int variable to write and read, and then it works perfectly. But in that case the problem is that many host stop calling processBlock when host’s playhead is stopped. And I move write head in processBlock. So when it stops then my waveform also stops and looks like it is frozen.

So I am still looking how to solve that.

But in all other cases in my projects, the VBlankAttachment is really great.