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

[Ge Wang]

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!