April 18, 2007

Boulevard Of Broken Dreams #4

by Chris Randall

In the last installment of this series, we'll have a look at some product evolution. The above image is the starting point. Early on, while we were casting about for a direction the company would take, we considered doing a synth, and here was my idea for one. Totally modular (with the exception that audio routing and CV routing had to, by necessity, be separate patchbays) it would be a fairly typical representation of a small modular synth. Now, this would certainly be a good product; the main problem with it is two-fold. (A) The synth market is flooded, and (b) it is pretty plain once you get past the semi-interesting UI.

So, we decided (more or less permanently, as it turned out) for better or worse to just avoid the synth market at the time and expand on some of the better ideas in our Mayhem package, namely the TimeFnk delay. So we took the better ideas from Plexus and combined them with the general execution of TimeFnk, and this is what we came up with:

Now, if you take a close look at that UI, you'll note that it mirrors a product you might already own pretty much exactly. That is the first UI for Ronin. In retrospect it is a far better UI, but there were reasons for not using it. They are:

1. This UI was built with the concept of using PNGs for the knobs and such in mind. Using PNGs instead of BMPs for the knob filmstrips and elements was a relatively new thing at the time. It worked on OSX machines, but Windows machines, which had no built-in method for reading PNGs, exhibited many issues. (This also engendered the redesign of Discord between v1 and v1.5.) So once we discovered that PNGs were a serious problem, we had a relatively short time to come up with a solution.

2. When we were working on this, it was a current fad on a couple of the pertinent forums to complain mightily and loud about "hardware look" user interfaces. I actually took this quite seriously. I know better now, of course, but when you're just starting a company, you only have that sort of feedback to go on. So we thought "well, we better avoid hardware UIs; we don't want to piss anybody off."

So, TimeFnk II got its name changed to Ronin, and got the current Ronin UI, for better or worse. Due to its obvious complexity, Ronin isn't one of our better sellers. But Ronin begat Dubstation, which our best-selling effect, so we're not complaining.

But this brings up an interesting point about user interfaces. Ronin and Dubstation are essentially the same code inside. With Ronin, you have access to every single possible parameter in the plugin, and you can route the audio and control signals however you want. With Dubstation, we've basically removed the patchbay, the LFOs, and roughly 2/3 of the controls. Dubstation has sold ten times the number of Ronin. You can easily see how this has informed our design process.



Page 1 of 3

Apr.18.2007 @ 11:35 AM
"You can easily see how this has informed our design process."

No kidding. Got to go where the demand lies

I agree with you, it is a better UI. Funny enough, at the time Ronin was released, I would have favoured the non-hardware look. I think I like this one better, not because of the hardware look, but because of the added definition created by the hardware-like elements (better shape and contrast which makes it easier to scan the UI for a given parameter). I think the marriage of the two in Discord 2 works similarly well.

One question, in the transition to TimeFnk II, why did you choose to drop the sample reduction parameter? Whenever anyone laments the passing of TimeFnk, the only thing they always fixate on is the sample reduction.


Apr.18.2007 @ 11:37 AM
Chris Randall
Well, both of those people have written me directly. ;-)

I'm not sure why we took it out; I remember having a conversation about it, but I can't recall the gist of it.



Apr.18.2007 @ 11:49 AM
Hey Chris, derailing these comments for a moment, what apps do people use for desigining the UI? Just Photoshop? Or are people using 3d apps like Maya? Is there a 'net community somewhere where folks discuss this? Thanks

Apr.18.2007 @ 11:57 AM
There's another point that came to my mind about amount of copies sold though. After reading the last sentences of the post I immediately thought "well, but Ronin is pretty expensive and Dubstation isn't". I just had to go check out the prices at AD site and noticed neither of them actually costs too much... but Ronin is still 2x the price.

Guess it's the psychological factor coming into play - for a cheapo student like me, Dubstation's price feels like "nice, I could get this even if it sucked, and I'm pretty sure it doesn't" and Ronin's like "not that expensive but for that amount of money I'd have to think about it carefully". I've no idea about your user base but I wouldn't be surprised if more than one cheap bastard like me though like that.

It's not like there's anything wrong with the Keep It Simple, Stupid -paradigm, though. Sometimes it helps to have a good sounding 2osc monosynth instead of a monster modular - with a modular you're likely to end up with endless hours of patch building wankery fun and no tunes to speak of.


