Thanks to all at Lightwave, Science Gallery, Trinity College, Dublin, IE for a wonderfully well presented exhibition, and for the opportunity to meet a number of fantastic artists from around the globe, as well as catching up with a few from the ITP crew.

Next up: NEXT.

THRU YOU | Kutiman mixes YouTube

So, so good in so many ways. I want more.

“We know that our patchwork heritage is a strength, not a weakness. We are a nation of Christians and Muslims, Jews and Hindus — and non-believers. We are shaped by every language and culture, drawn from every end of this Earth; and because we have tasted the bitter swill of civil war and segregation and emerged from that dark chapter stronger and more united, we cannot help but believe that the old hatreds shall someday pass; that the lines of tribe shall soon dissolve; that as the world grows smaller, our common humanity shall reveal itself; and that America must play its role in ushering in a new era of peace.”

Image: Beatrice de Gea/The New York Times
Lyric: Jakob Dylan

Getting ready for All Points West next weekend. Up to 1024x216 at approximately 316 colors. We are go for animation.

We're all set to display the new ORB and ultraORB at The Last Hope at Hotel Pennsylvania tomorrow, Saturday, and Sunday. We spent the evening in the space prepping things and meeting a few of the early arrivals. Looking forward to an interesting weekend.

Time for sleep now. I thought hackers were going to bed at 8:30am, not registering for conferences.

One of the great things about the new Mac Pro is its full size optical digital output, which feeds pure and clean digital audio to my receiver and on to the speakers in the office or main room. The downside of this is that the implementation is such that there is no master volume or mute capability; the optical out is a direct hard line out of whatever your apps hand it. Controlling volume with iTunes is no big deal, but it's really really annoying when you open a website with blaring loud awful music and have no way to quickly mute the sound. The best way I know is to open the System Prefs and change the audio output. So I figured what better time to hack a little AppleScript to at least automate the output switch.

I've only touched AppleScript on one other occasion, and I must say it's a bit of a mystery to me. It's sort of like the developers tried so hard to make the code like English that it turns into a confusing mess of pseudocode, and I've yet to find any comprehensive reference of what's possible in quick glances at what seems to be a maze of documentation. (Any pointers to such a reference would be much appreciated, BTW) But, there's always Google. To be fair, I've only spent a few moments with it and was able to figure out what I needed to make my mute button work, albeit with a big chunk of copy and paste from the O'Reilly Mac Devcenter blog.

