RLPF.ar

(Somewhat techie content)

High stress the last couple of days. I'm (finally) looking for a new laptop for Linux. The first challenge: I need an express-card expansion slot for my FireWire audio interface. These seem to be dying off as quickly as built-in FireWire ports in laptops. That limits my choices rather a lot, though there is an MSI model on sale that does have the slot. MSI is not a well-known brand, but they are the factory that makes Apple's laptops, which have a reasonably good reputation for reliability.

That leads to the next issue, which provoked more than a few moments of panic. I've been using puredyne, which attracted me as a lightweight, live CD/USB bootable Ubuntu distribution with a ton of audio and multimedia packages preinstalled. It turns out puredyne is not compatible with the latest generation of Intel laptop processors (the Core i3/i5/i7 series). I'm guessing the issue is that the OS can't find the display so it appears to freeze during startup. It took some searching, but I finally found it's a known issue with Ubuntu Karmic, on which puredyne is based. Supposedly that is fixed in Ubuntu Lucid (10.04). Tomorrow, I'll go back to the store with 10.04 CDs -- if it boots (and my web searches lead me to believe it should), problem solved. Otherwise... well, I'd rather not think about that right now.

In fairness to puredyne, a version based on 10.04 is in the works. It's a volunteer effort, so it takes a little extra time to catch up to new Ubuntu releases.

On top of that, programming the last couple of days has really felt like Sisyphus trying to roll the boulder up to the top of the mountain. A large part of this is that I'm doing something new for me, which is also something that runs slightly oblique to SuperCollider's orientation. SuperCollider likes to run processes that are in control of their own timing. In Affectations, much of the timing comes from immediate response to the dancers' gestures. Single events as immediate responses are easy, but that's boring. We also need gestures to be able to produce autonomously-timed sequences -- a wave of the hand could trigger a swirl of notes. It's this hybrid of responsive and automatic timing that's proving to be messier than expected for complex processes.

Why not keep all the processes simple? To make computer-generated music interesting, the processes have to represent musical information in a way that's relevant to the ways people listen to music. Also important is exposing parameters so that I can make a basic process template behaves differently at different times, without too much rewriting. I have a specialized "process object" that helps with this while also keeping processes in their own separate spaces, not stepping on each others' toes.

Some good progress today, though. I had been struggling with a technique to create a micro-environment to run several gestures from the same process object simultaneously. That's where Sisyphus comes in. No matter what I did, something always went wrong: the micro-environment wouldn't have all the information it needed, or it wouldn't clean up after itself. Today, I threw all that out and decided to create a separate process object from the template every time the trigger comes in. I didn't want to do that at first because processes are kind of heavy objects, but the advantage is that they already have all the logic to keep themselves separate. And in fact, I was able to get this working in just a bit more than an hour.

Tonight, we celebrate a friend's new Ph.D. The chance to unwind is most necessary! I think I can enjoy it more since it looks like there's a way forward both for the new machine and the new logic.