[chuck-dev] towards matching client / server messages in chuck

[chris turner]

Hello All,

I'm looking to build a minimal collaborative music production / jamming 
system
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 
going
to the 'house' mix, and independant workstations (local) running where 
people can
edit shreds with the pygtk apps and preview them. Once they are 
satisfied with
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 
clients.

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 1.1.5.3 for the 
second problem.
(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 
return code
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 
returned
up the call graph, tweak the client such that it would actually print 
the
corresponding message, and hold on to the initial message type for the 
print.

I'll be happy to integrate it in a cleaner way with the cvs chuck if 
desired /
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 
the protocol
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 
looking for.

- Chris


-------------- next part --------------
A non-text attachment was scrubbed...
Name: chuck-1.1.5.3-ct1.patch
Type: application/octet-stream
Size: 3669 bytes
Desc: not available
Url : http://lists.cs.princeton.edu/pipermail/chuck-dev/attachments/20041123/174cf4c6/chuck-1.1.5.3-ct1.obj