[chuck-users] A few random ChucK questions
ssalazar at CS.Princeton.EDU
Fri Apr 6 17:21:27 EDT 2007
Welcome to ChucK-land!
On Apr 6, 2007, at 12:10 AM, Ken Restivo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> A couple random ChucK questions:
> 1) Is there a tutorial or example code recipe somewhere
> specifically showing how to sync ChucK with JACK Transport? I want
> to use ChucK to supplement other tools that are sync'ed together
> using JACK (i.e. Hydrogen, Ardour, Rosegarden). I saw a thread that
> said, basically "use OSC", but I don't see any ChucK sample code
> that shows how to use OSC for syncing ChucK's clock with an
> external OSC-based source, i.e. like JACK transport.
> 2) A related but possibly off-topic question is: how do I translate
> JACK transport into OSC so that it can be sent to ChucK? Ardour and
> Rosegarden can send timestamps via MIDI, so that's one possible
> solution. Perhaps ChucK can accept MIDI sync, eliminating the OSC
In general we (ChucK team) are pretty clueless about JACK and
especially JACK Transport, as we just use RtAudio as our audio driver
backend and let that do all of the work with ALSA, JACK, DirectSound,
etc. There isn't any good supported method to make ChucK sample
synchronous with something else. OSC works for synchronization at
millisecond latencies, but for < 1::samp latency it might not be so
One thing that is worth trying would be to take advantage of ChucK's
sample-accurate strong timing. I have no idea if this would actually
work, but if you had some code like this running in one shred, you
might be able to accurately sample-sync ChucK with some OSC source:
// warning: written in mail
somePort => recv.port;
recv.event( "/sync, i" ) @=> OscEvent sync;
while( true )
// wait for a message
while( sync.nextMsg() == 0 )
// allow next sample to be calculated
1::samp => now;
The basic idea here is that, in ChucK, the next sample is calculated
only while each shred are in some kind of 'something => now;'. So in
this program, for every "space between two samples," ChucK won't
calculate the next sample until the /sync OSC message is received.
This would need some other program to send ChucK a "/sync, i" message
for every sample. Also, OSC could easily be replaced with some sort
of MIDI input here.
> 3) The polyfony and gomidi examples are great, but they seem to
> want to initiate a connection. That doesn't work too well: I start
> up synths (ChucK being used as a synth) and then connect my
> keyboard or sequencer to them using aconnect or qjackctl. So I
> guess what I'm looking for is a code snippet of a loop that'll have
> ChucK sit around waiting for an incoming MIDI connection, rather
> than trying to initiate one. Likewise, better if the shred doesn't
> die or become unresponsive to MIDI if the connection is closed and
> then opened again, i.e. from a different keyboard or sequencer.
I think this is possible to an extent with the current ChucK release,
but the device needs to be connected at the very beginning when ChucK
executes min.open() for that particular device. From there, you
should be able to hot-plug/unplug/start/restart your MIDI inputs as
needed--I'm not able to test this with ALSA right now, but I know it
can work on other platforms, sometimes.
Generally speaking, though, I think ChucK's MIDI implementation could
use some improvement in a lot of areas, including the kinds of
features that you are looking for.
Another way to do this would be, instead of exiting when min.open()
fails, to keep on trying min.open() until it succeeds, with some
amount of wait time between each min.open() call, e.g.
while( !min.open( 0 ) )
100::ms => now;
> 4) I'm really new to ChucK, but I didn't see any way to release a
> note. The sample code sounds like it stops the note hard at receipt
> of a note off message, or after 100ms, but reading the code, it
> doesn't seem to deal with note off at all! Most instruments need a
> release time, so I'd need a way to receive a note off, then start
> the note's release envelope, and I'm too new to ChucK yet to see
> how to do that.
The two polyfony examples will release the note when they receive a
noteOn MIDI message with a velocity of 0 (lines 94-97 of polyfony.ck,
lines 96-99 of polyfony2.ck). I think technically they should also
release the corresponding note when they get a noteOff message.
There are a variety of ways to deal with note releases in ChucK's
synthesis model. The ultra brute force method, used in polyfony.ck,
is to disconnect the UGen. Another brute force method is to set
the .gain parameter of the UGen to 0. A lot of the STK UGens have
built-in envelopes and corresponding noteOn and noteOff methods. You
can also use the Envelope and ADSR UGens to apply customized
envelopes to your patches.
> The built-in Ugens have lots of interesting parameters that seem to
> be already hard-coded to MIDI controller events,
Whoa, what? The Midi classes in ChucK only give you the 2 or 3 byte
MIDI messages that MIDI inputs provide, and let you send messages
back out. There isn't any default or hard-coded mapping from MIDI
controller events to parameter changes in UGens, although its not too
hard to write them in ChucK code.
> It seems like ChucK could be a very expressive softsynth, with
> parameters controlled not through a software GUI, but through real
> rotary controllers and buttons on a MIDI keyboard-- nice for
> performance purposes.
> The "plumbing" code I'd need (or need a lot of help writing), is
> the skeleton to handle waiting for incoming MIDI connnections
> instead of trying to open() them,
This is something would be nice like to have, but isn't quite there yet.
> and to handle note off events with some kind of decay envelope.
As I mentioned earlier, take a look at Envelope and ADSR for details
on how to do this.
> From there, I think I can figure out the program change and
> controller change stuff myself.
> My apologies if I'm the only person out there trying to use ChucK
> as basically a GUI-less softsynth controlled by MIDI.
No apologies necessary! ChucKers come in all varieties, and decent
support for hardware controllers is an important goal of ChucK.
> - -ken
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> -----END PGP SIGNATURE-----
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users