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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users