Building Ambisonia.com

Having an idea is one thing. Delivering it is an other. To deliver, you have to make choices about technologies. Making the wrong choice can significantly handicap.

Choosing Plone for Ambisonia was a mistake … as soon as you try to do something outside the box, Plone pushes you into a maze of convoluted gotchas and forces you to be intimate with its over-designed internals. Moving to Rails has so far proved to be an empowering God-send.

Years ago, I chose Java to embed a little network visualiser into web browsers. I had a gut feeling, at the time, that I should have chosen Flash. A couple of years later, when my GUI just wasn’t “taking”, that gut feeling was confirmed. Technology choices.

At first I implemented the Ambisonia uploader in Tcl/Tk. Had to be cross-platform, and Tcl/Tk fit the bill. But it was a dog to develop … way too many lines of code to do simple things, and then packaging the apps for easy installation was simply not possible (for my skill set).

Then I discovered shoes by “_why the lucky stiff“. _why hit the nail on the head with his message … a cross-platform GUI, with a powerful simple API, with a ‘package’ feature for making installables on all 3 major platforms… and a focus on creativity.

Shoes also has hooks into Portaudio … you know what that means? … it means the Uploader could also eventually become an Ambisonic audio file player. As I said, Shoes hits all the right buttons.

I dug around a bit, saw that there was good activity on the list, initial tests seem to work quite well … “ok”, I thought, “I’m diving into Shoes”. Progress was quite fast, there were some ‘issues’ that I needed to work around, but that is to be expected in a new application.

I eventually completed the uploader to 80% … all functionality was there, just needed polish. I then attempted to package it for windows … and that’s where the problems started.

Its now a couple of months later, _why seems to have been side tracked by other projects and more and more bugs are being reported on the Shoes list, mostly falling into silence. Ok, so _why is a very talented developer, with his finger on the pulse … and I’m sure that the other projects he is working on are very much worthwhile. And, yes, ok, so open-source software comes with no garantees … its use at your own cost… and “fix it yourself”.

I’ve had a dig around in Shoes, and the “fix it yourself” moniker hits hard when you see that many things (such as HTTP implementations) are done via hooks into C++ code. Urghhh, C++ ….  its been so long.

So using Shoes is _perhaps_ a bad technology choice. I say _perhaps_, because Shoes might still come good. I hope it does, because I really think it hits the mark. But for now it looks like it is a bad choice. Too early. It doesn’t deliver on its promise of cross-platform executables, or GUI consistency (things just look too different on different platforms).

Right now I’m coding up all sorts of convoluted ‘work arounds’ to try and get the Uploader working on windows. I’m not going to worry too much about the polish… I’ll just explain to my users that its all very alpha. … and then I’m going to pray that _why gets some wind back into Shoes, that he implements a bug tracker, and that other developers start to dive in and take part-ownership of the code…

My father fought in the Algerian war. When I look at the tiles in my bathroom, I always think of him. Whoever repaired those tiles couldn’t see the wood for the trees… or the tiles for the pattern. I wonder what he/she was thinking at the time. That’s my son, Dylan.

It was when Kevin Rudd, the current Australian Prime Minister, first took the reigns of government that he was accused of working too hard. He made no apologies ofcourse, and at first I thought it was an absurd accusation. But an ex-Prime Minister of the same denomination, Paul Keating, said it was a mistake to work like that, because one needed time to think. Time allows the dust to settle and thoughts become clearer. Without time, there is greatly reduced clarity.

Now, I know that many people have lost patience with Ambisonia. The current site has not moved in a long while. Over the past several years I have had email communication with a number of people enthusiastically engaging with Ambisonia, only to see them eventually lose interest. Understandably so. I guess if I’d been smarter I would have pulled some financial assistance… and the site would have moved faster.

None the less, I’m still here, and I’ve had a hell of a lot of time to think (whilst looking after my 14 month old son).

Today I “surrendered” to something that has been pestering me for a long while. I realised that it had been pestering me for a long while by the un-anticipated sense of relief I felt when I decided to surrender to it.

It is the uploaders who should support Ambisonia (not the downloaders). Ambisonia offers a publication service. It offers ‘access’ to audience who know how to consume ambisonic content.

