Render a View to a Bitmap - Some questions

[Spogg]

I've just knocked up this experimental schematic out of my own interest and to demo just what tricky blighters triggers can be.
I personally have a tough time with this because I still think in electronics terms rather than program execution. The hard fact I try to keep hold of is that nothing can occur in a program at the exact same moment (CPU cores aside). It has to happen sequentially and the order for triggers in Flowstone is less than intuitive shall we say.

I've put some comments on the schematic.

Cheers

Spogg

[Tronic]

Hi Spogg,
There are some things to consider:
1. that the trigger delay is a windows timer, then by nature imprecise and unreliable,
so having only a trig generator status [on / off] to give the various LEDs
2. for displaying a simultaneous ignition behavior of all the LEDs,
they should be grouped in a single view and have only one redraw,
this would work regardless of the order of trig.

This way you should have a simultaneous ignition behavior of all the LEDs,

[tulamide]

I was about to say the exact same two things.

I really don't see any unexpected behaviour. Flowstone does exactly what you told it to do (send a trigger to the first view, then a trigger to the second view, etc.). If you want something to draw at the same time, you trigger it once, just like Tronic said, and draw all of them at once.

[Spogg]

Hi guys

By "unexpected" I was referring to the electronic equivalent where all real-world LEDS would trigger from one pulse. I do realise this isn't the case with FS so my demo was actually to show this "unexpected" behaviour

However, I was intrigued to see if I could get all the LEDS to operate simultaneously and for the same time period.

The FSMs below illustrate an issue with this, or maybe I didn't do it right.

I put all the LEDS in a module and the behaviour was still "unexpected" (but a bit different).
Then I put in a MGUI with triggered re-draw and, whilst better regarding ON sync, the extinguish time is unpredicatble as is the ON time.

My hope is that this illustrates that trigger operation is counter-intuitive and, it could be said, difficult to predict at the design stage.
Also it would be interesting for me (and others?) to see how the goal could be achieved and what would be involved.

Cheers

Spogg

[tulamide]

By "unexpected" I was referring to the electronic equivalent where all real-world LEDS would trigger from one pulse. I do realise this isn't the case with FS so my demo was actually to show this "unexpected" behaviour

And we were trying to tell you, that you didn't trigger from one pulse. You created dozens of pulses to trigger each individual LED, and real world LEDs would behave the very same way then

So, to make things clearer: Is it possible to have some action happen to several things at the same time in Flowstone? Sure! Does it work, when I chain those things serial instead of parallel? Surely not!

In the two schematics, you still don't use one pulse/trigger. You just hide the triggers underneath another view. Still, the LEDs are each in their own view, instead of directly drawn into the same one. And still you use a windows timer (from which the manual explicitly says that it is unreliable!). So, the timing issues are the following:

1. Since you send one trigger after the other, one for each of the LEDs, every next LED gets notified later than the one before.
2. Since you use a windows timer you aren't guaranteed neither a start time nor a duration.

I don't really see where it is counter-intuitive? It still does exactly what you tell it to do.

I don't have the time to build a view in green that draws a dozen LEDs, so I made it with Ruby (which takes about 3 minutes). You will notice exact timing (unless the drawing takes more time than the duration of the timer) and parallel reaction from 121 LEDs drawn into one view. (Note the little editing of the file name )

[Spogg]

Many thanks for doing that tulamide.

I actually think we are in agreement

A "single" trigger source, like the stock trigger button, does not generate a single trigger but one in turn for all the items connected to it, depending on the connection order (as in Trog's tutorial). Plus we know that the Windows timer system is not accurate but Ruby runs at a steady 100Hz (as I understand it).

What is not complete in my understanding is that you suggest it might be possible to do this sync'ed thing in Green, if you had the time to demo it. Please don't spend any more of your valuable time on this, but I am intrigued by the idea that we could make lots of stuff happen simultaneously and in sync from just one trigger source and in green.

Cheers

Spogg

[Nubeat7]

Preset String load the S from preset after the "After Load" (so when I load the VST, it will never refresh to the new value from preset, but always the one from schematic).

thats not true, because you said by yourself that preset gets triggered after afterload, which is true, so it loads the (last saved) preset ..
if it is like you described, then something in the wavedrawing part is triggered wrong (before it gets loaded completely)

we also don't know your actual schematic, just few pics from small parts which tell us not a lot, if it loads wrong you need to change something, but without knowing the schematic and the real position of the problem, its difficult to say where you should have a look at...

[Nowhk]

thats not true, because you said by yourself that preset gets triggered after afterload, which is true, so it loads the (last saved) preset ..
if it is like you described, then something in the wavedrawing part is triggered wrong (before it gets loaded completely)

Honestly I didn't see something wrong happens with the actual schematic I have: it's the same you have posted, just with Preset String before WaveFile prim. i.e. I never got wrong results in drawing yet.

But this doesn't mean "I'm ok, it will never happens", since you have teach to me that triggers are totally indipendent, and act without any sequence!

It just could happens. Following this logic/mechanism, the scenario I've posted on this image can happen: viewtopic.php?f=2&t=3949&start=40#p22370

where 4-5-6-7-8 act before Min/Max value trigger the next Left/Right min values to Ruby.

Is it right? Or am I wrong with this asserting?
If I'm wrong (might be; I'm not here to say "I'm right" and "you are wrong, stupid"), there is somethings more to learn about Triggers that I miss (even if I've read the Spogg manual, which says nothing more than what I've learnt from you).

If I'm not wrong, it's a situation that can happen, and honestly I really don't know how to fix it, and maybe I have to surrender to the fact it could draw a wrong Wave (even with a very low probability).

[Nubeat7]

i.e. I never got wrong results in drawing yet.

But this doesn't mean "I'm ok, it will never happens", since you have teach to me that triggers are totally indipendent, and act without any sequence!

much luck.. i'm out!

[Nowhk]

i'm out!

Only because I've asked if this can happen? Is it not a licit concern?