Timing inaccuraries

[lennart]

Currently timing seems to be not quite right.

Scheduling of rendering shaders could be done just as dirt does, or completely disregard timing information and change weltfrieden to not expect timestamps.

[lennart]

@yaxu since you mentioned this, I did implement queue handling just as in dirt in eec783e this should schedule all messages appropriately, though I haven't tested this throroughly.

Did you already test this version (I just pushed this yesterday evening)? If so, I am wondering why it still fails to be on time.

[yaxu]

Yes I am up to date with the latest code and did make clean / make.

Reduce the cps and you'll see that in effect everything is quantised to a resolution of one eighth of a cycle.. So I guess this is a bug somewhere with the scheduling.

[lennart]

Thanks for the investigation, I'll have to take a good look at the scheduling code, especially regarding the order of shader layers rendered.

On Oct 12, 2015, at 12:05 PM, Alex McLean notifications@github.com wrote:

Yes I am up to date with the latest code and did make clean / make.

Reduce the cps and you'll see that in effect everything is quantised to a resolution of one eighth of a cycle.. So I guess this is a bug somewhere with the scheduling.

�
Reply to this email directly or view it on GitHub.

[lennart]

@yaxu I found the bug and (hopefully) have fixed it. I have been assigning the globaltime to ->when whenever a message has been received. now it's using the supplied values as scheduled by tidal.

this looks more in sync now.

however layering seems to be still not quite right (please test vowel params a lot, since this might help seeing multiple layers above another, as not all have alpha values below 1)

[lennart]

I did not notice any more timing errors, but will leave this open until more people have used it…