October

Thursday October 17th

A game for this weekend:

This is the game we’ll play in three steps:

1. Listen to the sounds around you. Listen to the tones. Listen to the other sounds.
2. When you have the sounds around you in your mind, add a tone to them on your instrument. Don’t worry about playing too much, or too little. Breathe and listen.
3. Let the tone emerge and unfold in a long and comfortable exhalation.

If you’re playing a pitch pipe:

• Just blow into one of the mouthpieces and listen to the sound, the pipe will take care of the rest
• Listen to the way the tone changes with the pressure of your breath. Listen to how your tones combine with others.

If you’ve brought your own instrument:

• Try to match the volume and character of the pitch pipes as best as you can
• Play from the concert pitch notes E, B, G, A, D in any comfortable register.

If you’ve brought your own instrument and “concert pitch” is nonsense:

• Just play along with your neighbors, and try to do your best pitch pipe impression.
• Favor slow gestures – just a couple different notes can go a long way. :-)

Above all: don’t worry too much about it and listen to the sounds that happen in the space.

Saturday October 12th

Woah, I missed September! That’s what I get for leaving the house, I guess.

I’ve been giving astrid a tour of the real world, which has been fun and sometimes disheartening when everything breaks down. I was sorta hoping I was through the worst of the showstopper bugs, but I am discovering a class of new bugs that are emerging when I use more than a small handful of instruments together. I’m doing a poor job of tracking these, but briefly:

• Starting more than a few instruments together has some kind of race condition that causes some to segfault sometimes… I’m working around it now by adding a small delay in between starting each instrument when I fire up a batch of them, but I’m very curious to dig into this one. I’ve only noticed it with python instruments so far. I haven’t confirmed yet if the same thing happens with lots of C instruments too.
• There are mysteries to discover regarding POSIX queue limitations. The main one I keep running into is sending messages to a queue that doesn’t exist fills up some kernel buffer after a while and then I can’t send any messages at all. I’m not sure if I want to add overhead on every message to check if the queue is available (tho maybe that’s fine, it’s worth looking into at least) so I could possibly just add queue flushing as a task to the cleanup routine that frees spent buffers in the mixer.
• Speaking of message queues: I’m still not convinced I’m avoiding throttling from the kernel. It’s way better with a high (low) nice setting and realtime privs, but I wonder if something like a local unix socket might be more stable…?
• The newest one I’ve discovered is that on raspberry pi, if the jack callback takes too long to execute (at least I think this is what’s happening) then the whole client application just errors out and dies.

That last one I discovered while working on an accompaniment program for an outdoor concert here in Winona happening next weekend. If I can get it stable enough to run for about an hour tonight I’ll be happy, since it only will really need to run for about 20 minutes.

I just read an interview with one of the Mego founders who IIRC said something along the lines of computers became less interesting when they stopped crashing. (Maybe this was Peter Rehberg actually!) I don’t really have an opinion about it right now though because I’d just like this program to stop crashing, really.