Once upon a time, there was a project called Jade. There were a lot of good things about Jade, and of course there were some bad things. Out of Jade came Jamoma. Jamoma has been torn apart and put back together a number of times, and Jade (which was difficult to maintain anyway) became harder to maintain and fell way behind.

Eventually Jade was open sourced. The hope was that Jade, like Jamoma, would pick up some interest and some dedicated developers and it could get up to speed. Jade would still make the idea reference environment for hosting Jamoma modules. However, in the time since Jade has been open sourced (about 18 months ago) I have not received a single email about it. I tell people about it and they say “oh”. Which seems odd because it seems like a lot of people know about Jade.

What does this mean? No one has the time to even think about it? That seems plausible, as it has been one of my problems. The project seems overwhelming? That seems plausible too, though if the person was just using Jamoma instead of developing it as well it shouldn’t be to bad.

Personally, I have a lot of baggage associated with Jade too – good and bad. When I think ‘Jade’ I think of specific ways of doing things in Max patches and such. Even to re-write Jade from scratch, I get stuck in the same routines and the same ruts—and caught thinking about all of these various unresolved issues in Jade, which has nothing to do with anything.

If I were really interested in a clean start on a Jamoma host application, I think it would need to called something else—even if it ended up being called Jade again at some point in the future. Of course, perhaps the whole world (or that extremely small slice that would care at all about Jade) would need a similar fresh start. Especially given how different such a host might be.

So I’m going to call this new application, whatever it might be, something new. In the case of Jade, it had several names before it was Jade. It entered beta testing with the name Silicon Performer. At some point I grew to be disgusted by the number of syllables in the name and the lack of imagery invoked by the name—so I started looking at various rocks, minerals, and stones for names.

The current working name of this new entity is ‘Cog’. The pronunciation according to the Oxford dictionary is Käg, and I like umlauts, so I could use that. The word is believed to be of Scandinavian origin: Kug, or Kugge. I think I just like Cog though. It seems clear.

Cog is a carpentry term, which seems apropos. It gives a sense of gears and wheels and motion and machines and energy. It isn’t the most important dominating force in what is going on – that would be the art work or musical performance or interaction or underlying philosophies. Rather, it is simply a gear in the larger system of the artwork “that transfers motion by engaging with projections on another wheel or bar” [from the Oxford dictionary].

Jade has now been released as open source software under the GNU LGPL. This has a been a while in coming, and I think it will make a lot of people very happy. To be fair, anyone who purchased Jade in the last 6 months will be receiving a full refund.

More details will be coming in the future. For now you can know that Jade and all of its source patches are now accessible to all for free. Enjoy!

Something is shakin’ in Jade land. Are you ready?

Following the KromoZone performance in England, I returned to Kansas City to master a recording of Dandelions for release on the CDCM series on Centaur Records. The problem was, my crazy hack for managing the performance no longer worked (see the first post in this thread). So faced with the need to redesign the patch (again), I took the various things that I had learned with Dark Forest and KromoZone into the processes of rebuilding the patch. The rebuilt patch is pictured above.

At this point, I was still building patches for specific pieces. I was beginning to think modularly in that I was able to re-use certain bpatchers, but I still modified them a fair amount for each piece. As an example, the color scheme of the screenshot above reflects the piece it was made for – Dandelions – with the green base and yellow top and bit of sky showing through in between. The modules are not a standard size, and so are really not all that interchangeable.

However, this is the patch where things will look very familiar to users of Jade 1.x. The input module in the upper left, the output module in the upper right, some analysis thing in the upper center, a control-type thing in the middle with display messages, and the matrix on the right, are all conventions that began with this patch. The initialization was done by a coll object with it’s text file saved on disk. The event script was done using a qlist object with it’s file saved on disk.

The patch pictured above was my performance patch for the Music Without Walls conference at DeMontfort University in the U.K. The conference occurred within a month of the release of Max 4.0 in the Spring of 2001, and I zealously dug deep into Max 4.0 to exploit some of its features. The conference paper, demo, and performance was another KromoZone performance – this time with Stephan Moore, Scott Smallwood, and myself making the lineup.

The patch was developed during a week of preparation with Stephan and Skot in Troy, NY (RPI). During the time I was there, Curtis Bahn basically got me hooked on the bpatcher object. I had previously known about it, but never quite trusted it for whatever reason. I quickly became addicted to it as it made the structure of my patch much cleaner and easier to conceptualize.

In this patch I used a coll object for all initialization, an idea taken from Todd Winkler’s book about Max. There was no event script or qlist because all parameters were controlled in real time by a Peavey fader box, foot pedals, and a fiddle~ object. The paradigm was that the patch was to extend my trombone into a sort of meta-trombone. The catch was all three of our computers were also controlling each other’s computers in a wierd interconnected way over a local network.

