Saturday, February 4, 2012


There is a small window between learning and knowing where it's possible to surprise yourself with a good design. Sometimes you are confronted with a new set of technologies and a new problem domain, and armed with a solid background in the fundamentals software engineering. You lay out the plans and begin work taking the best things from your previous experience, but only some of it applies. The rest is subject to your intuition and inherent skill, something that has nothing to do with experience with toolkits and successful or failed projects.

You trudge on almost blindly, building the system to match the "requirements" as well as you understand them. Gradually the behavioral nuances of the new technology bubble to the service, and little by little your skill set rises to meet them.

You proceed conservatively and test thoroughly, hoping for the best on the big day when you'll pull the switch. But your experience keeps tugging at your sleeve with the reminder that no matter how hard you design and test, the fact is that you simply can't be completely sure until it's all over.

But, the system rolls out and you move on. You've done well. Clients are happy, and minor bugs roll in. Your hard work is rewarded with service requests that fall well within the realm of fixable flaws. You charge for them, and a wish list grows.

Then some day down the road you finally have a chance to look back and get a feel for the process. "Wow," you think, it's kind of amazing how all of this works. Amazing how easy it is to get caught up in the confusion of the process while it's happening. But all in all, well done. Hard work always pays off.

Saturday, December 3, 2011

User Interaction - The Next Step

The best thing about the iPad. Man, we dev monkeys have known for a long time that something like the iPad was a good idea. Remember how touchscreens were like this mystical feature into a world of futuristic interfaces for so long? Like how engaging warp nine was totally the shit in conceptual whiteboard land but never actually a reality until a little PC vendor finally struck gold with a good design?

So why was this such a cool idea for all those years? What message was in our deepest gut that said at we wanted iTouch everything? Now hat we finally have this platform well-deployed and it's the most popular consumer electronics item of our lifetime (of all time?), what do we do with it? What's next? What now?

I think the answer is we push the envelope of user interface design with good graphics, wacky paradigms, and new ways of looking at problems. We are finally at a point where the door is open for the average developer to make the next big advancement, and it's all about the idea.

For one small example, sketching with AutoDesk SketchPad pro is incredible. It won't replace pencil and paper for everything, but does a lot of things pencil and paper can't do. You can quickly and fearlessly fearlessly move through ideas with undo and by adding new layers. You can try combos of brushes and blending that would never be possible on the old medium. This means you've got a new tool with a new niche - not just a toy.

We've had visualizations for music for some time. They've always looked cool, but is it possible that they help us think about the music better?

What can the machine do that we could never do before? What other ways can we show the data? What new angle can we present the problem? Nothing other than unbridled creativity can answer those questions.

My favorite pet puzzle is finding a way to push the envelope with live music production - and more specifically with music sequencing (writing out a part for an instrument). Just like finger painting, making music is something that is completely human and an art form where computers can make a big difference in helping humans become even more human.

The obvious iPad answer is to resell software reproductions of classic hardware synthesizers with beautifully crafted interfaces like the Korg iMS-20, or iElectribe. Plugging a MIDI keyboard in using the camera connection kit means the iPad can be a real, usable musical instrument and can save us thousands of dollars on the hardware counterparts.

