Hiho,
to cut things short... the spec documentation is incomplete, esp. regarding
the sync message. The spec lists only 2 arguments sent back, whereas the SC
clock server sends back about 5 arguments. And they are all quite relevant :)
Also, since SC can give you the information as to how many bars and beats
since the last tempo change... why not tell clients this info?
Also a manual that says that also one of the people involved should run an ntp
server so that system clocks within the local LAN (assuming that people don't
always play together while connected to a WAN) can be synched to that would
be useful. And maybe since not all livecoders are also sysadmins... a quick
guide as to how to set such a thing up, both as clients and hosts.
As a last note, writing the spec in more detail and explain the idea behind
the workings of each message, along with a description as to how a client
would connect, would really help.
It also allows for a close introspection into the written code, which may even
improve the code itself again :)
(at least that's what I find, when writing documentation).
ok, this is not as short as I planned it to be...
sincerely,
Marije
On Saturday 21 March 2009 01:31:27 Kassen wrote:
> 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 - 13:27:51 GMT