Is DSP code run BEFORE ASM?

[Spogg]

Hi all

Is it a fact that DSP code is always run before ASM?

I remember having a simple ASM output going into a DSP box, with very critical timing (probably for granular stuff with a one-shot process, but I can’t recall exactly). The DSP code just wouldn’t respond to the ASM output. Eventually I realised the DSP code was being run before the ASM, so the ASM output wasn’t yet there when the DSP was evaluated. The solution was a 1 sample delay prim between ASM and DSP.

What I wonder is whether this is always the way, or was it down to my schematic in some way, like the order in which I added the modules or code…

Cheers

Spogg

[adamszabo]

I dont think it matters, its a matter of the order of connecting them up.

[tulamide]

I dont think it matters, its a matter of the order of connecting them up.

I'm actually not sure about this. We know that, when loading a schematic, Flowstone works its way through the schematic from the top layer in the order the elements were placed in the schematic to initialize them. I would assume that something similar happens in the execution loop (that also would explain the often needed backtriggers in green)

However, this would be confirmed or disproved easily in Rex's example, by removing the delay, cutting the dsp module, pasting it back in, connect it with the asm module and saving the schematic. After closing and re-loading the schematic, it should then work.

[adamszabo]

I guess one can easily check it with the signal analyzer and check the converted code. Even the dsp box will be converted to assembly at the end

[Spogg]

I’m inclined to agree that it’s probably an adding order thing, since a DSP box is also run as compiled assembler.

I came upon this a long time ago and forgot to mention it before.

I think it was inside my Harvester so I’ll see if I can find it, try what tulamide said and report back, maybe with a demo schematic if it seems to be a fixed and predictable behaviour.

Cheers

Spogg

[Spogg]

I tried to find the original schematic with the issue but failed.
Maybe I changed something else since I had the issue.

I also set up a test with an ASM random generator feeding a DSP which only evaluated when the channel opened, for the first sample pass only. Whichever sequence in which I added the two code boxes the system worked. I also tried embedding the DSP and ASM individually in child modules. In each case I saved then re-loaded the schematics.

So, unfortunately I can’t reproduce it. My thinking is there might be a sequence which will affect chained modules, where one output affects the result of the next module. But this may be wrong if all the module outputs are generated at the same time for the same sample, which kinda makes more sense.

The other thing is that I was almost certainly using 3.08.1 at the time, but I just tested with 3.06 so maybe there’s a difference in the software that might cause such a thing.

So let’s not go any further with this. I had the issue (for sure) so I’ll remain aware of the possibility and if it crops up again I’ll post here.

Cheers

Spogg

[wlangfor@uoguelph.ca]

Could you run a Boolean on both, rely on a tick to check the state and emit a timestamp unix style to be sure. The increment of that timestamp could be sufficient?

[Spogg]

Could you run a Boolean on both, rely on a tick to check the state and emit a timestamp unix style to be sure. The increment of that timestamp could be sufficient?

I don’t really understand your proposal, but since I’m unable to reproduce what I saw I can’t pursue this any further.
But thanks for joining in!

Cheers

Spogg

[wlangfor@uoguelph.ca]

Well, I'm meaning You could use one of those stream Boolean to Boolean converters. And then compare 2 timers that are initiated at the same time. Use a not Boolean prim to cease timer and then compare times.

[Spogg]

Well, I'm meaning You could use one of those stream Boolean to Boolean converters. And then compare 2 timers that are initiated at the same time. Use a not Boolean prim to cease timer and then compare times.

Well, if it ever happens again we can talk!

Maybe it was all just a bad dream.

Cheers

Spogg