Kaoss Pad - So much fun with a low-pass filter.
Bt what next? What about new ways of designing the sounds or composing the music? In my humble opinion, the best interface for writing a drum part is still 30 years old, and I feel like that is going to change very soon (remember all that techno from 10-15 years ago? Yeah, that's where it came from). It's time to try new ideas, like improving the workflow for live MIDI recording arrangement to build a better musical whiteboard. Or building on the clunky grid-based midi sequence editor that every music composition program seems to have settled on as "good enough".

It's all about the features that really matter. For example, if Garage Band for the iPad relied on the built-in keyboard or a shitty 16-step drum sequencer like all the other apps, it would be a very cool and utterly worthless gimmick. Adding a line-in to record real instruments makes it an incredible mixing and arranging tool.

Roland TR-808, and the classic 16-step drum sequencer.
We haven't moved much past this for drums and synth lines.
It's all about the ideas. Rebuilding a cheaper and more portable version of something old is step one, but running with that old concept and making something new is the next step. This means breaking the mold, thinking outside the box, and not being afraid of failure. Presenting instrument tracks as 3D interactive planets, or adjusting the alpha channel of their colors to display their relevance in the mix, or drawing on modern empirical response studies and data visualization techniques to generate a good overview of the musical concept you are trying to put down are examples of things developers haven't tried.

I put stuff like this on this blog because I feel they have relevance to the general world of software design. What an amazing time we are living in.

Thursday, December 1, 2011


We've been having a hell of a (great!) time stitching together a new creative process with a new team here in the office. The company is already producing some really great 3d models, and I have been hired to head up the software effort to make those models interactive. Go touchscreen, go!

Something that has struck me lately is generally how bad developers are at PROTOTYPING. Now don't get me wrong, I don't mean this in a negative way. Instead I think that our tools have held us back for a while, but our tools are getting really good really fast and I think we have a lot of work to do in order to find a place in the creative process.

I've been talking to freelance developers and a few studios trying to find the right people to build a couple of key visual components for our first big job building touchscreen interactives. Meanwhile, we have been working hard to get our conceptual design done in parallel. So I'm having a look at how we are communicating our ideas and finding visual examples to illustrate what our ideas actually MEAN - and the whiteboard is just not cutting it.

Sure we still need the whiteboard, but not for more than a conversational tool. What we really need is to spend a smaller amount of time describing what we need, and more time building real examples in a timely fashion. A picture is worth 1,000 words, and here an animation is worth closer to 10,000 words! The only goal here is to produce a rich touchscreen experience, so this stuff is super important.

I'm getting the idea that most creative companies have their people make a bunch of prototypes, and then they go with the best option (Anyone seen Mad Men? Read a Steve Jobs book?). This means you have to burn time, and you also have to master your tools so that you can spend your time thinking about the big picture and less time thinking about the code. This brings me to my point.

I am looking at where we are as developers and I think that we are juuuuuust almost there - at least in the visual and interactive design realm. We need to take the next step and get even better at our tools so we can do this. If a client comes up with a concept, we shouldn't need to have them spec out the whole animal for us before we build something. Instead we need to be so good at our tools that we can put all of our effort into interpreting the big picture and the code is nothing more than an after thought. I mean, we can spend all day talking about methodologies and "agile" and waterfall whatever blah blah blah, but at then end of the day we need to be able to quickly write something or a few somethings "for free" to get a tangible illustration of the idea in front of the right people at the right time.

I think this means for a WebGL or CSS3 interactive we need to be able to turn a working example around in a couple of days. Then when someone says we need to rotate the camera around not one but all objects in the scene at once, we need to be able to turn that around in an hour. If we want to turn all the circles into squares and have them rotate around the axis instead of constantly looking at the camera, it should take 20 minutes.

You can see how these ideas would be hard to illustrate since there's several ways that we can interpret these simple few statements. Seeing it work is everything. Also it's important for a developer to not take the instructions literally but to interpret them as solutions to the problem, and write prototypes that solve the problem. No one likes a monkey.

On the same note, we eventually narrowed our focus to only hiring guys that have portfolios of prior work to show. We needed to SEE what they've put together to get a feel for what they can do. We also gave them a couple of days to put together a prototypical example of how they would approach our problem - off the clock. This seems to be the way of business in other creative industries, and I think it should be the way it works with software as well.

Friday, November 11, 2011

Thursday, October 27, 2011

Open Terminal from Finder Window

- Create an automator application with the following AppleScript and save it somewhere.

on run
  tell application "Finder"
      set frontWin to folder of front window as string
      set frontWinPath to (get POSIX path of frontWin)
      tell application "Terminal"
        do script with command "cd \"" & frontWinPath & "\""
      end tell
    on error error_message
      display dialog error_message buttons¬
      {"OK"} default button 1
    end try
  end tell
end run

- Right-click the finder toolbar and customize it by dragging the automator application onto the toolbar.
- Change the automator application icon by running "Get Info" on as well as the automator application, and dragging the large Terminal icon onto the icon for the automator application. It should change in the Finder.
- Open a Finder window, navigate to a folder, click the button.

Make this

And you'll get this
Then you'll get this

Saturday, October 22, 2011

New Twitter Account

I've separated my athletic / personal twitter account with my software / music / art twitter account. The old "pkaudio" is now called "plasteredskier" and I've created a new empty "pkaudio" account. Hope to see you followers back there again.

Wednesday, September 14, 2011

Separation of Ego and Will

I believe the path to enjoyment through excellence lies through the heart more than the average athlete. The Ego drives so much of our lives, and thus can quickly get out of control and throw our lives of course. Because of this, it's easy to think that removing the Ego from the equation would coax forth an untamable beast of pure power and athletic perfection.

About four years ago I remember a day where I found a really nice rhythm on the track, sort of like a place to put my mind while pushing my body over the limit. I remember imagining a max pace that would work for that distance and then just sort of hang my body on it, like a person hangs a coat on a hook. It felt right because it was juuuust the right balance between fast and slow for that distance. I was amazed at what this small change in attitude did for my performance.

I didn't know it then, but I was getting my first glimpse of a balance between Ego and Will.

The "Ego" is your rational mind that drives you to compete and judge yourself alongside your external world. It is the ego that keeps you alive, and conversely it is the ego that causes performance anxiety.

The "Will" is your innate, inner tendency towards peace. It is the subconscious personality that thrives on warm fuzzy feelings, or gives you that incredibly serene sensation of unity that comes on a solo day in the mountains when you could care less about races and glory. The Will is a factor of the "you", if the rest of the world didn't exist.

All of us in the western world are very well acquainted with The Ego, myself included. For the past few years I have been trying to learn how to run purely by Will, keeping the ego and its mischief out of my experiences. I have believed that there is an animal inside that wants to run and become strong and conquer all, and the true meaning of success meant letting this animal drive 100% of my athletic life. Today I don't think that this is the case.

Just like that day on the track, I think that pure life (and fast race times) comes from a balance of The Ego and The Will. Not only is this balance extremely difficult to find, but it requires that you have a comfortable relationship with your Ego, and a comfortable relationship with your Will, both as separate entities.

For the average American, learning to listen to your innate Will *alone* is the challenge of a lifetime. Learning to play with both, and then demonstrate the fine balance required to crush a race without anxiety and with predictable gratification is a challenge for only the most elite of athletes. I feel like less than 1% of any community truly has this balance.

I've had a couple of good runs with this on my mind lately. The next time I head out and start to push it, I'm not going to crush my Will into submission like the usual hammerhead. But I'm also not going to shut out my Ego in favor of endless calm and peace. Instead, I'm going to ask both what each is feeling at the same time, strike a balance, and crush forth with endless calm.


Tuesday, August 30, 2011

Two Parallels

In music, we figured out how to get machines to make music for us, and how to use a killer sample or two to make it sound good. But, our listeners are getting tired of hearing a killer sample over and over again. Now, our challenge is to get our music back to a level where the entire song uses unique, expressive, humanistic elements.

Time to raise the bar.

In computing, we figured out how to get machines to remember everything for us, and to recall and reshape it for us faster than we ever could. But, our users are growing tired of us saying "I'll just add a checkbox for that." Now, our challenge is to make the checkbox go away.

Time to raise the bar.

Saturday, August 27, 2011


It occurred to me the other day that a major flaw in the new technologies that we are enjoying so much today is that very few of the incredible works they are allowing us to produce will be around for very long. This makes me very sad.

For example, if a graphic designer sits down and produces an incredible web page and loves it like a piece of art, he may not be able to enjoy it again several years down the line because the programs that allowed the piece of art to took, behave, and feel so inspiring will not exist in the state that they do today. The font rendering may change, or the browsers will not support the programming language, or we simply won't have web pages.

Sadly, the same goes for some forms of music.

In my last job I developed software-based musical instruments that relied on a custom engine to play the thousands and thousands of meticulously recorded audio samples used in to reproduce a single instrument. These instruments were beautifully crafted by sound designers and recording engineers through months and years of work. The engine runs as a plugin inside mixing applications that rely heavily on the bleeding-edge technologies of today. Thus, it is likely that all of our years of meticulous toil won't even make it past the next operating system version because the plugin standard may change, the host software may not be supported, etc. A small piece of this work may live on in the musical recordings they were played in, but the instrument itself will DIE. And it will likely die very, very soon.

So I want to ask: Are we considering this extremely unfortunate loss as we cruise blindly into this high wave of technological expansion? How much art will we lose to this sad fact, and how much have we already lost? With the exception of old-style, static media like photos, videos, and audio, do we even consider the interactive and functional art that we are making today worthy of being saved?

If not, then that would make me saddest of all.

The Long Now Foundation is devoted to exactly this startling fact of modern impermanence. 


I wanted to call this post "giddy", but it turns out that word means "having a sensation of whirling and a tendency to fall or stagger; dizzy". Not really the feeling I was going for.

But, I digress.

I am elated at the direction the web is going in. I am most excited with how far from "web" the web is actually becoming. Watching the web browser become the future of visual expression is exciting, and while in some ways the HTML/CSS/JS triumvirate is tearfully clutching pieces of the technology that really truly, it's story is a wonderful example of an organic and purpose-full evolution.

It started out as a simple way to link together and transmit simple text documents, and after a long, strangely stitched labor, it is giving birth to inspiring new ways of visually expressing ideas and information. I mean, JavaScript used to suck, and it can now be used to generate incredibly smooth and colorful 3D content (canvas, WebGL, etc...). I'd say I was excited when I saw python for the first time in 1999, but I have never been this excited about anything related to computers before.

This is because I feel like computing is finally growing up. It is no longer strange but is now mainstream, and has rich purposes that people can relate to without having to think that a computer is even there. Today we aren't so much trying to get computers to help us do things we have already been doing for centuries, like allow us to read books, look at paintings, or just play chess. Instead, they are finally allowing us to do things that we have never been able to do before.

We can create new kinds of music that would have never before been possible. We can express new ideas in new ways using animations, interactivity, and multiple media at the same time. We can create fine art that becomes new art all on its own because it interacts with other art. Above all, we can actually be more creative.

Because of this, I am in awe and inspired by the "web". If the true test of a language is implementing itself in itself, then the technology of computing is redefining this test because we have used programming languages to invent new ways to write programming languages - the web browser is becoming the next generation of the computer operating system. Standing on the shoulders of giants we are, no doubt.

Three.js: The page that inspired this blog post.

I was talking with someone earlier today about some work involving interactive presentations, and realized that I was starting to think so far outside the box that the computer part of the equation wasn't really part of the equation any more. Sure, we know that we were going to use computers for the job, but I wasn't really thinking in terms of what the technology would allow us to do; instead I was thinking in terms of what we wanted to do for the job.

This is an incredible success for the story of computers.

In this case the success is largely credited to the fact that web browsers kick so much freaking ass right now. And they are kicking a few more asses every day. We are getting flexible tools, rapid prototyping, and performance that was hard to imagine just five (five!) years ago. All of this means that a decent developer with mediocre web experience can sit down and produce something that can blow his clients away in a relatively short time frame if he has a good idea. In my humble opinion, this is the very definition of success in design.

Thank you to all the giants for all the amazing tools that we are enjoying today.

Sunday, August 14, 2011


A quote from a really good book:

"Design is a process of making, it is the transfer of ideas to a surface by means of tools. Eric Gill used the image of a hand and eye as an emblem in his design. Graphic design exploits the visual and sensual in equal measure.

"If the computer deprives us of anything in exchange for its bounteous gifts, it is the physical pleasures of making. When using the (near redundant) letterpress process, every action has an effect: if the ink is carefully thinned, it prints thinly; if the colors are bled, they print that way, but differently each time; you can see the dust from the paper swirling in the sunlight; you can hear the treacle crackle as you ink the roller; you reel at the bitter smell of the turpentine. Each little piece of type bytes itself into the paper. The surface of work printed by letterpress undulates minutely - the type sinks back, the ink has a sheen. Each print differs, even if only by a fraction, from its fellows.

"This loss of sensuality is felt by even the fiercest devotees of digital design: 'What I really want on the Macintosh is a virtual reality interface - armholes in either side of the box so you can reach in and move logos around; a real paintbrush so you can feel the texture of the surface underneath', says Neville Brody.

"Perhaps the most important tool of any designer is the voice: calming, cajoling, questioning, and asserting. Design is above all else a social activity: event the simplest letterhead might involve lengthy meetings and discussion with a long cast-list: client, assistant, photographer, plat-maker, printer and paper supplier. The needs of every cast member may vary."

Monday, August 8, 2011

More Bliss: All-Keyboard control in OS X?

Speaking of bliss... I was just recalling the blissful days of WindowMaker and writing code using nothing but emacs and an xterm. Sub-80 chars and python-mode syntax those were the days. The only thing I used the mouse for was to position and resize my windows once at startup, and I rarely did that because my default wmaker session did that for me! Not using the mouse was so FAST.


Whew! I had to take a breath for a second. Here's a previous post about the same thing, and here's one from another guy on the same page as me.

These days I use OS X, and I realized how distracted I've become from that special place in my programmer heart! Have any other developers managed to remove the mouse from the equation in OS X? What tricks do you use to keep yourself on the keyboard as much as possible? Shortcuts keys? Apple scripts?

Peace out.

Sunday, August 7, 2011

Money in the bank: CSS Text Wrapper

Web designers: Say you have a shape on your web page and you want to shrink-wrap text inside or around it. Go check this out.

So cool.

Friday, August 5, 2011

Reaching the top: Pure Bliss

Have you ever reached a state of pure bliss with your code, or technology? Like when you feel like your skills AND ability to see the big picture both reach a high point so that you are able to actually *express* yourself like an artist. It seems like this is only possible when you specialize with a given toolkit and really get your fingers into it, allowing you to actually turn out products at the rate that clients initially EXPECT you too. Pure bliss.

There was a time about 6 years ago when I had barely reached this point doing GUI programming with PyQt. I was able to come up with an idea AND prototype it fast enough so that I could build on the idea without losing the creative spark. A bunch of nice python libraries (including pyrtmidi) came out of this time.

Since then I've been forced to change technologies often enough that I haven't been able to really make things sing. This is an interesting phenomenon.

First it was moving from Python to C++, but the slow link/build times were a total show stopper.

Second was writing a Python-based realtime musical effects engine, with features for authoring SWEET custom GUIs. This one had potential for expression both through the GUI programming and the musical effects, but the project changed directions and I found a new job.

Third is HTML/CSS/JavaScript. Here I am today learning something all over again. Sure, it's great having a wide range of skills, but man it would be really sweet to actually hit the elite level for SOMETHING and actually have a shot at experiencing pure bliss.

You know what I mean, right? Like when you run across a project and get that "woah" factor...Man I miss that.

Saturday, July 16, 2011

Managing Software Projects: When has it gone RIGHT?

It occurred to me yesterday that I have never seen a software project managed well. (Almost) Every project I've worked on has had the fortune of excellent talent that has delivered and made someone money, but the developers always get burned out doing it.

Is this just the nature of the industry? Is it not actually as profitable as we once thought? Sure, it seems that there is never enough time or money in any business, but I just have this feeling that it doesn't have to feel as catastrophic as I've seen it.

My very humble hunch is that we as developers (and people) have not properly asked ourselves this one question:

"What do I have that will allow me to do this better than it has been done in the past."

I think that too often our answer is: "We have good skills, and we are ambitious," and I think that that answer is not good enough. I think that software is still new and not enough of us have an experiential understanding of how software (and developer resources!) mature through development, testing, and maintenance phases. If we do have that understanding, I think we are not good enough communicators to apply it to our boss' and clients' expectations.

A lot of us has read the Mythical Man Month, but has anyone actually been on a successful project? Has anyone been happy enough with the life cycle of a product to be willing to go through it again in the same way? If so, I'd really love to hear about it.

Saturday, July 2, 2011

Scaling with Virtual Machines

One new thing since my real-world hiatus in the music industry is the prevalence of low-cost (like free) virtual machine software. They're cheap, they're stable, now we have linux and windows wherever we want, we can all own macbooks.

This idea is extremely intriguing when you start applying it to deploying server software. It seems to me like we would ideally be deploying a new virtual machine for every app in order to sandbox the application and it's environment. Yeah, a lot of us are stuck in the old timeshare paradigm, but let's look at it in terms of the next level.

The Desktop

Start with a developer's desktop machine. I have a maxed-out i7 macbook pro, and run Windows under VirtualBox for IIS/Visual Studio/Office/etc. Then, whenever I start a new linux app, I just tack on a new virtual machine with a hostname matching the project.

With all machines using a single Mac shared folder, I get to use my favorite app to write code (Coda, in my case) and work within my mac environment. I generally never even look at the virtual hosts' window, just use them as if they were a server somewhere in the closet.


The Servers

Now this gets really interesting when you start thinking about deploying servers. Ideally we would have one box with an infinite number of virtual machines. Ideally, the OS overhead would be negligible. When you release a new project, you fire up a new virtual machine, install yer stuff, and add a DNS entry. No more site-wide broken apache configs, no more runaway processes, everyone has sudo where they need it with none of the risk. Once you own the hardware, you can do this as much as you want.

In that world hosting is not a problem anymore. You buy hardware resources in bulk and parcel out the pieces.

This is where we are going. I wonder how long it's going to take us to get there?

My release schedule

0) Throw that dumb DDD/FRD schema you learned in college out the window.

