The Recursive ISV

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

Yeah, something a little different and something of a taste in relation to what I’ve been doing to MixAction…

If you were following in June during the 30 Day sprint I blogged about and participated in then you might recall the early screenshots of MixAction.  If not you can refresh your memory by Clicking Here.

That screenshot gives you a pretty rough idea of how things stood at that time.  Right now to all intents and purposes it looks very similar, same UI elements are there, same basic principles, same color schemes and so on.

However.  The center pane, the playlist, in that screenshot worked pretty much like like any other Audio media player.  You add an Audio file and it goes onto the list.  MixAction then allowed you to set various parameters for special effects on the file and so on. 

In addition the program could auto increment and play the next track or all the tracks if you wished, adjust volume according to your preferences - preset by you - and so on.

I’m not going to give away the store in this post, not quite yet, but I thought I’d give some indication of how this has all changed and tease a certain person who is attempting a rather lame clone [which he is attempting to market at a price less than mine, which I read is perplexing him as I've not released pricing details anywhere. 

Plus I've never really said who my actual market or markets are.  You know what they say about people who assume... ;-)  ].

null

The trick here is that while the UI hasn’t changed in the sense of overall look there are many additional options added that can not be seen in that screenshot.  Some additional smoothing over, some animation of certain parts where appropriate (instead of boring old hide/show) and most notably - the playlist…

See, it no longer is a playlist like you would expect to see in your average “media player”.  It’s now a playlist of “objects”.  Each “object” has properties.  Properties include things like lists of Audio files, playback parameters, automation, special effects and much more.

You might be getting some idea why I was so pleased with not releasing.  Fundamentally this is an enormous paradigm shift. I had to shift it in order to ensure the product lived up to it’s name - MixAction.  Clearly it should do a lot of “Mixing”. 

Now the premise was ease and automation and this is where the objects work so well.  By taking a leaf out of the precepts of object orientated programming and applying the basics, and the most relevant, to Audio.

 I’d love to elaborate further on exactly what I mean by that statement, but for now it will have to wait.  Suffice to say I will be showing screenshots for you to take a look at later down the track.

The great thing about this is that it also allows for expansion, easily.  In fact almost (not entirely of course) zero coding expansion for effects and parameters as the Audio engine is already coded.  It’s literally a matter to a large extent of enabling certain “properties” and wiring them up to the engine.

That’s the theory, though Murphy is bound to be popping in anytime to alter that certainty… 

The benefits to both me and the customer is that the basic product potentially becomes one of several levels in terms of complexity (functionality) and price points. Additionally the process is much more visual.  This was always meant to be a key component of the product.  It’s interesting to note and look back upon my own personal notes from earlier this year (back as far a January and February 2008) to see that much of this was in the original intended specifications.

Indeed the June rush saw a lot of this go by the wayside as it was physically impossible to code the product and implement this kind of drag and drop object implementation.

I think this should empower the person working within the program, both at the design stage and at the performance stage.  Many of the options going in during this iteration are “preset” in that while you can set parameters or properties they are limited to a set functionality.  This is a design decision influenced by the idea of release early…

Now I know what I just said.  That phrase “release early”.  Iterative via updates etc, the development paradigm that is certainly relatively recent, despised by some, but one that does make some sense.

As I have the June prototype I’ve been able to see both strengths and weaknesses in that design.  Basically this is a result of that process, evaluating, rethinking where appropriate, separating the GUI from code as far as practical and tweaking.  It’s also the catalyst for sweeping change in a good many places.

And there too is the problem with folks cloning unreleased applications, particularly without  domain knowledge.  I know where I’m headed, spent most of this year documenting and designing UI elements (some not included in June and then pulled back in now, or redone or retouched) where as the clone has to play catch up.  Indeed I’m finding it rather stimulating now as rather than just code up a storm I’m methodically planning the code to allow expansion in the future.  That task is almost done. 

There is massive scope to expand the product, iterative release is going to make “catch-up” of the clone rather difficult.

Oh - and there’s the marketing blitz that I’ll expand upon in the months to come.

Take care! Scott Kane

Quote of the day: What if this weren’t a hypothetical question? - Unknown

Related posts brought to you by Yet Another Related Posts Plugin.