3 ms·

I very briefly worked on ChucK while at Princeton years ago, although I never finished my contribution to be an official committer. Having spent a decent amount

I very briefly worked on ChucK while at Princeton years ago, although I never finished my contribution to be an official committer. Having spent a decent amount of time with it, I think the biggest problem with ChucK is lack of flexibility within the strongly-timed model. The ChucK operator, `=>` is used to connect together unit generators, but as I recall, you can't use it to connect arbitrary ports of those unit generators together. Each has only one designated ChucK input and/or output. This makes it difficult to truly experiment with modulation. You pretty quickly reach a point where you end up writing the same old procedural code you'd write in C or Java, explicitly manipulating samples instead of streams. There are many other systems that are similar, including SuperCollider, Max/MSP, PureData, CSound and JSyn/JMSL. I think the intuition behind ChucK is similar to the functional reactive programming of Elm [1]. But it's doesn't seem as though it's thought completely through. It would be cool to see a true FRP implementation for sound.

krazydad 13y ago
I've been working on building a set of basic music patches simultaneously in ChucK, PureData, SuperCollider and Pyo. The idea is to produce patches which produce the identical sound, to illustrate the differences between the music languages. I have a long background as a C programmer. Because ChucK is C-like, I have had the least trouble learning it, of the 4 languages mentioned above. The simple stuff I implement in ChucK tends to work the first time. However, my musician friends who are not C programmers tend to find visual patching languages (like PureData and Max) far more intuitive. Performance-wise, ChucK seems to me to be the least performant of the 4 mentioned above, however, for my needs it works fine, and I look forward to doing more work with it.
droithomme 13y ago
> you can't use it to connect arbitrary ports of those unit generators together. Each has only one designated ChucK input and/or output. This makes it difficult to truly experiment with modulation You can route things to multiple destinations with multiple ChucK operators. You can also route to specific inputs by naming them. Arbitrary routings are neither impossible nor a problem. SinOsc A => dac.left; // Here, A's main output connects to a specific input of object dac. SinOsc B => dac; A => B.freq; // Here we see the same A having another output connection, and connecting to a specific input of another object to create FM modulation.
- droithomme 13y ago
  NOTE: please ignore above post. I shouldn't post before coffee, or without checking code. Routing A's audio output to B's frequency control output does require doing it in a loop since A's output is not compatible with freq's input. Have to do: A.last() => B.freq, and last() is the current sample, so needs to be called in a loop to work, which is what AC was saying - parameter modulation ends up being fiddling with individual samples.

krazydad 13y ago

I've been working on building a set of basic music patches simultaneously in ChucK, PureData, SuperCollider and Pyo. The idea is to produce patches which produce the identical sound, to illustrate the differences between the music languages. I have a long background as a C programmer. Because ChucK is C-like, I have had the least trouble learning it, of the 4 languages mentioned above. The simple stuff I implement in ChucK tends to work the first time. However, my musician friends who are not C programmers tend to find visual patching languages (like PureData and Max) far more intuitive. Performance-wise, ChucK seems to me to be the least performant of the 4 mentioned above, however, for my needs it works fine, and I look forward to doing more work with it.

droithomme 13y ago

> you can't use it to connect arbitrary ports of those unit generators together. Each has only one designated ChucK input and/or output. This makes it difficult to truly experiment with modulation You can route things to multiple destinations with multiple ChucK operators. You can also route to specific inputs by naming them. Arbitrary routings are neither impossible nor a problem. SinOsc A => dac.left; // Here, A's main output connects to a specific input of object dac. SinOsc B => dac; A => B.freq; // Here we see the same A having another output connection, and connecting to a specific input of another object to create FM modulation.

droithomme 13y ago
NOTE: please ignore above post. I shouldn't post before coffee, or without checking code. Routing A's audio output to B's frequency control output does require doing it in a loop since A's output is not compatible with freq's input. Have to do: A.last() => B.freq, and last() is the current sample, so needs to be called in a loop to work, which is what AC was saying - parameter modulation ends up being fiddling with individual samples.