One of the early rules that I had set for myself was that I needed to optimise publishing volume. That meant not charging for uploads. I had to find a way to charge the downloaders. Micropayments for music are very difficult to do, but there are strong signs that patronage (or voluntary payments) could work. So I decided to go with patronage.

And I still intend to build-in a patronage system (to generate revenue for the uploaders).

But I cant rely on that to be the bread-and-butter income of the site. Its too risky. Because if it doesn’t work then I’ll be racking up lots and lots of bandwidth and storage costs, and that has the possibility of knee-capping the whole site when one spritely morning I wake up and realise its either the site or the mortgage (i.e. my house).

Its fascinating that the business model of a venture can either come from the producers or the consumers. Its a strange question …. should I charge the producers, or should I charge the consumers.

I guess its the kind of thing that business school students write essays about.

I was trying to think about the similarities and differences between Ambisonia and SoundCloud.com. SoundCloud have a simple model. Pay by the month and use their service to publish your work (amongst other things). I always thought that Ambisonia would be more of a YouTube.com model. Its free, “get lots of content up and work out a business model later”.

Later is now. Ambisonia offers a publishing service for producers working in Ambisonics.

This, perhaps ‘obvious’, business model does have some significant advantages. Downloads (of 5.1 material) can remain free. Downloads of the *.amb files can remain free (instead of the messy subscriber model). And producers can still make an income (via patronage).

The “new” Ambisonia is only about 5 full days of work away. It’ll probably take me a month to get that work done. But now that I’m finally feeling comfortable with the business model, I’ve got a bit of extra energy.

There’s lots of talk at the moment about the financial meltdown and its effect on the technology industry. Online advertising revenues are drying up.

In tandem with that, the news industry is losing their ‘print’ revenue and so are forced to focus online. More and more people are using online resources to consume their news, and buying less newspapers… but making money online is difficult. Specifically, charging for online news is simply not ‘accepted’ by the Internet going public (essentially thanks to Google’s free-conomy).

The re-consideration of how to charge for online services is very appropriate to Ambisonia, ofcourse. This little TV segment is extremely interesting. Its a conversation between Walter Isaacson of “Time,” Robert Thomson of “Wall Street Journal” and Mort Zuckerman of “The New York Daily News. They discuss a number of things.

The current financial meltdown is potentially a good thing, as Nick Carr speculates, for the online service industry. If I understand him right, he is essentially saying that reduced online advertising revenue and reduced technology investment capital will effectively ‘cull’ the weaker businesses. This will reduce supply, and therefore increase the acceptable cost of good services. Perhaps paying for subscription services will now be viewed as more ‘acceptible’.

I hope so.

Some mornings I wake up and I think I cant really go from charging nothing on Ambisonia, to charging something … markets really really dont like that.

Other mornings I wake up and think, I simply cant keep Ambisonia going, with a family to support, a mortgage to pay, and (with children) an ever-dwindling availability of ‘free-time’. I have to be brutal and charge.

Ofcourse, what I am currently implementing is kind-of half way. Yes, I _am_ removing a free service (the distribution of *.amb files for free). But I am also introducing an other, much more accessible ‘free’ service … which is the ability to stream all content, for free, from the browser.

I think a likely scenario is that there will be a bit of disappointment amongst the community that they now have to pay a little for a yearly subscription, to download everything for free. But to counter-act that, there will be many new-comers … who will have accessed the streaming stuff, and will want to go a step further. And eventually, the community will understand that I just cant keep up *sweat equity* on Ambisonia, I habe no sweat left.

It is exciting times for me though. Once the commercial version of Ambisonia is launched I can finally let go of the years of struggling to put it together. If the site fails commercially, then I will officially let go of it, and be free of the shackles my commitment to it. If the site survives financially then that will be a huge boost to ambisonics, because it will finally be possible to make money using this technology (I’m not just talking about me, I’m also talking about the uploaders). Either way, its a win for me.

The plan is to have the new site opened to limited beta testers (who will be uploaders). Once there is a bunch of good content (maybe 100 uploads), then the site will be released to the public. Whilst the beta testers are uploading content, I will be coding up the ‘tipping’ system. I’m anticipating this will take around 3 months.

Launch Business Model

I’ve been racking my brain to try and find a business model which is sufficiently simple and can benefit both the uploaders and the site.

