On Nov 23, 2004, at 9:43 AM, chris turner wrote:
I'm looking to build a minimal collaborative music production / jamming system using chuck + pygtk + possibly pyORBit2 if it is needed.
This is excellent.
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.
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.
Yes, we need this very much - thank you, I will put into next release, we should work together to integrate it.
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.
We need to somewhat design this part of the protocol...
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 : ) )
This could be problematic. Immediate mode was for skipping the message queue and calling the VM on the current thread. This is how machine.add() and friends work. However, it could crash using it from the server thread because the VM is on another thread and is not reentrant. Sorry for the lack of documentation on this...
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)
Does the unwanted audio occur with all client/server network shreds? One thing to test if it's the audio interface part of ChucK or if there are actual unwanted samples generated. You could record the server using rec.ck - this is sample-synchronous with the dac, so it will only catch things that are actually synthesized, and is immune to timing artifacts or audio interrupts. If you don't hear the glitches in the recording, then it's likely something in the machine or the audio interface code. If you hear the glitches, then something is sending it to the dac. Since changing to immediate got rid of this problem, then it's likely something in the machine code. Please post an example, when you have time.
Thanks for the coolest audio thingy around.. it is exactly what I was looking for.
Thank _you_! Please keep posting dev issues here - we will start a (gasp) document effort soon for us developers! Best, Ge!