Well, admittedly, most people never heard of Jamoma – so what was it?

Jamoma was intended to be a standard that was developed by an open source community for how to structure Max patches. The basis was that if all patches conformed to some common guidelines that they could be more easily shared and plugged into existing patches.

I have spent quite a bit of time wrestling with these issues in the development of what became Jade 1.0. I thought there seemed like quite a bit of promise in the idea and floated it on the Max list. I decided to try and start the open source initiative and named it Jamoma (the name sort of correlates to JAde MOdules in MAx – where the idea initially came from).

There were about 2 or 3 people that actually expressed interest in participating. I found this rather disappointing, but figured it was workable. Unfortunately, of the three people, 2 people had their own ideas which seemed incompatible and the project stalled. I think the Max community tends to be made up of so many do-it-yourselfers that it is hard get a group of people willing to compromise to make a new standard.

There were a number of ideas that were brainstormed by Jesse Allison and myself for Jamoma which I was pretty excited about. Finally, I am getting some of those ideas into place for Jade2. The new modules for Jade2 will essentially take the pieces of what was Jamoma and build on them. With any luck the tools, features, and structure of the new Jade modules can, in fact, become a defacto standard of some sort. I guess only time will tell.

In the meantime, I’m plugging away at some of those tools; right now an application onto which you drop a Jade module (Max patch) and it generates the documentation for that patch in HTML format. “Look ma! No hands!”

Hopefully I’ll have these tools implemented in the next experimental version of Jade, sometime in early January.

Merry Christmas!

Whew! It’s been a lot of work, but Jade2 is starting to come around. “Jade2! you say?” Yep. I’ve been plugging away at parts of this for almost a year – though most of the effort has been in the last few months.

Some major improvements and features are being added:

• new easy to use file format
• new module format
• new module development tools
• many speed improvements
• OS X native in how it interacts with the user

It has been a lot of work rebuilding all of Jade’s modules to work with the new system – I hope I never have to go through this again! I think I will not because the new format is much better and more flexible. The old format was somewhat arbitrary, and the new format is actually thought out based experiences and screen real-estate management. Part of what is making this difficult are clumsy decisions I made designing some the modules a couple of years ago…

I hope to have an experimental version ready for preview in a week. Time to shut this thing off!

A new beta of Tap.Tools has been posted to the registered users site. Here are the highlights:

• Jitter objects now available for Windows
• A couple of new objects including: tap.jit.colortrack, a colortracker (up to 4 colors) tap.route, an alternative to Max’s route (with attributes).

Enjoy!

A new beta of Jade is now up and going. The beta is being conducted on the siliconprairie list. You can join the list if you are interested in participating.

West Chester University presents a concert of new works in cooperation with the Society of Electro-Acoustic Musicians in the United States (SEAMUS). The program presents new music by Greg Wilder, Tom Flaherty, Scott Wyatt, and Timothy Place. Guest performers include Chris Bryan (cello) and Charles Fricker (marimba). The concert is scheduled for Wednesday, November 19 at 8:30PM in Swope Auditorium at the School of Music on the West Chester University Campus. Admission is free.

It looks like Tap.Tools blue will not be seeing the standard LFO implementation that I dreamed up on this Blog several weeks ago. Here’s why:

First off, it is a royal pain in the rear to implement intelligently. The code is becoming convoluted as I try to implement it, and that is not a good thing.

To top that off, I’m finding that the CPU can bog down significantly because I’m doing things with signals that would normally be reserved for Max control messages. An example: The blue.verb~ external is currently running around 5-6% on my cpu. Turn on the LFO and apply it to the base delay time and the cpu usage jumps to 20%. That just isn’t going to fly.

It seemed like a nice idea to have this stuff all built in. But the strength of max is to wire and modulate parameters with each other – so I think I’ll leave that which is good for Max to Max. Comments?

While I’m waiting for the Windows Jitter SDK (so that I can get Tap.Tools 1.5 done), I’ve been continuing to play with ideas for Tap.Tools Blue. The last couple of days I’ve been working on some speed boosts…

The big speed boost I’m playing with right now involves using function pointers to replace switches and if statements in my code (known as branching). It turns out to make a rather dramatic improvement in performance. For example, 50 copies an svf filter object (like MSP’s svf~) in MSP with a switch() statement runs at 54% of the CPU on my laptop. Using function pointers, the same 50 copies run at 12% cpu.

I had no idea the difference would be that big. There are also improvements in the panner, crossfade, wavetable oscillator, and other objects. It looks like Tap.Tools Blue is going to be a significant speed bump over the previous Tap.Tools – and I find that exciting!

Yesterday afternoon was a presentation at UMKC’s White Hall by Zygmunt Krauze, a composer from Poland. I found his music to be very engaging and enchanting.

