Render a View to a Bitmap - Some questions

[Nowhk]

When you trigger, the color in the "current background" must be the same of the one in the generated "Bitmap", but that's not always true (or maybe: its rare that the two are the same).

sure, when you are using 2 different random colors, they will not be the same...

They are not 2 different colors I choose one (random), I draw the V and I send the color as output (to monitor it). The color is one.

What I'm looking for is exactly the project posted above (except that I dont draw only a background, but 45000 points, which is expensive). Draw once, export as bitmap (what I just draw, no different things) and just stop to draw again (using the flag). Even if I store the array with points (without calcolate them every time), to draw that amount of points (at Tick100) freeze the application.

I'm programming since 18 years right now But 4 days for creare a bitmap is huge I guess. In C# it tooks 3 lines of code and five minutes to get it. Thats what I meant as hard task in FlowStone

[Nubeat7]

They are not 2 different colors I choose one (random), I draw the V and I send the color as output (to monitor it). The color is one.

2 colors!

2col.jpg (125.8 KiB) Viewed 14557 times

still don't understand what you exactly want to achieve, if you want that other people fix your problems you will need to share them...

btw. if it is that easy in c# why not doing it in c# than?

[Nowhk]

btw. if it is that easy in c# why not doing it in c# than?

There's not an audio developing are as FlowStone in C#, that's why I love FS and I use is

2 colors!

still don't understand what you exactly want to achieve, if you want that other people fix your problems you will need to share them...

You're right, I was tired! So ok, here's the whole example of what I'm trying to achieve (I'm sorry, I've saved the loaded sample inside the schematic; since forum allow file under 2mb, I had to upload to another file sharing platform):

Loading_2.zip

even if I save all points inside two variables (left/right; so it don't need to calculate points every where) and I resample the points to /10, using audio files over 3/4 seconds, the points to draw are too much. And the whole application is freeze.

I could resample more? Yes, but when I'll use file longer? It crashes, or I'll miss many points, falsing the waveform.
Or I could use envelope follower instead of all samples, but the graphics of the samples looks bad in shorter samples, and I'd like to print them all getting precise waveform And anyway, even if I got 200 points intead of 700.000, I have to draw path of them every time, adding additional CPU wasting time.

So the best is to keep all data (once) and made the bitmap. But I'm not able to do it... because trigger the Bitmap Create occurs in a non definible stack order and I don't know where to call it.

[Nubeat7]

this should do the job pretty well, maybe there is still more room for optimization,
just did this pretty fast in my spare time i have, so maybe you will find some bugs too..
its free resizeable and it works well with stereofiles, for mono files it would need some more to do.

[Nowhk]

this should do the job pretty well, maybe there is still more room for optimization,
just did this pretty fast in my spare time i have, so maybe you will find some bugs too..
its free resizeable and it works well with stereofiles, for mono files it would need some more to do.

But this doesn't make any Bitmap at all! I know how to get a decent Waveform with ENV and progressive cursor (fluid, not steppy), but I still want to avoid drawing lots of points at every redraw (which are many). Works good for 1/2 display. What about if I'd put 10 Sampler in my plugin? It can't hold up, alongside others feature I'll add. That's the point

[Nubeat7]

shouldn't be a problem because the drawing is reduced to minimal calculations and redraw rate, and every bitmap you create needs resources too, i would test it like this before.. it works pretty smooth and there is no freeze or any other problems with it..
afaik a bitmap also needs to be redrawn when anything on top of it is moving around, but i'm not sure about that, tulamide is the man for this..

btw. i'm pretty sure that 10 independent samplers will generate other problems than some redraws more or less..

[tulamide]

I wouldn't want to be involved here too much, but these are the things that come to my mind:

1) Yes, a bitmap is redrawn just as every other component in a view. If I'm not totally off, the technique used to draw bitmaps is faster then other drawing functionality, because bitblt is used. There is an advantage in just redrawing a bitmap compared to draw the individual elements.

2) There is no reason at all to use more points than can be drawn. Having a view of, say, 320 pixels in width means you can draw 320 pixel horizontally. Using 400,000 sample points to draw 320 pixels doesn't make sense at all. So, what would make sense? The easiest, of course, is to divide 400,000 by 320. The resulting 1250 would be the step you make through the audio file. You would draw every 1250th sample. Another technique would be to get the peaks. Instead of each 1250th sample you divde the audio file in blocks of 1250 samples and calculate the peak of each block. Peaks are relatively easy (=fast) to get through code.

3) You will never get an exact visual representation of the audio data, unless your view has exactly the same amount of pixels horizontally than sample points in the audio file.

4) To avoid too many drawing operations, you can use trigger limiting (there are quite a few examples to be found)

Conclusion: If you work with static audio data, it indeed is better to create a bitmap. But if the data changes often, go the runtime route with trigger limiting.

[RJHollins]

Don't know if useful, but Spogg just posted a 'SteadyScope'.
http://www.dsprobotics.com/support/viewtopic.php?f=3&t=3809&view=unread#unread
It seems to use some of the 'data reducing' concepts talked about.

[Nubeat7]

thanks tulamide for the explanation with the bitmap drawing,
about point 2, yes thats exactly what i did in the schematic, the waveresolution is fitted to the pixels of view-width
also redraws are reduced to a minimum and calculations happens only in green or outside the draw methode..

anyways, here is the bitmap capturing version..

all in all i think it will not be a big advantage to do it this way, after you need to keep all the wave creation code anyways, maybe if you really using more samplers, you can use just one waveformcreator for all samplers and just use the images for the individual views...

however hope it fits your needs..

[Nubeat7]

here is a slightly more optimized "direct draw version"

the graphics paths are also done in the coordinates methode now, so only called when updating the wavefile,
and only pure drawing in the draw methode.
The redraw rate for the playposition line is reduced to 50 ticks instead of 100, works pretty smooth , it should be close to the screenupdate rate from normally 60 hz..

also it just needs to redraw one layer instead of 2 when you draw on top of a bitmap..

some testings with your 10 samplers would be interesting if it makes any difference between bitmap or direct drawing..