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
