[chuck-dev] towards matching client / server messages in chuck
c.turner at 199records.com
Tue Nov 23 09:43:48 EST 2004
I'm looking to build a minimal collaborative music production / jamming
using chuck + pygtk + possibly pyORBit2 if it is needed.
basically, the flow is this :
I see there being a 'live' chuck (remote) running in loop mode which is
to the 'house' mix, and independant workstations (local) running where
edit shreds with the pygtk apps and preview them. Once they are
their previews, they can submit them to the 'live' mix.
however, there are 2 missing features with that as of 1.1.53 :
- as far as I can tell, it is not possible to synchronize the clocks of
2 chuck processes
- submitting a shred to chuck in loop mode does not return an ID to the
The former means that 'remote' loops will not play in time with 'local'
loops, and the latter means clients have no way of knowing which shreds
they have submitted into the 'live' mix.
I wasn't prepared to fix the first problem yet (big surprise :) )
so I went ahead and wrote this patch against chuck 220.127.116.11 for the
(would have written it against -current, but didn't know about anoncvs)
Basically, the second data field in the Net_Msg is filled with the
of the desired operation (instead of the more global 'ok'/'nok' that
seems to be stored in the first data field).
I had to tweak the shred queuing a little bit so that the shred id was
up the call graph, tweak the client such that it would actually print
corresponding message, and hold on to the initial message type for the
I'll be happy to integrate it in a cleaner way with the cvs chuck if
add support for other status messages. Ideally, I'd like all the
messages to match
on the client and server, but I didn't want to go mucking around with
without seeing how well it would be recieved / fit in with other plans.
As a side note, I wasn't sure what 'immediate' mode was for shred
submission, so I made all the shreds immediate as a test (because
immediate shreds get an id at that point, which made it -much- easier
to know the shred id : ) )
It seemed to have cleared up a strange bug whereby shred submission
triggers an un-queued sound to play at the beginning of the new shred..
(developing on apple laptop, but can do linux/jack testing.. this patch
has only been tested on osx)
Thanks for the coolest audio thingy around.. it is exactly what I was
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3669 bytes
Desc: not available
Url : http://lists.cs.princeton.edu/pipermail/chuck-dev/attachments/20041123/174cf4c6/chuck-18.104.22.168-ct1.obj
More information about the chuck-dev