1) Gather requirements. Talk, meet, and outline as much of the system as you can with your poor human brain. Make sure you know your tools well enough to ask the right questions. Compile a list of atomic features that can be checked off by a tester for completion. Call it the FRD. Make estimates.

2) Implement a working version of the features. Anything obvious that they do, they should do well, but they don't have to do EVERYTHING. Show prototypes to the client for feedback on potentially confusing features whenever possible. Update estimates.

3) Review the running code with the client to ensure that you haven't forgotten any functional requirements. This does not include bugs. You must learn this difference. Get a final sign off from the client agreeing that the FRD is complete and no additional features are required. This is absolutely critical for your sanity later.

3) The code is now in "beta". This isn't the stupid flash word that is overused everywhere to mean "new and cool". It means that the client is seeing the code run and providing feedback, and no new features can be added. Only bugs can be fixed, and only without causing new ones. If the client cannot be held responsible for putting the time in to test the code, then you need to find someone that can.

4) When you feel like you are getting down to the last few show stoppers and you as a developer or project manager feels that the system is stable enough to release, start talking to the client about a deadline for bug submittal. There will always be more bugs. It will never be perfect, but it WILL be USABLE. If they thought that they were paying for perfection, direct them to the nearest meditation hall and instruct them that perfection is only found within.