I recently stopped using a CVS repository service (assembla8.com) because I couldn’t work out how much their service would cost me … their business model was too complicated. Made me realise that the ‘cost’ of the service _has_ to be simple.

So here it is.

All content is streamable (for free) from the browser in 5.1. You can either stream to speakers connected to your computer, or stream optical to an AV receiver.

No downloads are free.

If you ’subscribe’ to Ambisonia, then you can download everything for free. The subscription fee is $15 for 3 months, or $45 for one year.

Now here’s the really cool point … you then have to ’spend’ your subscription money as tips. In other words, if you bought a $45 one year subscription, then you need to allocate that $45 to the tunes you think most deserve it.

You might tip lots of people 10c, or you might tip just one tune $45 (either way you can download everything). Ambisonia then takes around 30% of that (like iTunes).

Anyway, back to the beta site.

What I’ve got left to do is:

1. Find a new name. I’ve been labouring over this for ages. I cant use any ‘ambisonic’ derived name because it wont be trademarkable. I liked something like ‘conch’ … because it has that association with being transformed to an other world just by sound (putting a sea shell up to your ear). ConchHead.com would have been perfect, but its taken…so… I dont know.
2. Clean up a few graphics.
3. Work out some way for the Uploader to know how long the transcode is taking.
4. Test edge conditions (like uploading files of same name etc.).

On the right is a ‘teaser’ screenshot of the new ambisonia. It probably wont look like that once deployed… but that’s not the point.

Teaser screenshot... may not look like that, probably wont be called that.

The point is that I just completed the first successfull full-use-case test. I uploaded an amb file using the Uploader… very easy. When finished, the Uploader gave me a link … when I click on it I go straight to the web page of my new upload.

Then … and this is the clincher …. I clicked on ‘play’ (in the embedded quicktime player) straight away …and WHAMO! .. there was my ambisonic file correctly translated and streaming directly out of the browser.

No waiting, no torrenting, no mucking about. All on Amazon’s S3 and EC2 platforms… so super fast for those in the US (and quite fast for those in Europe).

So, I’m excited (again). Getting closer, slowly, slowly …

Photo by Annie Mole from Flickr.com

The discovery of the art of blogging has been accidental, amongst my efforts in the development of ambisonia.

The discovery is simply that blogging is an art. It is a medium in itself.

Its kinda like writing a diary, but the diary is public. Writing something publicly creates an exciting challenge that I have blogged about before. It creates the challenge of sincerity versus security.

If I could just quote myself:

The ego blocks sincerity and it is sincerity that creates a voice. Being sincere (as an artist) is extremely difficult, because it exposes, and to be exposed is to be vulnerable.

Since blogging is an art, it follows that it is difficult to blog sincerely. But sincerity is truth (or something like that) … and I am drawn to truth. I’d give my right arm to be able to wax sincerity. I believe it would be one of the most liberating of freedoms.

That’s why I’m a big fan of Johnny Cash. There’s an engaging sincerity about his work. Check out the below song, “Hurt”.

Funny thing about “Hurt” is that it was written by Trent Reznor of Nine Inch Nails. Johnny Cash is actually just covering it… but he still manages to bring a sincerity to it that hints that he has ‘lived’ those emotions. Check out the original … it an entirely different aesthetic:

Its a demonstration that the aesthetic is secondary to the art. Although the video in Nine Inch Nails’ performance of it is gripping, Johnny Cash’s version is almost more raw.

Anyway.

To me, the master of blogging is Dave Winer. I was extremely interested to read his “Three examples of great blogging” post … now from some weeks back. The three qualities that his 3 sample posts have are:

1. People talking about things they know about, not just expressing opinions about things they are not experts in (nothing wrong with that, of course). 

2. Asking hard questions that powerful people might not want to be asked. 

3. Saying things that few people have the courage to say. 

Point 3 is the one I’d like to thrash out. It takes a lot of courage to speak sincerely. It takes perception to see a truth, but it takes courage to speak it.

I think that having the courage to communicate a truth that you have perceived is what being an artist is about. Its a 2 pronged thing … you have to be able to see that truth … and then you have to be able to communicate it.