So, without further ado, here's the code. You'll need to use AppleScript Utility (in /Applications/Applescript) to "Enable GUI Scripting" for this to work (the script will help you out with this if you haven't already done so). Use the Applescript Editor (also in /Applications/Applescript) to save the code (it seems to do some compilation in the process).

The long lines are hard to read here on the site, so the code is also available here.

(*
Modified from the script found at www.oreillynet.com/mac/blog/2006/07/applescript_audio_output_switc.html to
switch between Digital output and Internal speakers, to act as a mute when using Digital out
*)

(*
This script toggles between two audio outputs in the "Sound" pane in "System Preferences" and adjusts the volume. 
Modified from a script at forums.macosxhints.com/showthread.php?t=45384 
to add volume control and GUI scripting detection. --David Battino, www.batmosphere.com.

USES GUI SCRIPTING; "ENABLE ASSISTIVE DEVICES" OPTION MUST BE CHECKED IN THE "UNIVERSAL ACCESS" PREFERENCE PANE
*)

tell application "System Preferences"
	activate
	set current pane to pane "com.apple.preference.sound"
end tell
tell application "System Events"
	if UI elements enabled then
		try
			tell application process "System Preferences"
				tell tab group 1 of window "Sound"
					click radio button "Output"
					if (selected of row 3 of table 1 of scroll area 1) then -- Digital out is selected
						set selected of row 1 of table 1 of scroll area 1 to true
						tell application "Finder"
							set volume 0
						end tell
					else
						set selected of row 3 of table 1 of scroll area 1 to true -- Internal speakers are selected
						tell application "Finder"
							set volume 2
						end tell
					end if
				end tell
			end tell
			tell application "System Preferences" to quit
		on error
			tell me to activate
			display dialog "Problem selecting audio device." buttons {"Whoops!"} default button 1
		end try
	else --GUI scripting is disabled
		tell application "System Preferences"
			activate
			set current pane to pane "com.apple.preference.universalaccess"
		end tell
		display dialog "Please check the box called \"Enable access for assistive devices.\"" buttons {"Okay"} with icon 1 default button 1
	end if
end tell

The script opens the System Preferences dialog, clicks on Sound, selects the Output tab, and toggles between outputs 1 and 3, which in my case are "Internal Speakers" and "Digital Out". When setting the output to the internal speakers it also sets the volume to 0 (mute). Perfect.

Now with a Quicksilver trigger, the script runs when I press F10 (in my case fn+F10, since I have the other special keys enabled) and mute is toggled. I also used the Quicksilver triggers and the iTunes plugin to map F11 and F12 to iTunes volume up and down. Not quite as nice as master volume + mute, but hey, it's digital to the amp — worth a little annoyance.

I've been doing a lot of work in Ruby on Rails lately and absolutely love it. In the past few days I've needed to port an existing database over to a new schema for comparisons and benchmarking. It took a bit of digging to find what turned out to be a typical RoR (read: elegant) answer to the related problem of maintaining connections to multiple databases in Rails, so I thought I'd offer a link to Dr Nic here.

It's also worth mentioning with respect to the new piece for Coachella, that I've acquired a few new tools that are making the process much quicker and easier. First and foremost, and really the centerpiece of it all, is the new Tektronix TDS3024B Oscilloscope. This baby has been on my wishlist ever since playing such a huge role in my senior design project success back at UIUC, and with the days counting down fast to Coachella, I decided I needed all the help I could get, and it really has been a big help.

I often describe working on electronics without a good scope as being comparable to trying to work with your eyes closed. It's not necessarily impossible but it increases both the time and frustration of even simple tasks by orders of magnitude. It's much easier to work intuitively when you can see what's happening right before your eyes. The image above, which I grabbed just to confirm that the duty cycle of the PWM was changing (in this design, the duty cycle of the PWM is also capable of changing faster than the eye can perceive), shows in yellow, pink, and green the CS, MOSI, and MISO lines from the FPGA to the SD card, and in cyan one of the channels of PWM out to an LED. Prior to this I had an old Tek265 analog scope which was useful in many circumstances, but for things like the serial bus debugging of the past few days, just didn't do the job. The 3024 has 4 channels @ 200MHz with all sorts of advanced measurement capabilities, FFT, advanced trigger, and a 640x480 color LCD. It also sports its own internal web server so getting screen captures is as simple as opening a web browser. The only negative is that when debugging a 50MHz serial bus on a 200MHz scope, the waves are pretty distorted, so a higher bandwidth wouldn't hurt. I wouldn't trade the advanced features for more bandwidth though, and to up the bandwidth to 500MHz crosses the line into 5-figure territory, which just wasn't in the cards this time. The reality is that the 3024 has been capable of everything I've asked, and I couldn't be more pleased with my decision on this one.

Also very helpful has been the Intronix LA1034 LogicPort USB Logic Analyzer. A logic analyzer is essentially an oscilloscope that trades the ability to see analog voltage levels for the ability to see lots of channels at once — in the case of the LogicPort, 34. It's somewhat limited in its sample storage capacity, which limits the length of data you can view at one time, but it mostly makes up for this with really smart triggering, which lets you focus that limited view on exactly what you want to see. The software also decodes serial buses, so it turns the SPI data and clock wave forms into hex that you can read directly (shown in the image below), which has been invaluable in the past few days. It's also an incredible bargain, when you compare with hardware solutions that (in Tektronix) start at $10k. The LogicPort is no $10k piece of gear, but it's a great addition to the lab that I'm very glad to have made. Plus, it's made in the USA by a small American company doing great work, which is always nice to support when the opportunity arises.

For the past few months, and really accelerating in the last couple of weeks, Dad and I have been working on a new piece, set to debut at the Coachella Valley Music and Arts Festival April 25-27. At its core will be a much improved spherical display with high-res surface complemented by volumetric accents, all in 24-bit color. On-board will be on the order of 10GB of removable flash memory, combining the increased resolution and color depth with a much greater potential show length as well as much easier program changes. All of this will lend itself toward a renewed focus on content, which is a very exciting thing for me as a big step toward the high-definition three-dimensional canvas which I originally envisioned with the ORB.

To make this a reality, I've finally crossed the void into the world of FPGA, and I'm loving it. The ability to quickly create massively parallel hardware in a few lines of code is really powerful. It takes a bit of getting used to, but within a few days I was generating the beginnings of working code in VHDL, largely with the help of Volnei A. Pedroni's Circuit Design with VHDL and the Altera Cyclone III Starter Kit. Now, just under a week into serious development, I feel as though I've got a pretty good handle on things, so the learning curve isn't as steep as it initially seemed, particularly if you've got some crossover experience developing both software and hardware.

As is unfortunately too often the case though, the learning curve seemed steeper when it came to using some of the pre-existing libraries I found. I needed SPI to access the flash memory, and so I started looking for libraries. The Altera board shipped with Quartus II which I'm using for all of my development and is a pretty nice package. Quartus leads you directly to Altera's NIOS soft-core processors with all kinds of great add on modules. These designs are cool because they allow you to set up part of the FPGA to act as a microprocessor meaning you can develop in a typical procedural language like C where appropriate, using the hardware definition languages only where necessary. The demos were easy to walk through and I thought I had everything figured out — until I read about the $2500 per seat licensing fee.

I'd heard of OpenCores and it sounded like a really cool project so I thought I'd check it out. OpenCores is essentially Sourceforge for HDL (hardware definition language) designs, albeit much less trafficked. It appears that there is some great work going on there, but at my level of knowledge, the documentation was just insufficient for my needs. If I really needed a fully-featured CPU running on my chip I'm sure I could have figured it out given enough time, but as it stands it's far from plug and play. And as the countdown timer on coachella.com continually reminds me, the show starts in 45 days, 17 hours, 28 minutes and 26 seconds. So it's time for action.

As it turned out, I spent a bit more time tweaking the SPI module I had been writing prior to looking at the soft cores, and with just a bit more effort, got it up and running. I then began work on a state machine that controls the SPI module and passes the data out to a set of PWM modules which actually control the LEDs. I'm still working on scaling the code and getting some of the finer control functionality implemented, but all indications are that with a few more days of work the code will be 99% complete. Then its on to PCB design, construction, and content.

In parallel with the electronics, Dad's hard at work building two chassis, one to ship to Manhattan for me to use as a framework to finish the electronic development and another to finish out in time for Coachella. We've got a totally new look this time, a bit more design-influenced and incorporating some cool high-tech materials. I'll get some photos of that part of the process up here as soon as they become available.

In the meantime, it's back to work.