DSP Robotics Support

I'm finally get able (more or less) to do what I'm looking for.

Well, I've a Ruby component that draw some graphic: in this case a rectangle with a random color; in my real plugin, it processes an array of 400.000 samples (or more) and draw the waveform (I'm loading a sample and display its waveform; with a Drumloop, the number of samples is big).

Since I've a redrawing 100 times at second, I've lots of operations coming out from that Ruby component, which freeze the whole application.

The only solution (for what I see) is to render the generated waveform display to Bitmap.

So I've made this module that (on event trigger) generate the View; then it triggers a "Bitmap Create" that (trought Sample & Hold) create it and store within the schematic:


Here's the schematic:


The problem I have now are these:

1 - Why when I trigger "Create Bitmap" the first time, it continuously trigger S&H? (watch at the Trigger counter I've inserted inside the module). It should trigger once, not continuously. Fixed; I've link the input trigger directly to S&H trigger and removed the one from Bitmap Create, so it trigger just once now (p.s. I've linked it as "second" order-position, so it first creates the bitmap, then store it).
2 - Why the generated bitmap position has an offset? It starts from grid 3,6. (Fixed; I've set X,Y=0 to the MGUI inside Display module)
3 - Why if I use "redraw 0" inside the event method of my Display module the whole application crash? (in fact I'd like to do the redraw when I click on trigger; not waiting the redraw invoked by the Redraw module and be "lucky").
4 - How can I make sure that "Create Bitmap" is called (and will finish its task to create the bitmap) after the Display module Draw its graphic and before the draw method loop again (which will draw nothing)? Because at the moment, the "double" trigger could generate an empty Bitmap (if I Create Bitmap after the draw method has been recalled). I'm not sure of this, but I think could happens (even if I didn't encounter this yet). Maybe "draws" events are executed following a stack? This will ensure that Create Bitmap will be executed before the Display module draw acts again, but I don't know! Flowstone is single process-thread (which will not introduce concurrency issues here)?

I hope you can help me! I'm improving myself on FlowStone day per day! Love it!!!
Thanks!

Here is one good example of background render that I collected over years...

BTW, sorry if I don't answer on your questions, I am very busy these days...

yep ... that ones' been in the toolbox. Works good.

Youlean wrote:Here is one good example of background render that I collected over years...

BTW, sorry if I don't answer on your questions, I am very busy these days...

Well, its exactly what I've done in my example, except that the link of V as "Bitmap Create target" is directly linked instead of wireless.

But the point 3/4 stays, and they are specific to learning something new in FlowStone.
For example here (I make it simple):


when I click on Trigger button, it changes the @do_draw variable in the Display module (linking order 1), but it doesn't any draw (since I don't call any draw method). In that moment I've an empty V.
Than it calls Bitmap Create (linking order 2), which should draw "nothing" since in the View there is "nothing". But in fact it draw a rectangle with a random color.

This means that draw method inside Display module is called in some way (by who?!?!) before that Bitmap Create. I don't think it's Redraw method inside the Render module at the top/right, since its being invoked after the bitmap is created (which should be empty, since the V was empty). In fact, if I remove it, I can still see the Bitmap created.

Do you see my dubt? I think I miss a point...

yea looks like it feeds the view connection with the generated rectangle but its not shown after you doesn't generate a redraw, which looks cool so you can call it on other place without to be drawn at the source...
interesting fact

btw maybe you like my stripmaker, with this tool you can render rubymade knobs into knobstrip images..
viewtopic.php?f=3&t=3283&p=17599&hilit=knobstrip#p17599

here is a snapshot tool i did a while ago..

Nubeat7 wrote:yea looks like it feeds the view connection with the generated rectangle but its not shown after you doesn't generate a redraw, which looks cool so you can call it on other place without to be drawn at the source...
interesting fact

btw maybe you like my stripmaker, with this tool you can render rubymade knobs into knobstrip images..
viewtopic.php?f=3&t=3283&p=17599&hilit=knobstrip#p17599

here is a snapshot tool i did a while ago..

Hi man, thanks for the reply. Watched to your schematic, which is similar to mine (and to what I've to do). But it still doesnt create the Bitmap after making the V and stop the redrawing (which cause CPU eating). Here I've edited your example:


1 - I click on Trigger;
2 - It creates a rectangle with random color (0,255,rand(255));
3 - It switches the "draw flag" to off (thanks to do_draw=false), so next redraws (which is at Tick100) do nothing (save calculations on CPU; on my real plugin I iterate 400.000 points);
4 - Once the V is drawn, it triggers your view snapshit Module (and should make the Bitmap);

but in fact does nothing Your trick of OFF/ON in the V Selector seems to save the "famous feed" between V and redraw 0, but I'm not able to get the Bitmap

Any ideas? It seems that when I trigger Bitmap Create, the draw method of my rectangle (re-called by Redraw @ Tick100) is executed before making the Bitmap itself (so, it creates an "empty" Bitmap).

In few words, I need a way to sync and stack these operations; so in order I make the V and I create the Bitmap before any redraw happens...

i have no idea why are you doing any redraws at the left part, it never gets drawn anyway because the drawrect methode is only active while creating the rectangle..

you set the do_draw flag to on (here the random rect is created) and the next operation is to set the flag to false, so it never gets the chance to be drawn ( or better to say the time window is too short that you can see it ) so with the ticker you just redrawing nothing all the time

to capture the view, the output trigger should also happen in the event methode

Nubeat7 wrote:i have no idea why are you doing any redraws at the left part, it never gets drawn anyway because the drawrect methode is only active while creating the rectangle..

Ok, maybe that's the point you misunderstand! It's normal, my english is pretty crap, and I ask sorry!
I'll try to explain me better (I hope). I've a V with two element: one that is static (thus, it's created when I click on a trigger and stay the same till I reclick the trigger; i.e. the rectangle I've posted above) and one part that is dynamic and need to be continuesly draw (somethings like an element that is changing during the time over it; that's is what I've tried to emulate with the Redraw method).

This example really make it simple to understand:


Background change at click and label is continuesly changing thanks to Redraw and Tick100. If you looks at the Float, you can clearly see the "Number of Times Background is drawn uselessly". This is the important part: because in my plugin I've expensive calculations inside the drawing, not just a background color .

You would say: why do you put the two element on the same V? Well, because if you look at the Top layer in the navigator, there I can move the single module with both elements!! It's fancy to move section of my plugin together.
That's why Redraw will work together the background (same View). And anyway: even if I've not Redraw, FlowStone itself call "often" redraw during the time inside the plugin, and these calling are unpredictable (i.e. the click of mouse over the working area). So I would to save CPU doing it once (more time is waste).

Nubeat7 wrote:you set the do_draw flag to on (here the random rect is created) and the next operation is to set the flag to false, so it never gets the chance to be drawn ( or better to say the time window is too short that you can see it ) so with the ticker you just redrawing nothing all the time

As I said, I want to draw it once due to the massive weight of operations. When the flag is on, I'll enter in the part of code where I draw the View. Of course, once entered, I set the flag to off again, because the next redraw (i.e. when Redraw trigger it, or when on FlowStone I click with mouse, or whenever guys call it) it needs to ignore the redrawing (because I've done it before; i.e. I want to save CPU for: the famous "NUmber of Times Background is drawn uselessly").

Nubeat7 wrote:to capture the view, the output trigger should also happen in the event methode

I've already tried this solution yesterday, but it "almost works". I say almost because it captures the Bitmap which strange artefacts. I guess trigger happens in between the previous draw and the next one, so most of the time the generated Bitmap is the previous selected color, before the new Trigger. This because (I guess) event and draw methods occurs at different times, so they would be triggered without any stack/sequence. You can see this here:


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

Damn I'm really not able to figure it out how to do this with FlowStone guys: it's 4 days I'm working on it...

sorry thats too confusing for me, maybe it would be better to share your original schematic so its much easier to understand and help with your issue...

often it is better to reduce the operations in the draw methode and write own methodes, the best is to do just the drawing in the draw methode and all the calculations somewhere else and just call them when they are needed...

btw. i'm very sorry for you that you already working on it 4!! days, hey, there will be problems which will need weeks or months to solve, welcome to the world of programming

Nowhk wrote: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...