A fellow Cycling ‘74 colleague recently referred to This commentary on Wiio’s laws.

If you ever need to communicate with others, especially on the web, and even more especially on a mailing list, then this is essential reading.

If it seems like hyperbole when the author says that communication is much worse, then consider a couple of things:

• The author makes no mention of the effect of typos in electronic communication. I happen to be notoriously bad about this. A misplaced, misspelled, or missing word can be crucial. And it’s common to have this messed up.
• What about the accidentally hitting the button to send when you meant to hit a different button? Oops.

Those are just a couple that come to mind immediately.

Last week a group of us from the Jamoma project were finishing up some work on a paper we submitted to ICMC.

During the process, Trond Lossius and I were talking when somehow we were off on a tangent about mapping. Trond mentioned that one example of mapping is BabelFish: given some input, it produces a translated output.

The implication of this is that many of our mappings in the computer-based arts are like BabelFish: they work in simple one-to-one or limited context translations. BabelFish can manage the translation of words, but it can’t handle the translation of meaning nor understand the context within which a word appears to make a better selection.

I find this parallel with BabelFish quite compelling, and have been thinking about it ever since…

A group of us from the Jamoma project have spent quite a bit of time in the past couple of weeks working on a paper for NIME regarding our Open Sound Control (OSC) schema, and the syntax we use to address various parts of our system.

The process has been rigorous and, to some extent, exhausting. Behind every corner has been a whole new can of worms. When we thought we had solved a conundrum, there would be three more popping up.

But in the end, I feel very confident that we nailed it. The key observation came from Trond when he realized that OSC, as it is presented in the spec, is based on constructs from functional programming (e.g. C). But what we are doing with OSC in Jamoma is based on classes and object-oriented design (e.g. C++).

While taking on the topic of making OSC object-oriented would be a mammoth task, I think that the work we are currently doing in Jamoma is a definite step toward thinking about OSC addressing in a fundamentally different way than I have seen others doing up to this point.

Of course, this probably means we’ll have to re-write Jamoma yet again! ;-)

There is an article in the New York Times about Radio Head’s recent album. It mostly focuses on the marketing model.

It even starts off with an anecdote about Cycling ‘74…

I was recently reminded of a couple of a blog posts I have bookmarked by Allan Odgaard, the man behind the very excellent TextMate app. This one is a good one:

• http://blog.macromates.com/2006/20-will-require-leopard/

This is an even better one!

• http://blog.macromates.com/2007/buy-a-mac-get-textmate/

As my frustration over a number of issues on Windows (particularly with the Objective-C mess), and as a number of other things have collided on different fronts, I’m realizing that the points Allan makes are really good ones.

This also presents me with an opportunity to mention that the ObjectiveMax project, as of about a week ago has become a Mac-only project. It’s a bummer because we then won’t be able to use it in TTBlue or Jamoma (because they both need to support Windows). Objective-C actually made the code fun to write.

Not having Objective-C on Windows also means that Tap.Tools 3 is not going to be all of the hoopla that was predicted in an earlier blog post. It will still be nicely integrated with Max 5, but the object set needs to be cross-platform (except for tap.applescript), and so won’t be getting an Objective-C re-write.

Hopefully this means I’ll have some more time to write music – which will positively improve my personal happiness :-)

One of my favorite parts of a good book or dissertation is reading the quotes at the beginning of a chapter. I recently read the dissertation of Alexander Refsum Jensenius, and it has some great quotes. Here are a few of my favorites:

It is easy to play any musical instru- ment: all you have to do is to push the right keys at the right time and then the instrument will play itself.
J.S. Bach

If you take a photograph of some- thing [...] you separate it from the rest of the world and you say, “This deserves special attention”.
Brian Eno (Kalbacher, 1982)

Computers have promised us a fountain of wisdom but deliv- ered a flood of data.
(Frawley et al., 1992, 57)

You have to have an idea of what you are going to do, but it should be a vague idea.
Pablo Picasso

Technology at present is covert philosophy; the point is to make it openly philosophical.
(Agre, 1997, 240)

And of course, I love the Albert Einstein quote at the very beginning of the dissertation:

If we knew what we were doing, it wouldn’t be called research, would it?

Somehow it reminded me of another quote that I like a lot. When Einstein was asked to describe how radio works, this was his answer:

You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat.

Here is the starting point for my little tangent today: http://media.rubyonrails.org/presentations/programminghappiness.pdf

The line “optimize for happiness” particularly struck me. A more thorough description of the concept can be found here: http://gettingreal.37signals.com/ch10_Optimize_for_Happiness.php

I have a little different slant on it, but the idea of writing code in a way that it is optimized structurally, syntactically, or otherwise rather than simply for performance seems very appealing.

Of course, my favorite segment from the Getting Real book is this one: http://gettingreal.37signals.com/ch04_Make_Opinionated_Software.php

