Closed mpahrens closed 9 years ago
So the define to eval isn't really that laggy. It is probably the sonic pi <-> audio drivers that are laggy.
Any sense of how uniformly laggy it is? Both across and within units? Seems important for sync ability.
On Jul 21, 2015, at 5:22 PM, Matthew Ahrens notifications@github.com wrote:
So the define to eval isn't really that laggy. It is probably the sonic pi <-> audio drivers that are laggy.
— Reply to this email directly or view it on GitHub.
Nope, that is my dev goal for tomorrow morning. The I'll see how syncing goes and if they "all lag together"
So, since they "all lag together" (we syncronized 8 units today) I am going to close the bug version of this. But I think we should consider a low-latency alternative or investigation as further enhancement.
Very cool! Did you sync with the kids?
On Thu, Jul 23, 2015, at 07:27 PM, Matthew Ahrens wrote:
So, since they "all lag together" (we syncronized 8 units today) I am going to close the bug version of this. But I think we should consider a low-latency alternative or investigation as further enhancement.
— Reply to this email directly or view it on GitHub[1].
Links:
yep! all of the kids' units played in time with each other! it was pretty neat. I put up my fieldnotes for a complete rundown.
my running suspicion is it is because I am using the sonic pi macro "define" to make a named function and then making a named thread that calls that function. The original implementation was for multiple motifs to be cue-able at a time. But since only one motif is cueable at a time, we can simplify this by just spinning the thread, and not defining the function.
Why we still need the thread: loop / stop, and just piece of mind about code independence. We do not want the execution of a sonic-pi thread to block syncing beats or anything else.