5) You are gold. Or, at least your code is. Compensate your employees as well as you can while retaining enough capitol for the next project.


Beware the "cool" company

"Office Space" changed everything. The cubby has been a known death-wish for several years. Grey walls, beige boxes, dorky ties and coffee mugs. Screw that, right?

These days you see a lot of companies steering clear of that dead and dying image by sprucing up their offices, having more fun group events, shooting toy guns at the bosses, stuff like that. We all think of Google.

However, beware the "cool" company that wants to be all of those things, but doesn't have the integrity to back it up. Anyone can paint their walls brown and orange, and buy goofy chairs, and talk about how fun it is to work there, but this is not to be confused with signs that the company is actually SUCCESSFUL.

A group is only really killing it if they are getting shit done first, and being nerds second. When you have pleased the clients, mastered the process, and provided increased security for your work environment, then we can talk about taking off early every day because we are "so laid back."

"Laid back" companies have either mastered the craft (very rare, you usually know about them for THAT instead), or because the market proved them lucky, which means they will as easily be proved unlucky.

Tuesday, June 7, 2011

Steve Job's 1997 re-hire keynote

Steve Jobs’ ‘97 WWDC keynote after being rehired to rebuild apple. Back then they still said “Rhapsody” and “Networking”. The most compelling part is that his message has always been the same even through the iPhone “antennagate” flak: "Stop bitching and build a better product than us."

