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