He presented a number of his works. The first was an orchestral piece using shifting blocks of sonorities built on m2,M2, and m3 with a focus on minimizing contrast – siting similar goals in some works of visual art.

The second piece presented was fiddle (folk) tune based. He made several transcriptions of the same tune (each is slightly different), he then gave it to 10 performers who each do thier own interpretation of the transcription (including tempo). The outcome creates dense counterpoint but ,again, reduced contrast. He also discussed the issue of where the line is on claiming you have “composed” a work.

His Piano Concerto No.1 includes 2 accordions, electric guitar, and 2 saxophones, and is structured in a number of smaller attaca movements (somewhat like Crumb).

He then shared with us a technique whereby stones or rocks (about 8-12” large) are placed on the strings of the piano to create some really great musical devices. Last night he performed a piece using this technique called “Stone Music.” He also wrote a piano concerto with orchestra using the same technique (I very much liked the effect when combined with other instruments and textures). For notation, he gives description of size and position of the stones. Usually he is using multiple stones in the piano. The excitation source can be the rock bouncing or rocking themselves or using a small metal knife to shake or rattle between the strings – this technique does require amplification. The result is an incredible texture!

To wrap up, he presented Piano Concerto No.2, which featured some really incredible orchestration. He created a soundscape that was beautiful, warm, and rich juxtaposed with stark contrasts of more aggresive and abrupt sections. He talked about his working on how to put segments of contrasting material together(with or without silence), and how to do it so that the segments don’t ruin each other. Part of his conclusion after researching it, is that almost any segment of contrasting material can be put next to each other as long as it comes from the same “hand” – this is also true in the music of Messian.When asked about time aspects he responded that nothing is calculated but always intuited and not thought about too rigorously.

His performance was great. His style seemed mechanical or stilted at times. In some instances this resulted with a good effect and it seemed impossible that he would be doing some of the things he was able too. It was an almost Nancarrow-like effect. At other times I found it distracting and a little disconcerting. It is interesting to see the intersection of his compositional and performance styles. The lasting impression is that it was a phenomenal visit.

Glad I made it back from Norway in time…

I’ve spent some time the last few days, here in Bergen, working on Tap.Tools 2 – which I am now calling Tap.Tools Blue. It has been very productive, here are some of the developments I’ve been working on…

I’ve added a couple of (c++) objects including tap_clip and tap_lfo and I’ve made more efficient objects of tap_zerox, etc. The Max externals which I build from these now begin with a “blue.” prefix instead of a “tap.” prefix. This allows me to sidestep some backwards compatibility issues – the “tap.” prefix will remain in use for a set of abstractions I will build to keep backwards compatibility.

With some of the optimizations, blue.verb~ is now running at more than double the speed of the old tap.verb~. This is really exciting, though I know I can’t expect this type of speed boost with all of the objects. This speed boost comes even with the addition of a number of new features, which I hope to make standard among the audio externals. These features at the moment are:

• dcblocking
• limiting
• clipping
• lfos
• wet/dry mix
• gain
• downsampling
• mute
• bypass

I’ve also updated the look and feel of the help patches; I think they are much clearer now.

Well, I’ve finished my dessert (a waffle with strawberries) and my coffee is about done too. Time get back to the code!

This afternoon I finished my series of lectures and workshops at BEK, here in beautiful Bergen, Norway. If you ever have a chance to get to Norway, go straight to Bergen – it is an incredible and enchanting place. The trip from Oslo to Bergen is fantastic and the fjords are breath-taking.

This afternoon’s event was focused on Jade. I presented some of my music that has used Jade, and we looked at how Jade is doing things in the context of those pieces. We also took a look into some of the features in the upcoming Jade 1.5 – such as the tools to make building custom modules a relatively easy task.

Last Wednesday, Thursday, and Friday, was a Jitter workshop, also at BEK. On day one we got up to speed in Max and developed our own algorithms for filling Matrices one pixel at a time. Thursday we started working with feedback and additional matrix processing. Friday focused more on Tap.Tools and linking audio and video in Max/MSP/Jitter patches.

While that was fun, the real fun was on the weekend when I was blessed with the opportunity to have dinner @ the house of Trond Lossius. We had a fantastic meal of shrimp and I very much enjoyed chatting with he and his wife at their gorgeous property west of Bergen (including a view of the north sea)!

One of the highlights was seeing documentation of his installation Ekkofisk and having a walk through of the Max patches. The level of detail in the synthesis algorithms was great, and made for very rich sounds and envelopes and phrases. Also the use of Markov chains and the Max prob object seems promising and I need to study them much more.

Also we talked of a commission for a violin piece for a great performer here in Norway, and perhaps a collaboration. It would be wonderful if these could happen!

Tomorrow evening I will be headed back to Oslo and then on toward home… Sounds like a little time to actually get some development done!

-Tim