[chuck-users] A few random ChucK questions

[Spencer Salazar]

Hi Ken,

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  
> middleman?

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  
great.

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
OscRecv recv;
somePort => recv.port;
recv.listen();
recv.event( "/sync, i" ) @=> OscEvent sync;

while( true )
{
     // wait for a message
     while( sync.nextMsg() == 0 )
         me.yield();
     // 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.

Yes definitely!

> 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.

spencer

> - -ken
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFGFcg2e8HF+6xeOIcRAg0mAKCgfZtKFeb7ZK6TL8QCSiUT8XU61QCgxLSc
> HgJhYAcWcp1gN63rxuq24EQ=
> =EbUv
> -----END PGP SIGNATURE-----
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users