“The reason Apple was successful is because we weren’t trying to build a company, we were trying to build a computer.”

Solid gold.

Saturday, June 4, 2011

And I quote...

"But none of this answers the original question: why do we have an element? Why not an element? Or an element? Why not a hyperlink with an include attribute, or some combination of rel values? Why an element? Quite simply, because Marc Andreessen shipped one, and shipping code wins."

"Scripting is here to stay, but should be avoided where more convenient declarative markup can be used. Scripting should be device and presentation neutral unless scoped in a device-specific way (e.g. unless included in XBL)."

I'm not sure that scripting should be avoided where possible in favor for declarative markup. My reasoning is that in order to get a page to DO ANYTHING you have to whack the declarative markup on the head to get it to change. How do you do this? JavaScript.

I do, however, strongly agree with keeping the languages as neutral as possible. Ubiquitous support and good, fast debuggability is key for developing any app.

Thursday, April 21, 2011

The Beer Code

I've noticed lately that you can work so hard on a problem that sometimes it actually helps to stop, drink a beer, and go at it again with whatever the beer gives you on the way. It's like there's two modes of thought, one that works with a clear head and maybe some coffee, and another that taps into that lazy, Chappelle's Show and a High Life kind of attitude that can actually be quite productive if taken in stride. Interesting.

