DSP Robotics Support

Spogg wrote: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

I've thought about your comparison with a real world circuit. There is a difference, but you probably already know about it, thanks to trog: A trigger can cause back-triggers. For example, if your LED would rely on another input, then the incoming trigger would activate the LEDs programming, which would ask the other input for data by sending a back-trigger.
That's certainly a huge difference to the real world circuits.

Regarding your second paragraph: The secret to synchronizing is buffering. I give you an example of how DirectSound starts several audio tracks in sync. Each track is given an id, starting from 0. Then, starting from the highest ID, each track fills a buffer with its data and sets a variable to its ID. When the last track, the one with ID 0, has filled the buffer, the variable is set to 0. The next component, say an algorithm that sends the buffer to the audiocard, waits until this variable is 0, only then it sends the buffer to the audio card.
That is also the reason for audible crackles. It means that it took too long for all tracks to fill the buffer, since the audio card uses the next buffer, as soon as the previous one is played. If there is no next buffer, it plays silence. That's when you should either reduce the number of audiotracks or increase the size of the buffer.

I've done the same with the Ruby module: A draw call waits for all code executed in the draw method. All the things are drawn into a bitmap (that you are never aware of and have no access to) with the size of the associated view. Only when the draw method is finished, the now completed bitmap is drawn on the screen. So, the individual LEDs are still drawn one after the other, but because the draw call waits for a bitmap, we don't see the individual drawings of the LEDs, but the finished bitmap with all LEDs in it.

Example (0 = LED off, X = LED on)
View's current bitmap (this is displayed): [00000000]

draw method is invoked, builds a new bitmap:
[X]
[XX]
[XXX]
[XXXX]
[XXXXX]
[XXXXXX]
[XXXXXXX]
[XXXXXXXX]

this whole process above is hidden, the user still sees [00000000]
now that the drawing is done, the new bitmap is displayed: [XXXXXXXX]

the user thinks that all of the LEDs have switched in sync.

And this can be done in green as well

Well guys, I've spent all the afternoon/evening to read, traduce and understand the Spogg Trigger manual suggestion, and yeah, I've got few new things. But...

tulamide wrote:So let me point out: You may never rely on anything! Don't assume an order, in which events will be triggered. Don't try to force or prevent a redrawing. Don't try to do that 30 year old, static top to bottom executed code.

why did you said this? That's made me confused and out of the ride. I totally misunderstand your speak here. There is a "sort of order"! That's why the things works (even my example with Preset String).

Page 11, the author clearly says: "When the first 'no ticks' link gets a trigger, it has total control over the schematic until everything connected to that link has finished working – only then will the next link see the trigger."
This makes the sense for the Triggers. There is trigger order for chain. This means that its not possible that trigger out of this chain acts before the chain finish its works (inherit trigger included).

In this way, my example/image of asynch trigger from different place of schematic makes no sense.


Since the chain of the "master trigger" need to finish its works before a trigger from "another" place of the schematic act, it's is not possible that once trigger B starts (well, not really a trigger here; I mean the mem from schematic trigger Min/Max prim when I load it), trigger A run until 1/2/3/4 (which are in the chain of B) ends its works putting data to Ruby connector.

Please tell me I've got it!!! A simple "yes" would be enough, and I won't stress you anymore with triggers (which I quite understand now I hope; also the backwards/forward concept).

#hope

I don't think the outputs marked '1,2,3,4' should be considered separately. They are of the PRIM.

What happens after those outputs then depends on the circuit path from there.

The TROG documentation on TRIGGERS [along with the examples] offers all kinds of insights and strategies.

For me, it was NOT a fast read, but more a constant reference.

RJHollins wrote:I don't think the outputs marked '1,2,3,4' should be considered separately. They are of the PRIM.

What happens after those outputs then depends on the circuit path from there.

Not sure if I got correctly your words. With a more easy example:


here it's not possible that (when I change Float Start), Float E data get updated before all A/B/C/D Floats get updated. Can you confirm this? (and save my life )

Tronic wrote::|

Capture.PNG

Why that puzzled emoticon?
That's confirm my thoughts. So triggers have an order, run with some sequence logic, they are not all unrelated.
At this point, is it correct "exaggerate" and say that "triggers" runs individually? i.e. can't exist two triggers that run in parallel at the same fixed time/tick (even with two (or more) CPU core).

Nowhk wrote:That's confirm my thoughts. So triggers have an order, run with some sequence logic, they are not all unrelated.

True

Nowhk wrote:At this point, is it correct "exaggerate" and say that "triggers" runs individually? i.e. can't exist two triggers that run in parallel at the same fixed time/tick (even with two (or more) CPU core).

Yes and no...
FS is mono Thread application or better it is an evented system, every happen in an thread queue sequence fashion,
the only way to make concurrency trigger is to use the beta primitive Trigger Thread,
and it is unrelated with how many CPU core you have.

Nowhk wrote:

RJHollins wrote:I don't think the outputs marked '1,2,3,4' should be considered separately. They are of the PRIM.

What happens after those outputs then depends on the circuit path from there.

Not sure if I got correctly your words. With a more easy example:

Immagine.png

here it's not possible that (when I change Float Start), Float E data get updated before all A/B/C/D Floats get updated. Can you confirm this? (and save my life )

alright ... I'll take a stab at this. From my understanding/experience dealing with trigger ORDER [not so much TIMING, which I would say coding something THAT specific would be logically better handled/controlled in RUBY code] ...

From [START] -> trigger FIRST to A, then E [looking at the black marker coming off [START].

[A] triggers [B], then [D] ... then [C].

The UNKNOWN .... how FAST does the trigger pass from [START] to [FINISH].

I suppose a 'timing' analysis module [from one of the toolboxes] would provide a milli-second readout of that.

NEXT ... I believe what the GURU's here have tried to impress, is the overall construction of a schematic IMPACTS how this all works.

A small, isolated example MAY reveal a particular result ... but within the context of a specific schematic, with function and design that only the author sees/knows .. what can anyone say ... Your Mileage MAY very.

This may be viewed as a problem. It is nothing less then the 'timing jitter' we saw in early PC MIDI apps. The ATARI STe computer, with a dedicated MIDI communication port/architecture was specifically designed to do one thing ... handle MIDI data.

GREEN timing is loose ... we know this ... it will probably stay that way. [unless one wants to 'fix' the computer and OP system]. There are other methods, including with FlowStone. Coding with RUBY, or DSP. Care must be exercised in planting THOSE 2 elements into a GREEN environment.

This is my understanding. The gentlemen who have spoke about this here have much more experience/knowledge regarding this topic ... and more.

RJHollins wrote:From [START] -> trigger FIRST to A, then E [looking at the black marker coming off [START].

[A] triggers [B], then [D] ... then [C].

No man. Its not Start->A, START->E, A->B, A->D, B->C.
It's Start->A, A->B, B->C, A->D, Start->E. This remove the dubt I guess:


since I've removed Float E and link Start (tick 1) directly to the Indexer (which is still the last to be triggered).

RJHollins wrote:I suppose a 'timing' analysis module [from one of the toolboxes] would provide a milli-second readout of that.

I can't figure it out how to stamp the timing of Triggers in FlowStone. It seems that "time" function inside Ruby return the same time on each trigger (even if in fact the timing is different). Maybe "time" is scheduled at fixed clock and the value has a huge range where many triggers can happens in between?

From [START] you have 2 triggers.

The first path is to A

the second to E.