Open lennart opened 9 years ago
lennart
commented
9 years ago @yaxu since you mentioned this, I did implement queue handling just as in dirt in eec783ece141468dca075166d616c034d26aab2a 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago @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
commented
8 years ago I did not notice any more timing errors, but will leave this open until more people have used it…
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.