Building Ambisonia.com

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.

Several weeks ago, I thought I’d try and rally a group of people (to my mind, ‘key’ and ‘active’ sursounders… about 10 of them) to try and put together a specification for integrating Ambisonics into Vorbis.

I had no idea of the difficulty of this task until it was well under way.

The aim was to by-pass the sursound (mail list) style of endless debate and quickly produce a smart, solid, reasonably-future-proof specification that the Vorbis-dev people could implement.

I’ve been trying to put my finger on exactly why this is such a challenge. I have to say I have a re-newed respect for the open-source communities who put together projecs like Linux. How do they make consensual decisions and move forward?

The challenge, I have come to believe, is that

1. participants all have different expectations from the exercise (sometimes personal, sometimes strategic), and
2. that there must be some kind of ‘responsibility hierarchy’. Decisions have to eventually land at someone’s feet, to be able to move forwards.

Not all decisions can be consensual. The challenge is then to not lose participants along the way.

Aaron Heller suggested that such technology-defining exercises _must_ begin with a clear and concise definition of the expected outcome… thereby aligning the participants expectations. He postulated that there are 2 ways to go about defining a technology, or a format.

1. technology-push. For ambisonic file formats, that would translate into: “how does ambisonics want to be represented in a format” and
2. application-pull. In our case, that would be “how can we deliver streaming ambisonics over the Internet”

This little effort has clearly been ‘application pull’.

What matters is that someone sitting at home can go to a web page, hit ‘play’ and get an ambisonic file to play over their cuboid speaker array.

Its all about getting ambisonics ‘out there’ and it doesn’t matter what the internals of the format looks like. Pure application-pull.

The best way to get a group of super-smart contributors to move forwards on this, I have realised, is to constantly go back to the stated goal: “The goal is to deliver ambisonics over the internet, how does the suggestion of … affect that goal“.

Its been a huge learning curve for me. We are not there yet, but I think the effort is starting to bear fruit … if we can just continue on the current path for perhaps an other week, I think we will have a convincing and implementable spec.

Check out the current state of the draft specification here. BTW … you can have a look at the discussions here.

I should note that an other extremely difficult decision was the decision to limit the membership of the group. This was not done because it was thought that certain sursounders would have bad input … it was done because by limiting the numbers, it would be easier to reach consensus and move forwards. Maybe this has been the wrong decision. Given a more explicitely stated goal, it may have been possible to parse greater numbers of input and still move forwards.

ambisonia is a computer (and thousands of hours of time)

Just a quick note to confirm that the global recession will not be affecting Ambisonia.

Since Ambisonia has no business model, it will not be losing income.

Since Ambisonia has no investors, it will not be losing cash flow.

Since Ambisonia is not hosted on a commercial server, its service will not be compromised (any more than it usually is).

However, if the recession dramatically increases unemployment, and I find myself cronically unemployed, Ambisonia may well be gaining a full-time resource (albeit a stressed one).

When I typed in excited and stressed into Flickr, this is the image I get! Cows Again by Or Hiltch.

Excited because I have Amazon EC2, Amazon S3, Amazon EBS and my little Ruby uploader working very very nicely together. I have created a script that sucks up *.amb files from S3 (online storage service) into an EC2 instance (a virtual machine on Amazon’s servers), transcodes them into all sorts of consumable formats .. then uploads them back to Amazon S3 … ready to be stream-downloaded. Its clean, fast, efficient and fully automated. It takes a couple of minutes at most before a submitted *.amb file is available for streaming in AAC. Almost instantaneous .. unlike the DTS transcodes that force manula labour on me.

Stressed because my principle employer (who I’ve been working with for 1 year) terminated my contract. Several months ago they asked what I needed from them to drop my other casual employment so that I could give them 100% flexibility. I said just guarantee me 2 days of work a week. We drew up a contract, I signed it. 3 months later they terminate the contract. Thanks guys. Remind me never to work with you again. I think you have been very socially irresponsible (I know, I know, all’s fair in love and war … and capitalism is war. Its a jungle out there).

In a quandry because I officially really dislike Plone.. and I’m wondering if I should kick it once and for all. Ambisonia.com sits on Plone. I’ve been using Plone for 3 years, but the more I get to know it, the more it infuriates me with its layer-upon-layer nothing-is-well-documented over-complicated over-abstracted over-designed obfuscated complexity. Its a platform designed by developers. Developers are not good designers. It takes a special person to ‘design’ software .. someone who understands code, but also understands the act of design. It is easy to put a piece of software together, it is enormously difficult to put a piece of software together in a simple way. That’s design. And that’s what Plone is NOT. I waste soo much time trying to do really simple things in Plone.

The uploader is done in Ruby. I like Ruby. Should I do the website in Ruby on Rails. Arghhh … I just spent some resources hiring a contractor to put together a scalable implementation of Plone. Arggh …