By the way, I did not type this while drinking beer. But, I am about to crack a High Life and get into some Backbone.js :)

Monday, April 18, 2011

The New Thing

Javascript is the new thing. About five years ago I got a little tired of the explosion of web frameworks and moved into compiled programs and music software. Now, after a long hiatus, the web is completely different. Now we have that javascript debugger I was missing all those alert()s ago, and the same code (pretty much) runs everywhere.

Now here's what I see coming in cold.

We literally have ubiquitous support of a high-level language (javascript) in the whole world's hands (mobile devices), and it has access to cutting edge graphics technology (html 4/5, etc). While before OS's were struggling for streamlined and unilateral application support, the browsers have climbed and dismounted that ladder on the roof of the platform game. The web browser is a virtual machine that is poised to become the next host for desktop applications. Now it's just up to us to get better at doing that.

Yes, I mean *desktop* applications. The term "client-side" should go away. We should write more javascript and ditch the stateless paradigm. We've already a great RESTful concepts (http/JSON) to harness our massive distributed resources, so let's get going. We need to start writing javascript like we write C++ for native apps, and improving on the markup (because right now it totally sucks).

And why not? Google has apparently invested millions getting their javascript engine to run faster than CPython. Safari and IE are right behind. Everyone supports it absolutely everywhere. The debuggers are getting better. jQueryUI style coding is where it's at. Now we just need to write more code.

Go! Go! Go!

Friday, March 11, 2011

VirtualBoxVM == Excellent

Boy I'll tell you what, a bad job is like a bad relationship (I'll leave drawing the parallels to the following description as an exercise for the reader). At first you are excited for the prospect of something new and everything's great. Then if the stars aren't aligned for you, you start to get cranky and any possible gaps in communication now pose a real threat to your happiness. If you were a contractor, quitting is less clear because they can always send an email asking for help on something small. Next thing you know it's one year later and you have no idea what your status is, but it occupies enough space in your mind to become a problem. Eventually you have to cut all ties and go cold turkey, or face an eternity in limbo.

Once you are "free" of any previous obligations, you are able to start looking for some new ones ;). If you previously rose to any challenges provided to you, you may choose to aim a little lower next time to give your mind and body a break.

Anyway, I'm looking at starting a new job this week at a consulting firm here in Anchorage. This time it's salary, writing C# swag for the state and local telephone companies. It's not exactly (nearly) as exciting as building virtual instruments for Hollywood score composers, but I am glad to take on a workload that is "light as a feather." But, being a mac guy I'm not too excited about the prospect of using Windows full time.