Our best performance was not actually at the conference, but in the studios of WRPI – the radio station at which Stephan worked in Troy. A photo from that performance, showing the patch, is below. Scott Smallwood is also in the picture.

This was the first patch where I was clearly separating the interface from the dsp algorithm. Inside any of the modules was a separate abstraction with the actual dsp processor. This could be turned on and off with the big toggle that you see in the interface for each module. At the time this still used the same pcontrol method that I had developed for Dark Forest.

In the Winter of 2000-2001 I further refined the structural formula I had used for the KromoZone performance in Seoul for my the piece that would serve as my Master’s thesis: Dark Forest. A quick glance at the screenshot does indeed bear a strong resemblance to the patches for The Nature of Contigency.

What was a significant improvement, however, was how I was forced to deal with CPU management. I did this by encapsulating each section of the piece into a subpatch. Then that subpatch had it’s processing turned on and off with the pcontrol object, which was controlled by the qlist. I also incorporated a display so that the qlist could show messages that would help cue the computer operator and give a status of what the system was doing.

The way the piece worked was that many aspects of the performance were controlled by doing color-tracking of a video source, which allowed me to get gestural information from the mallets of the performer. Each “section” of the piece could actually consist of several components. As an example, the screenshot below shows the multiple elements involved in the transition from section 1 to section 2 of the piece.

This entry is continued: Click here to continue reading.

In the Autumn of 2000, I had a performance at the Seoul International Electronic Music Festival. The performance was by the group KromoZone, which I had founded with Stephan Moore while living in Baltimore back in 1998-1999. The performance in Seoul featured both of us, together with Seongah Shin (wacom-controlled powerbook) and Paul Rudy (amplified cactus) on stage and Rich Jaime (video production) back in Kansas City.

The plan was to collaborate on the performance across the network. Unfortunately, the organizers of the festival did not provide us with the promised network connection. They instead showed a network cable that we could use – which was a bunch of bare wires with no connector (the mixer also went up in smoke at the intermission prior to our performance – so we had a variety of challenges). Fortunately, we had a backup plan in place, and the performance came off successfully.

The reason that this particular performance comes up in the context of Jade, is that it was the first performance I did using the qlist object. At the top of the patch, clicking the “event button” would open up an interface for the qlist, copied from the qlist help patch by Richard Dudas. This was used for automating the processes in the patch. It worked the same way as the qlist example in Jamoma. The contents of this qlist can be found if you click below.

This particular patch (there were 7 computers with patches) was for the video projection. It used Nato for the movie playback, pre-performed rendering, live video processing, and the combination of these elements. It also used Trond Lossius’s lut-level object for controlling the look-up table attached to the 242.lut object. The patch is structured as a series of sections (with a set of video processes) and transitions between these sections.

We agreed on a structure prior to the performance. A score was created on graph paper, then scanned, and included in each performer’s patch. Multislider objects on the top and bottom then scrolled across indicating the current position in the score as the clock advanced. This allowed us to all follow the score. The clock was generated over the local network (which did work for the performance), so we were all synchronized.

1. KromoZone network server
2. Seongah’s Powerbook and Wacom tablet
3. Stephan’s Powerbook / Peavey Sliders
4. Nato video processing patch (live input was the cactus)
5. Video analysis machine (nato-based, watching the cactus video feed)
6. 4-channel spatializer, driven over the network by the video analysis machine.
7. (unused in the actual performance) Video control machine back in Kansas City.

The video processing patch could be controlled over the network by Rich Jaime, or the qlist could be triggered by the performance clock, which is what we did in the non-internet performance situation.

This entry is continued: Click here to continue reading.

It has been a long spell since the last Jade beta was posted. The combination of work on Hipno and my dissertation has kept me from doing the much needed work on these betas (and will continue to do so for next couple of months – this will probably be the last Jade beta before sometime in May).

The most significant part of this new beta version is that it is built on the latest versions of Max (4.5.3) and Tap.Tools (2.0 beta 5+). This alone resolves the most troublesome issues in the previous couple of betas.

A notification should be going to the siliconprairie list shortly…

• fixed installer permissions (again)
• updated Jade splash screen
• Max Runtime splash screen no longer pops up
• software no longer expires

• added attribute-savvy arguments to matrix.audio and also added a ‘fast mode’ option to the audio matrix (binary connections), though neither is actually usable (yet) from the Jade script handlers
• new tutorial (Tutorial 7) added to the Documentation folder for how to build your own modules

• (really) fixed bug with paths containing free-standing decimal point numbers

• Problems linking from cascaded k.* modules introduced in beta 10 are fixed
• pitch_shift module problems introduced in beta 10 are fixed
• k.lfo now offers a “square” waveform
• k.lfo now more CPU efficient