Several weeks ago, I made a very very difficult decision. I decided to drop Plone and re-write the entirety of Ambisonia in Ruby on Rails. This weighed very heavily on me.

I decided to do this, because anytime I wanted to do something slightly-out-of-the-box with Plone, I’d be sent into a violent spiral-in-a-box  … hitting walls, walls and obstructions.

I’ve been nervously wrapping my head around Ruby on Rails, waiting for the prognosis on my decision.

Well, the prognosis is good. Very good.

I feel empowered by Ruby on Rails.

The new site is coming along well. There is a freedom you get with writing the code yourself (rather than wedging things into a Content Management System) … which empowers you. You know you could steer any path, at any time, without hitting the walls of an established (over-designed, I feel) ‘framework’.

Further to that, I am really starting to love Ruby. Its the kind of language that takes a quarter of the code you thought you would need to write… and there’s always a simpler way.

Python and Plone had Buildout for installing/upgrading development code to the production machine. That was good … I’ve never used a ‘deploy’ system before.

But Ruby on Rails was designed around the needs of the modern web application builder. It supports the whole development/testing/production lifecycle out of the box. And Ruby has Capistrano. Capistrano seems far simpler than Buildout. And it is designed so that I can deploy new code to the production server, without ever going into the server. All I do is type “cap deploy” on my local machine … and WHAM … the new code is there. Very good for incremental development. Painless.