But lo and behold, Oracle's VirtualBox VM is amazing! I hardly notice the speed bump on my i7 macbook pro, and I can just cmd-F to full screen Vista while running Mac OS X. The Dock still works well, and all the iTunes hot keys on the keyboard work. The integration is so smooth, I'm actually looking forward to this.

If you have a decent mac machine and need to use Windows, try Virtual Box VM. It's free and works extremely well.

Tuesday, February 1, 2011

Enough with the "BETA"

Hey commercial guys: Enough with the "beta" tag! We all know you are just trying to find a cool way to say "kinda new", but it doesn't really buy you any credibility despite the "bugs" it may have. A feature that is fully deployed as the second tab on's from page is by definition not "beta".

We know software isn't perfect. We're over it. You should be too.

Wednesday, January 26, 2011

Signposts in Shark

Shark is a pretty badass profiler. I don't know much about the mach internals that let it do it's thing, but it's pretty sweet.

I've been trying to get a handle on the performance of my python-based scripting engine in the audio thread, and have found setting sign posts extremely useful for a system trace. A system trace provides a timeline view of all the threads in your app or system, and you can use sign posts to display when a particular event is happening. If I set start and end signposts around the script execution phase, I can see just how much of the audio period the script engine is taking up. This is huge.

Shark System Trace. The Audio thread is second from the top.
The above is a screenshot of a system trace of about 5ms, indicating a timeline of each thread in my audio application. The gui thread is at the top, the audio thread is second from the top, and the rest are disk streaming threads, watchdogs, etc.

The 5ms of execution shown above is a particularly busy audio buffer period, where the scripting engine is really close to causing an overrun and high cpu usage (and scratchy audio). The first set yellow line and green telephones indicate the previous audio period. Then the next audio period starts with a yellow warning sign post marking the beginning of script execution, and each blue telephone is a system call to release or acquire a semaphore (semaphore_wait and semaphore_signal). Then you can see it barely finishing before the next audio buffer, marked by yet another yellow line.

Whew! That was a lot of effort. Anyway, sign posts rule.

Humans VS Computers: Humans +1

It recently struck me how definite the line between musical phrases and structures that are machine-like and which ones are human-like, and how important it is that music includes the human structures. For example, imagine a robot voice telling poetry. That's sort of what electro-techno can be like.

I write this because I am a computer programmer, and am heavily into electronic music. Like heavy heavily. Lately I've been spent quite a few of evenings on the internet listening to new music that has a strong mix of modern electronic elements and more organic parts like guitars and voice.

Bands like Lusine, Lucky Shiner, Sister Crayon, The Notwist, Made in Heights, and of course, the extremely famous Radiohead, are all discovering new ways to impress their humanistic creativity upon the functions of their technology. Vocals over cheap gameboy drums. Chopped guitar loops triggered with eyes closed and emotions running high. Wurlitzer keys gapped and glitched perfectly to print the message of emotional-technological conflict in the author directly into the passage. This is an important step for us because I believe that most people still see a very black and white relationship between technology and music - it's either techno or it's well, music. But even through all the techno-lacing over the last 30 years, a listener can still tell when there's a person hidden behind the curtain or not. The existence of this human element is what makes good music good music. Replace the poetry robot with William Shatner and it's well, at least a step in the right direction.

Check out the end of Two Dots, by Lusine in the following video:

In the last minute or so, Lusine's use of the female's voice is absolutely brilliant. The timing and selection of each voice sample is chosen with wonderful precision, which overwhelms the pragmatic critic's mind in the way only true human expression can.

I am so glad to see the beginning of the techno thing starting to really hit home on the human thing. Dance hall anthems rely heavily on the machine pounding of a new fat-bass sound or a rhythm hammered mechanically into the listener's body, but will also fade from the listener's memory in time. Real, timeless music has more of that human message through expressive use of technology, whether it's a violin, or an MPC-5000. No matter how much modern producers "ruin" music in the same way that modern shoes have "ruined" running, the basic rule that it takes a human to touch a human will aways hold true.

That's why I have infinite faith in music.

Thursday, January 6, 2011

More Zen, Man!

Not the first time for this topic. Not at all..

You ever look around on the internets and see some projects that speak to you a little? Like you see "Download in FLAC, MP3, OGG." And then you think, "FLAC? really? for an album? dang. ...I like writing headers for audio formats."

That was random, huh? But it's the little things like that that are important to remember when you dive back into optimizing 10,000 of rpc code, or figuring out why your stupid Qt combobox pop-up looks a little different on mac. Shit.

