The Recursive ISV

As I’m in a time zone a day ahead (date wise) to the other participants it’s technically Day 15 of 30 of the 30 Day Sprint and Sunday.  That’s the half way point technically for me.

So.  Am I going to make it?

It’s looking that way.  Though there are times when one does feel a bit doubtful, I admit. 

Take yesterday.  Incrementing the selected node of the project treeview took a lot more work than it should have.  It works fine now.  Being able to swear fluently in English, Italian and colloquially in Australian, Italian, American and Cockney certainly helps. 

I love Delphi, don’t get me wrong, but the implementation or rather wrappers of these kind of Win32 widgets, well, suck big time. 

In the past I’ve used treeviews in Delphi (in fact they’ve been a part of my projects GUI’s since 1999) however it’s a lot easier to search for “text” and get a node than it is to do it via the item index. Should be the other way around. Oh well - I’m putting it down to a learning experience. 

So in short MixAction now automatically moves to the next track ready to play in the currently selected Act or Scene and then at the end of that play list to the next Act or Scene in the sequence, loading each play list as required, until the end of the “theatrical production’.

With the “project tree” and the current “play list” I have yet to implement dragging an audio track from the play list to another node in the tree.  That’s not hard and it will be added some time this week.  Dragging nodes on the tree of course is done as is changing the order of audio in the play list via drag and drop.

I then spent time synchronizing the Play/Pause buttons and making sure the audio position trackbar allowed fine adjustment.  Both of those work well as does double clicking an audio track in the play list - which overrides the currently playing track, stops it and starts the next.

This all led to some tightening of code in the audio playback logic of the GUI for which I’m pleased I got to spend the time on.

Further adjustment will be needed when I add in the logic for crossfades between the playing and next track. 

As MixAction is not an “audio player” like iTunes, WMP etc and as theater is not a “precise” environment, but rather something who’s timing depends on somewhat rather unpredictable “people” doing things on stage, it’s generally the case that full automation would be undesirable.  So an individual track never starts immediately when another track finishes, unless the user has set properties for it to do so.

When such behavior is desired it is selected (a checkbox of course, which is where the project file database comes in) and in that instance the next track begins playing when the last track finishes.

A further element is when the next should start playing - not just when the last finishes.  This is where cross fading comes in.  At the simplest level the current song dips and fades in volume as the next track starts and fades up or a combination of those. 

I expect most users initially won’t be setting a lot of these more advanced properties.  But, apart from the hierarchy driven layout this is one of the most important features of the product.  Point and click driven “scripting” of events.  It’s also, from a technical and programming perspective, where multiple threads become necessary.

One “keen teen” has asked “Cool, will it beatmix Dude?” 

Nope. 

There are a kazillion DJ software and audio software packages on the market that specialize in this.  It’s a complex algorithm and I can assure you, as a person who did club DJ’ing in another life that, none of them get it right with the exception of products like Mixcraft, Sonar, Acid Pro and similar which use specially created audio tracks. 

I am purposefully avoiding “sound creation” in this regard and those who want to do it will be pointed towards those products, which BTW, are not good fits for live theater unless you really know what you are doing, have spent time (a lot of it) practicing and so on.  All the things that MixAction strives to help the user avoid in short.

In wrapping up for this entry, today I intend to treat myself by coding the Graphic Equalizer and Dynamic Controller.  The former is self explanatory and the latter is a gain (level) riding tool who’s job is to level out peaks in the audio signal.  A “safety” tool to avoid overload of amps and speakers.

Then there are the “Project Templates” that will allow the user to select a project that “fits” with their purpose and have the skeleton of a project created for them.  I’m intending to expand on this quite a bit later.

There are two types of Equalizers in MixAction.  The standard Graphic most folks are used to.  Seven bands in this incarnation as anything beyond that tends to overload entry level CPU’s, and Parametric which is in the case of MixAction is aimed more at special effects than their more usual usage in pro audio.

This weeks challenge for me is getting the individual properties for a track coded and operating at playback.  If I achieve that then the final week of the challenge will be spent creating the installer, testing the application on as many systems as I can and working on the website. It’s highly doubtful that the built in “audio store” will be ready by the end of the 30 Days inside the program.  If I get to day 30 and that’s the only thing missing in the implementation I won’t be at all worried. 

One final note.  Normally when I code I don’t play music.  I simply can’t concentrate with it.  It’s fun to work with a project that *requires* you to play music when you run the project. 

Later…

Quote of the day:
Until you’ve lost your reputation, you never realize what a burden it was. - Margaret Mitchell