Apr.18.2007 @ 12:53 PM
Ronin's priced too high for impulse buy, Dubstation isn't, honestly that's why I own Dubstation and not Ronin.

Apr.18.2007 @ 1:31 PM
Chris Randall
Ataru hits the nail on the head. We've found that $49 is the cut-off point for an impulse buy. Since Ronin and Dubstation share so much code, the development costs (mainly just time, in our case) of the latter are folded in to the former. Since the latter makes significantly more money for us in the long run, the costs of developing Ronin, while technically still way in the red, are well covered.

As for the actual design, I don't know of a community specifically for doing user interfaces. Personally, I use 3D Studio Max for all the knobs and buttons and such (or the whole UI in the case of our 3D products like Dubstation and Phase Two) and do the layout in Photoshop. There are exceptions to this, though. 914 (and 907A, its parent) was done entirely in 3DS Max, even though it is technically a flat-on UI. I did the hash marks and lettering in Photoshop, but the rendering itself is all Max.

But it is much easier to make knob filmstrips in 3DS Max than it is in Photoshop, so even the stuff that _looks_ like Photoshop (the knobs in Ronin and Discord 2, for example) are still done in 3DS Max. Part of the problem is turning the knobs. I can write an animation to turn the knob and shit out a stack of PNGs of it in about 5 minutes in 3DS Max, but doing it in Photoshop, even with a fairly sophisticated set of custom actions, takes forever. Plus the shadows in Photoshop never look right.

For the curious, I'll use Dubstation as an example. For our 3D interfaces, I generally do 33 frames for a knob turn. (It has to be an odd number, else there's not a frame that is directly at 12 o'clock.) So for Dubstation, I build the faceplate in Photoshop, lay that on a "panel" in 3DS Max, and build the rest of the unit around it. I then either use an existing knob model or make a new one, lay out all the knobs and switches, and animate them. I then render a 33-image stack of the entire UI. Then it's back to Photoshop. I have several Actions I've written to make this portion easier since I do it so often; the simplified version is that I make a single Photoshop document with 33 layers; each layer is one of the 3DS Max renderings, and they're in order. I drag a marquee around the knob I want to make a filmstrip of on the top layer, make a new document that is whatever width that is, and a height of the marquee x 33, then press F10 and presto, magic, I have a filmstrip.

So, from blank page to a finished set of images for the UI for something like Dubstation starts in Photoshop, moves to 3DS Max, then back to Photoshop for final stitching. There are other tools I use (TrentStitch for BMPs, PNGstitch for PNGs), plus I generally code the actual UI itself, although the last couple of products Adam has done that, simply because we've had to develop new UI elements during the course of making the product, and I don't have the knowledge for doing that.

That's probably more information than you were interested in getting, but there you go.



Apr.18.2007 @ 2:15 PM
So I guess I kinda feel dumb I bought Dubstation after Ronin :) Then again you can pretty much get me to buy anything if you can tie it into a certain a certain Afro-Caribbean genre of echoey music.

When does DubReplicant come out?


Apr.18.2007 @ 3:08 PM

Well, a couple of thoughts to make you feel better about buying both - first, you're extra cash is helping the sustainability of AD, second, while both products may use similar code, Dubstation has a certain "quick and dirty" feel to it (as I understand it, that was the whole point). It may do fewer things, but I'm guessing that if you just need a delay, you'd be more prompted to throw Dubstation on as opposed to Ronin.

Caveat - I own neither. I've been debating the purchase of either DS or Ronin far too long. Ronin has all the features I need, and is far better than a hardware delay that I used to own, and loved (the MoFX - it was simple and worked well live). Dubstation had that impulse price point, and looks like it's well, maybe not full of techno, but full of dub (or, maybe ganja, but I digress).

Given this discussion thread, and now knowing that the code is essentially the same, I think CR just upsold me on Ronin (fishes for credit card...).


Apr.18.2007 @ 4:02 PM
I own both DS and Ronin. I knew well in advance that it was essentially the same code, but it came down more to work flow for me. If I need something quick I load up DS, since to me it's basically better than the "Simple Delay" in Live. If I want to do something more complicated, I know it's time to start fussing with Ronin.

Apr.18.2007 @ 5:19 PM
If I remember correctly, PNG files (as well as many other formats) can be loaded easily using Windows GDI+ Libraries. The only issue is that people must have the libraries. That's not a problem on XP or later, but earlier versions of the OS may require the re-distributable package be installed to be used.

Page 1 of 3



Sorry, commenting is closed for this blog entry.