I’ve also discovered Shoes. wow! Writing GUI code has always been a complete pain in the *&(*#. Shoes is a revolution. Well … its part of a revolution. Several years ago I was exposed to Processing, a Java kit for doing graphical things. I actually used Processing to write a little graphical GUI for moving sounds around ambisonically. “WhyTheLuckyStiff”, the author of Shoes says:

Shoes is strictly inspired by stuff like REBOL/View, HyperCard, the web itself and, of course, Processing and NodeBox.

I don’t like the bulkiness and the layers and layers of wxWindows, FOX, QT, GNOME. They are big, big libraries and all the apps look identical, devoid of spirit.

The unique thing about the web is that it gives you very few controls, but people are able to build wildly different pages with it that are still immediately accessible to people.

He is a good thinker, this “Why” fellow. Its rare to get someone who can write good code _and_ understand design, _and_ trumpet user experience.

Check out NodeBox. Very inspiring stuff.

Believe it or not … the *new* ambisonia is already up on the Internet. Its not called ambisonia, and you cant see it :p (yet). Slowwly, sloooowlyy, easy does it …

Following Part 1, where I presented a ’software’ use case, this post proposes an application architecture that allows extensible workflow modelling, a tightly integrated GUI, a pay-as-you-use business model, in a “web 2″ application platform. I’ll call it the ‘Enterprise Web 2.0 platform’.

The inspiration comes from multimedia applications that have been around for decades. Let me set the scene…

Its the late 80s, and gentleman named Miller Puckette is working at IRCAM (Institut de Recherche et Coordination Acoustique/Musique) … trying to work out a better way to organise how MIDI messages get sent to various keyboards and other pieces of audio hardware. MIDI is essentially a simple protocol for sending around musical info, like “Play note C, reasonably loudly, for 2 seconds”. These messages get routed around from computers to keyboards to samplers to this that and everything under the (audio) sun.

Miller wants a way to easily change/affect/filter/configure this MIDI data, change what device the MIDI data gets sent to etc. He writes a now-lengendary software application called ‘Max’. Its simple … its just a set of boxes that do different things … and you can wire them up to each other, in a sequential manner, define the input and the output (where the messages come from, and were they go to). Have a look at the image.

For corporate software users, Max looks kind-of a bit like Visio. Boxes joined up by arrows (or lines). But it is very very different to Visio, because it is not just a diagram, it actually executes the logic that it represents.

The configuration interface is also the application architecture is also the user interface.

What you see is what will execute (WYSIWWE). There’s no ‘business logic’ below the bonnet.

Many people have since written other applications that use a similar “the GUI *is* the application architecture” model for audio processing, video processing, and other things. There’s MaxMSP, PureData, Plogue Bidule, AudioMulch, Reaktor, and more.

In 2001 I spent many hours integrating video processing capabilities into JMAX. You can see, on the image on the left, one of my “Visio diagrams” of objects and connections describing how video should be processed.

Its a messy diagram, but that’s not the point. The point is to realise that each object does something different, and you can configure exactly what you want to happen by creating lots of little pipes between different objects.

That’s the first point.

The second point is how the “GUI *is* the application architecture” thing works. How is it implemented and why is it so profoundly significant? Well, it is simple. Let me illustrate this by considering how one would implement an email notification feature. Consider this code:

public void EMailer (email_address, email_subject, email_body, trigger) extends GUIObject
{
    # code to send an email here
}

That’s the only code you would need to write. You dont need to write a GUI. All you need to do is drop that compiled code in the right folder, and whamo, ‘management’ has a tiny little independent object called EMailer that they can drop into their Visio-like diagram. Just configure the recipient, subject and body, then draw a line into it (from whatever point in the ‘workflow’) and an email will be sent at the appropriate time. What you see is what will execute.

This little ‘feature’:

1. has no dependency on any other code in your application,
2. can be easily (QA) tested because it is entirely isolated from other code,
3. will not introduce bugs because it is entirely isolated from other code,
4. requires no GUI to be designed,
5. can be used anywhere in the application,
6. can be used by someone who knows nothing about programming.

Implementation

How would I implement such a thing? Well, it has to be accessible over a Web Page. I’d implement the front end using Flash (embedded in a web page) … communicating via a REST API most probably to a Java back end (or perhaps a PureData back end?). Flash would not execute any of the business logic… its just an interface to define/access/monitor/edit the ‘workflow’ (or business logic).

The useage of Flash is important because it favours graphic designers, and the design of such an application would be very important. That said, since the communication between the front end and the back end is a REST API, anyone could come along and implementa ‘new’ interface.

Design

I’d employ the best user-interface designers, and graphic designers I could find. The above code sample defines no GUI code just to illustrate the architecture, but in practise you would want to design a funky little GUI for each object. The EMailer, for example, would typically be a little envelope icon. That GUI design would be a little Flash file that would be sucked up into the larger Flash file.

Business Model

You would pay only for what you use. So, for example, the EMailer might cost 1c per email sent. EMails are sent when the object receives a ‘trigger’ so the ‘triggers’ would be counted, and each object would have access to a REST API to ‘log’ useage volumes.

3rd party extensions

3rd parties only need to develop the independent objects, then ‘log’ them in an object database. All customers of the platform would be able to access all objects in the database… and their account would be charged as per what they use. They can choose to use or not use any objects at any time.

Sample objects would encompass typical enterprise software needs, such as these:

1. LDAP server integrator,
2. Schedule objects,
3. Logic flow objects,
4. Notification objects (emails, SMS, IM),
5. etc.

Configuration

The customer’s administrator (or manager) would then drop, onto a blank screen, a selection of core and 3rd party developed business logic ‘objects’, then string them up to model their workflow/process requirements.

In Production

Once configured, the ‘patch’ (or diagram) would be locked. Each object would then expose different levels of interface to be used during the real world ‘workflow’.

Prototype

I’d prototype this by using the existing PureData. In fact, I might even implement it using PureData as the back end.

Conclusion

This post proposes an extensible ‘platform’ for modelling and executing ‘workflows’ in corporate environments, and how that ‘platform’ could be monetised (on a per-useage basis).

It is inspired by configurable multimedia software, where a workflow is modelled by a GUI which looks and feels similar to a Visio diagram. The radical difference is that the diagram then *becomes* the application architecture. It is not just representational, it is in-fact executable.

This architecture is very scalable, feature-wise. Adding new features causes no weight on the existing infrastructure.

The platform is heavily GUI based, and so could be easily configured and maintained by the customer.

The platform’s GUI would be delivered by Flash embedded in a web page, thereby offering high accessibility.

NOTE: this post is, ofcourse, a simplification of all the details that would be involved in implementing this architecture. It is essentially just a first ‘fleshing out’ of an idea I’ve been thinking about for a while.

One of the cold realities I have discovered with Ambisonia, is that there is a hard limit to activities which dont sustain themselves financially.

I cant (yet) claim to have a good grounding in online business models, but I do claim to have a solid base in marrying online technologies to deliver applications. I’ve been doing lots of thinking, recently, on how to infuse business models into application architectures.

In Part1 (this post), I will highlight a ’software use case’. In Part 2, I will propose an architecture which delivers a scalable solution combined with a deeply integrated GUI and with an infused business model.

Y Combinator, a high profile early-stage startup fund, lists ideas they would like to fund. One of them is “Enterprise software 2.0″:

Enterprise software companies sell bad software for huge amounts of money.

Oh, how I agree with them! My ‘payed’ work, for the past 10 years, has been mostly in the corporate ‘IT Service Management’ field. The complexity and lack of ‘user experience’ most available software provides is head-ache inducing.

One of the current lights of this industry is www.service-now.com … a “Software as a Service” (SAAS) IT Service Management provider, which brands itself as “Web 2″. I worked with this tool for over a year, and whilst it is definately years ahead of any other software I’ve encountered in this field, its still far from what I would consider “Web 2″.

Service-now essentially models business processes by offering long, deep forms and endless choices of convoluted combinations of configurable drop-down fields. You know what stage a particular process is in by reading the current value of a drop-down. Not very intuitive. Filling out a form requires making many ambiguous decisions that will always be prone to errors. Staff need to be trained, and then work full-time, just monitoring/maintaining values in forms.

One of Service-now’s other drawbacks is its complexity of configuration. The vast bulk of a new customer roll-out involves configuring users, groups, privilidges, tasks, alarms, notifications, workflows, etc. About 80% of that is achieved by, you guessed it, filling out numerous web forms. The last 20% requires scripting (in ecma script). Often, you can achieve in several lines of ecma script what might take several pages of web forms. Ofcourse, the professional service consultant will always tend towards favouring the web forms, because the customer can then maintain the system themselves. Or at least that is the theory.

But Service-now have enough ‘young smarts’ in their midst to recognise there was a better way … they recently deployed the Graphical Workflow editor (see image). One of the things I noticed when collecting customer requirements, was that many customers defined their requirements with Visio diagrams. We would then ‘translate’ these Visio diagrams into values we would type into a gazzilion ‘web forms’, and ecma scripts.

It wouldn’t take much to reach the conclusion that configuring the system should be done with a ‘Visio diagram’ style interface. Service-now saw this and delivered. Although, there are now 3 ways to configure a system, a gazillion web forms, ecma scripts, and the Graphical Workflow editor.

This is the right direction. But when I first saw their javascript client side Graphical Workflow editor, I had concerns about the implementation because the rest of the application is far more mature. Introducing a radically different interface (quite late in the piece) has implications on the underlying infrastructure.

1. Will all features be available through this interface, or will I be relegated to doing *some* things in ecmascript, *some* things in web forms, and *some* things in the Graphical editor? Already, not all aspects of certain features are available in web forms, and not all aspects of things in web forms can be easily configured in ecma scripts.
2. How has it been architected? Is it just a layer on top of everything else? Like so many other corporate applications, will Service-now fall over in 5 to 10 years because of a complicated multi-layered architecture that piles new feature on new feature, eventually requiring a team of Quality Assurance engineers the same size as its development team, just to make sure that a new feature hasn’t broken everything else?

I also wonder if this interface is only intended for configuration. Because it shouldn’t be. If Visio diagrams is how management see processes, then Visio diagrams is how the staff should execute these processes. Removing Web forms with endless drop-downs, check boxes, radio buttons, free text fields etc. in favour of a high-level diagram that makes it very clear where we are and where we want to be has to be a good thing.

Instead of an ‘assigned to’ field showing who currently owns the ticket, show me a little image or photo of that person (with their name below), then let me re-assign the ticket by clicking on the image. Or something like that.

Show me when emails were sent just by displaying a little envelope icon next to the relevant arrows/boxes. Give me more details when I click on them. Tell me what emails are going to be sent by ‘penciling in’ light email envelopes at future points in the Visio diagram.

Tell me what stage the process is up to, just by ‘firming up’ the relevant boxes/arrows up to a certain point. etc.

In Part 2 of this post, I will propose an architecture where the graphical user interface IS the application architecture, where adding new features to the application causes no risk and adds no complexity, where the application effectively becomes a platform, and 3rd party providers can offer added features which pose no (or little) risk to the underlying platform but with an easily measurable value.