How to store the Graphics::drawLine()

Hello,
somewhere on that forum, exactly here there Jules said:

I’d suggest looping along the X axis and calling Graphics::drawVerticalLine to render each pixel-wide vertical section - that’s how the library draws audio thumbnails

He said that in the context of Path and better CPU performance. But I wonder how to store those lines. When I have Path I can keep my wave form in it and and draw it any time I want and any where on the screen I want. But when I use paint(Graphics& g) to draw line from buffer data:

for(int i=1; i<bufferSize; i++)
    g.drawLine(axisX[i-1], audioBuffer[i-1], axisX[i], audioBuffer[i]);

But for the next audio buffer the one before will disappear.

That’s why I wonder how to store Graphics to be able to draw wave form for whole song.

Whole song has for example about 3:00 minutes, it’s 180 seconds and in each second I have 44100 samples. It’s really a lot of data for Path. But in the end it’s just simply curved line. So for the graphic point of view it’s not very complicated.

For example photo from telephone camera is much more complex. OK I know photo is rastered graph, and I probably need vector graph to be able to make some manipulation in the real time. But I don’t know how to deal with those issues.

Could anyone help? But please notice I don’t want to hard learn graphics theory. I just want to make some audio graph like waveform or freq analyser and probably will never do it again. I’ve heard about Open GL, but I am not sure what exactly it does and I am afraid to start with it, spend a lot of time for thing that in the future will be unnecessary for me.

Why don’t you look at how AudioThumbnail works?

Great thanks, I didn’t know about class like that :slight_smile:

It looks like I am not good in searching. I was looking in JUCE class list things like “wave”, “waveForm”. But never thought it could be thumbnail :slight_smile:

Thumbnails is something I that I thing about icon, some small picture, but why wave form?

Did you miss that line entirely when you read that post (and subsequently quoted it)?

Have you read any of these books? c++ faq - The Definitive C++ Book Guide and List - Stack Overflow A lot of your questions could be answered by yourself if you spend a little bit of time with some of those books and also spend some time just browsing and reading here: JUCE: Tags Pick a class title that captures your attention, and read the documentation. then see if you can find how its used in the JUCE demos.

1 Like

I think Jules talked about a different approach than what you have in mind. If I get you right your plan is to create some object (may it be a path or something different) out of the entire audio data you have and then use this to paint your waferorm.

Now this data might contain a lot more datapoints than what’s useful to be drawn on screen. Reducing those data to what‘s really gonna be drawn, interpolating and drawing lots of lines that are not strictly horizontal or vertical in the paint call is quite demanding to the CPU. So what Jules suggest is looping along the pixels you really want to fill on screen and then calculate which reduced subset of your audio samples you really need to draw the waveform. So your database while drawing is not a preprocessed graphic object but your raw samples

thanks for advice I will read them.

Thumbnail as in giving you an overview leaving out the detail. That is exactly what you need, if you want to display the whole 3 minutes on the screen. If you would draw on each pixel one sample, your display needs 8.64 millions pixels along one axis (3minutes * 60 secs/mins * 48000 samples / secs). That makes it obvious, why you need a scaled down representation of the wave to draw it in reasonable time. There is no point in scaling it down on the fly.

This technique is called “Level of Detail”, and doesn’t only apply for game developers, but all kind of visualisation.

Thanks for answer. But I can’t agree there is no point in scaling wave form. For example in Logic Pro you can zoom in wave form to see how it looks in exact milisecond. And it’s often very handy. At least for me.

The sentence continues “on the fly”. Sure it makes sense to scale it, but you need a low resolution version of your wave form in the memory, that you use to draw.

But Logic pro does not stay zoomed in all the time. When it is zoomed out, it is scaled. And most of the time it is zoomed out.