The first three paragraphs are great. The rest a bit so-so, and the last paragraph I could live without, but the first three paragraphs make up for it.

It seems like a small thing to respect other people, but obviously it is always the norm. This especially true when dealing with customers. Why do some companies treat customers so poorly? This is part of the reason that exchanges like the following make me so happy, and so proud that Electrotap tries to be different…

(personal information omitted to protect privacy)

On Nov 20, 2006, at 9:43 AM, xxxxxxx@xxxx.xxx wrote:

>> Hello,
>> what should i do in order to be eligible for students discounts?
>> (like send you a jpg of my student card or whatever...)
>> thanks
>> Xxxx
>
> 2006/11/21, Tim Place <xxx@xxxxxxxxxx.xxx>:
> Hi,
> 
> We don't believe in validating student status -- if you tell us you
> are a student we trust you to be telling us the truth (i.e. innocent
> until proven guilty).
> best wishes,
>    Tim

Didn't think people like you existed anymore!!!!!!

Yup. We exist. It’s shame that this should be a surprise though…

Cycling ‘74 has recently published an article called Managing Complex Patches in Max by Arne Eigenfeldt.

I first met Arne at the ICMC banquet in Miami a couple of years ago. If my memory serves correctly, Arne was one of a number of people at that conference who told me that they realy liked using Jade modules in Max, especially for teaching, and that he really didn’t use the Jade application at all. The sum of these various conversations was part of the germination process leading to Jamoma taking flight several months later.

In addition to being a really thoughtful and deep composer/creator, he has a wonderful and gracious manner. His installation this past fall at the ICMC in New Orleans was particularly rich and full of depth. It was clearly the culmination of a lot of serious thought and the layers of sound it produced wove a really captivating tapestry. How did he do it?

There are lots of answers to that question, but a significant part of the answer was that he developed a style of patching in Max that allowed him leverage the benefits of a structured approach. In this article he shares a lot of what composes that approach.

I have personally been fascinated and obsessed with structural facets of music, software, art, nature, texts, etc. for a very long time. This obsession is reflected in Jade and Jamoma. Often I still feel that I have defend approach, and try to convice others that being structured is beneficial when working with Max. I’m thrilled to see someone else carrying that baton in completely separate context than Jamoma. Hopefully his insights will benefit Max users for years to come…

Last week I was chatting with friend and colleague “Andrew Pask” about various things. While we were talking I mentioned that one of the potential subjects for future versions of Jamoma are time-based interfaces for our cuelist module.

He thought it was interesting, but expressed that he is basically fed up with all of these interfaces that express time as a linear progression on the x-axis, and furthermore that representation is nearly worthless for truely interactive compositions or performances. So we started brainstorming…

We both came up with what essentially the same idea expressed in different ways. An interface where the Z-axis represents the progression of time. In terms what the user sees at any given time, it is like a single frame of a movie. Each frame then would represent the state or algorithm representing the state of the relevant Max patches or Jamoma module. Progression through these frames (or interpolating between them would be analogous to stepping through cues in a cuelist.

So, instead of watching time going across – you watch it like a movie. In some ways this similar to the way Apple has chosen to represent time in their Time Machine for OS 10.5. It would particularly nice if you could quickly scroll through time by using the scroll-wheel on the mouse.

A brief snippet from the dialog:

Tim: so it would be like each frame represents a patcher algorithm, or a set of data laid out visually, and you progress through the frames with possible interpolation or crossfading from frame to frame

Andrew: yes – or you could specify the frame “resolution”

Tim: and frames could be triggered by events, or driven by a metro through time, remaining completly flexible

Andrew: events which exist in frames could have inspectors

Tim: that could be really interesting. It might be sorta like a poly~ object (but not really) that loaded up a bunch of patches and knew how to represent them in this visual doodad thing

Andrew: you could represent an audio file as a vumeter type thing

Another thought that I had is that if it is in 3D OpenGL, you could actually rotate your view of time to be on z-axis or x-axis or y-axis (or some angle where you see all 3 concurrently. Because one of the benefits of the traditional x-axis is that it’s easy to click on a random location and be at that point in time immediately.

Being able to switch back and forth between different views would be important, because truely interactive music doesn’t represent well on a fixed x-axis whatsoever. But there are time when that is best.

Implementing this type of thing with Jamoma should be easier than without it. In Jamoma there is a well defined interface, and all modules communicate in a standardized way. This could also be implemented as an interface to the cuelist module, which means that the internal ‘events-engine’ is already done. It would still be an ambitious project and take some time to implement.

Of course this is just one possible alternative to the linear visualization of time on the x-axis. There must be more research about this topic. Before starting, perhaps we should figure out all the possible ways time could be represented (hah!). If you have any ideas, please leave a comment or send a note!