Jamie,
I went over this again with Marije (Nescivi) over Skype just now as I had
some trouble understanding it still.
There are two issues for this for ChucK as I see it right now.
First of all ChucK doesn't yet support timestamps for OSC messages. Most
ChucK people seem to get by but here this is a bit of a deal-breaker as I
currently understand it. Ok, a big deal-breaker :¬)
Secondly the specs. I mostly looked at /docs/spec.txt as I'm not that
familiar with SC. As I perceive it the current docs are written by SC users
for other SC users and to be illustrated by the code. This leads to issues
when we want to implement it accross platforms as not everybody will be
intimately familiar with SC.
The particular issue I ran into is that I was unable to see how we'd get
actual sync. Marije explained to me (looking at the SC code) that when I
request to sync to the next beat I'll get;
*a float (that's a whole number) expressing the number of this beat since
the last bar line
*with a time-stamp expressing when it will occur.
Assuming We know the BPM at this point (and we do) that's indeed enough
(asside from temp changes in the meantime). Sadly the specs.txt file doesn't
actually tell me this as it doesn't mention the stamp aside from in
reference to the last tempo change. One particularly confusing thing to me
was that it talks about "logical time" without explaining what is meant by
that.
I'd like to suggest that these docs be extended to clarify what actual
messages are send when to make this standard more independant of a speciffic
implementation and generally clarify the workings of this protocol. Reading
it again now that I've been told how it works I can see that it's all there
in a way (and really quite simple) but previously I was having a bit of a
hard time with it.
If/when we get OSC timestamps for ChucK this should be quite straightforward
to implement. I'm not sure why we still don't have those, we could speculate
that it might have to do with how ChucK works; a block of 512 samples will
be calculated within the time that it takes for 512 samples to pass but some
point mid-way through that block need not be exactly after 256 samples have
passed as not all samples will take as long to calculate. I'm not sure how
that would work out here, maybe nobody is and maybe that's why we can keep
track of time since the last sample-clock-tick to a obscenely detailed level
yet not tell the time of day in ChucK. I don't know :¬).
Yours,
Kas.
2009/3/7 Jamie Forth <jamie71forth_at_yahoo.co.uk>
> Kassen,
>
> On 5 Mar 2009, at 14:40, Kassen wrote:
>
> I glanced at the docs I'll have a more in-depth look later. One thing that
>> strikes me right now is that there is a concept of "beats per bar" but no
>> way to sync to the last or next start of a bar. We can sync to the last
>> metre change but there seems to be no guarantee this coincided with the
>> start of a bar. Is that correct? Is that the intended behaviour?
>>
>
>
> The beat at which the number of beats per bar is changed always becomes the
> down beat (if it wasn't already). So knowing this, and also knowing how many
> beats are in the bar, means you can always work out where the bar line is.
>
> Messages for previous or next bar could easily be added, but this is more a
> matter of client functionality. Under the hood, a client should probably
> always sync to some concrete time-point in the past, even if, as a user, the
> behaviour you want is to drop the beat at the next bar line. Plus, doing
> this means that if the bpb or tempo changes in the mean time, your code will
> still kick in at the intended musical moment.
>
> Anyway, back to the topic of the thread... GSoC is a great idea but sorry I
> can't really help out much on the admin front at the moment.
>
> Jamie
>
>
> ___________________________________________________________All New Yahoo!
> Mail – Tired of Vi_at_gr_at_! come-ons? Let our SpamGuard protect you.
> http://uk.docs.yahoo.com/nowyoucan.html
>
>
Received on Sat Mar 21 2009 - 05:32:43 GMT