A member of the Sursound list asks what market problem Ambisonics solves. I have my opinions.

But I know 1 problem that desperately needs a solution.

How to make sense of the endless tireless debating flying in all directions on lists.

Is there a product out there that can ‘order’ lists like the sursound list … in such a way that ‘conclusions’ can be easily derived, published and consulted? Maybe a group-ranking of list comments… or something more sophisticated.

There is something about the order of lists that incites people to have endless debates that sprout like cancerous mushrooms. I think it is the nature of email. At one of my workplaces, we had a policy that if you could not solve a disagreement in one or two emails, then take it off-line … go one-on-one.

Going one-on-one is not possible when you have 100 members spread all over the world. So email arguments sprout, with line by line parsing of the detractor’s positions on topics that dont deserve the attention.

Market opportunity … lists that draw conclusions.

Photo by Mykl Roventine from flickr.com

I think Nic Carr has done an excellent job with his high level description of what Google is about. Its actually quite simple.

Google collects all the data it can about everything/anything … and uses that data to offer more and more targeted (and hence more successful) advertising.

Its the ultimate ‘complimentary’ service, where advertising is to data what mustard is to hot dogs. Give your hot dogs away for free, and you’ll sell heaps of mustard. Google gives away services for free, and uses the data collected from those services to sell more advertising.

In a way it is scary, because in a digitised world, everything is data. So Google sells more mustard for almost everything that happens on the Internet. Notice also, however, how Google is trying to turn as much as it can of the ‘real’ world into Internet ‘data’. Google maps (they recently launched their own satellite), street view, books, and now microfiches. Here’s a prediction: watch as Google attempts to bring in more and more ‘non-Internet’ data into the Internet.

In an other way, it is also scary because it is extremely difficult to compete with free. Google gets more profit when it gives away their services for free (because they collect more data to help them sell advertising better). 99.999% of other web sites cant make money from free. Unless, ofcourse, you put up Google ads on your website. This is scary because the only way you can compete with Google’s “free” is for you to share your profits with Google. The US Justice Department is considering an anti-trust case against Google for these kinds of reasons. This is serious stuff, I hope they can make headway.

In an other way yet again, it is scary, because if you fall foul with Google and they decide to pull the plug on your Adsense earnings (as google did with ambisonia), then you are left high and dry. Attempts to engage with the Google machine to contest their actions is met with intimidating silence. Why would they bother with one (or probably thousands of) tiny little sites?

What Nic Carr doesn’t address is the impact of Google’s “we make money from analysing your data so all our services are free” on other web sites. Is Google’s ‘free’ strategy a win, generally, for all of us? … or is it a loss? Do we get more from Google’s free services than we would have gotten from all the services that cant survive because they cant compete with free?

In the last post, I spoke about XXXXX the missing feature that I need to offer. Something that’s

Photo by DREASON on flickr.com

really really cool, and brings a new experience to surround sound. Something that opens up ambisonia.com to the next level. … maybe its inline track mixing, maybe its some kind of social integration, maybe its some DSP API. I dont know.

My point is that “I dont know”.

And that now officially brings to light something that I have never quiet understood before. The importance of market research. All advice I have read on Business Models stress the importance of market research.

To do the market research, I have to understand who the market is. This is difficult, because those involved in Ambisonics come from a wide variety of backgrounds and interests.

The Business Model could be aimed at the content uploaders OR the consumers. The interesting thing is that different purveyors of the Freemium model aim differently. Flickr.com aims exclusvely at the content uploaders. Other sites like (music sites) amie st etc. aim at the consumers.

It makes more sense for Ambisonia to aim at the content consumers, because it is early days for ambisonics and there arn’t that many producers out there.

Who are those consumers, and what can I offer them that has real value?

1 year would give you $8 tipping credit

This is where I’m at. $14.95 will buy you 3 months subscription to Ambisonia.

For that, essentially, you get to download everything in a range of formats.

I havn’t yet decided if whether or not *.amb files should remain as free downloads or not.

What I’m looking for is the XXXXXXXX in the picture on the right. What is it? …. what’s that last little feature that will really add to people’s experience of the site? Its got to be

1. funky in some way. a ’super’ feature,
2. accessible to newcomers. The business model cant rely on features only meaningful to a tiny minority.

Essentially, if that XXXXXX is good, then I can make *.amb files free for downloads. That will be the clincher.

Maybe its an automatic-convolution service where you upload the data you want Ambisonia to convolve each tune with (for Binaural or room correction). I dont know.

Can you help?

Clearly, for $14.95 for 3 months, what you are buying is accessibilty. It really feels like there should be one more little thing involved… some must-have feature that will open up the can to excitement. The questions is what!