I'm tellin' ya man, those simple things are the things that really get our gears turning. When you finish a major work of complexity, what is it that you appreciate after it's done and works well and everything? It's the feeling of sitting back and feeling the simplicity of the function painted plainly in contrast to the complexity concealed within. It's like an instant of grace that happens like 1/100 minutes that I work on any given project.

Recently I've been tasked with moving from writing more and more docs on the scripting engine, to trying to cut down on the system calls made to the mach kernel to operate the pipe between audio->scripting processes. This shit is super complicated. There's #ifdefs, and // german comments, and mach calls VS win32 calls, etc.

Then I take a step back and get tapped on the forehead with the thought of a FLAC header. so simple. I cant wait to be a project lead in a time when I have the resources to make my own decisions. What an idea. Man-power available for good testing. Some sort of loose but consistent process for tracking workload. Individual responsibility depicted in a simple progress-bar (thank you trac).

But most of all, the greatest simplicity to toss into that "back in the day we yusta'" talk, is the simplicity if the finished product. You load and play an instrument, add another and a side-chained compressor, and get off to dance-land. There's no more audio locks, xml attributes, platform-sepcific code, no more multi-national arguments about the overhead of a semaphore lock when the semaphore is guaranteed free. Jesus.

In code, the next best level of simplicity is to have the time available to you to sit down and just dig your little fingers into the steaming guts of that knob's painting routine. It's an ellipse. With a two-toned bevel. On one side only. Fuck the bevel, just antialias. Small value text, extremely accurate integer and float value representations for any unit. dB Hz % ms. All as good as the other.

Bring it back, baby, just bring it back. Get right into that knob, and just make it as nice as you possibly can. Then move on to the next thing. Ahhhhhhhhhh. peace.

Looks like someone had a good day designing.

Thursday, December 16, 2010

No Work in Alaska

Finding developer work in Alaska sucks. As far as I can see from growing up here, it's very difficult to find anything other than a C# web form developer for something that eventually just supports the oil industry.  What a contrast after spending time close to the SF bay area.

After years of telecommuting, living in your home office can get very, very old. You wake up at work, you work, and when you are done, you are still home. Most of all, you never get a chance to see real people, and your social life takes a hard dive.

The same old question pops up for me again...mountains and people that run and ski and hike, or a killer job. Damn it.

Please Stop Misguiding Our Youth

 Abhi: I'm going to disagree with your last paragraph, but only on a very nit-picky kind of way :)

I believe that it is easy to confuse hiding data with providing a clean interface. The idea of a functional contract between components does not *require* any kind of restriction, it simply requires that the interface through which the function is provided does not change.

This contract may be provided in the form of documentation, naming conventions, even a simple phone call to describe that single method used as an entry point to a library. It can even go so far to say that a contract is made by simply keeping the client code ignorant of internal attribute names, so that they won't use them. If you hack the library to find and use the internal symbols, you should not be surprised when the library starts acting weird, right?

The public and private keywords are specific to languages like C++ and java, and the only reason that I could see a use for them is if the person writing client code was actually reading the headers that defined the class. Including type headers (which is only a convention!) is a language-specific thing, and do not *facilitate* this contract, they only provide a semantic (compile-time!
) helping hand for a language's *implementation* to remind a programmer that they are breaking the contract.

If I were teaching an OO basics class, I would not teach that "encapsulation" is necessary for object-orientedness. Instead I would focus on the idae of clean *abstraction*, which is the separation of components to ensure that one can be changed without affecting the other. This can be just easily be achieved by providing a wrapper class, or naming methods using an underscore convention like "_handsOffThisWillBreakTheContract", or simply keeping the names of the "private" methods and attributes out of the docs, whether those docs are defined as the html user docs or the class header file itself.

I will say that I am tired of hearing that encapsulation has anything to do with object oriented programming. Shoot, even abstraction is only necessary  in *some* cases, and it can just as easily be achieved in a structured language like C, and so also has nothing to do with object oriented programming.

The "object oriented" concept provides nothing more than a thin semantic helping hand, in the form of a real-world representation instances of stageful types that provide a function. Everything else is nothing more than language implementation.

Thursday, November 18, 2010

Python/Music Talk Tonight at BayGiggies in South Bay

I should have thought to post this up here earlier, but I will be giving a talk at the BayBiggies meeting at Symantec tonight at 7:30 California time. The talk is entitled "Embedding Python as a Realtime Audio Scripting Engine", and this is the summary:

Topics will include separation and communication between the
application and scripting engine, why Python is "safe" for audio work
including empirical performance metrics, and caveats related to
multithreaded processing as performance requirements increase. I will
share my experiences using the standard CPython implementation to
research and develop a state-of-the-art audio scripting engine.

At least there's something happening even if the economy did take my job!

Here is the BayPiggies link for more info: