Too Busy For Words - the PaulWay Blog

I love how ideas 'chain'. I was listening to my LCA 2006 Arc Cafe Night second mix (Goa and Hard Trance) and thinking of the fun I had while mixing it. I manage to get away with using proprietary, closed-source, for-money software at LCA somehow, but though I'm absolutely dead keen to have a free, Open Source program that could do what MixMeister does I have neither the skills or the time for such a large project.

Still, I was thinking about the way I use the program. It has a main window divided up into three parts - the top half is divided into the catalogue of songs you have, and the playlist of songs actually in the mix. Then the bottom half is the graphical display of the mix and is where you tweak the mix so that the beats line up and the fade-in and fade-out happens correctly and so forth. The key problem with this in my view is that sometimes you want a lot of space for the catalogue so you can very quickly scan through the songs looking for something that has the right BPM and key signature and that you recognise as being a track that will blend smoothly with the current track, and sometimes you want a lot of space for your graphical mixing display.

So why not have an interface that watches what you're doing and gradually adjusts? The more time you spend in the mixing window, the more the top half gradually shrinks down to some minimum width. When you go back to choosing songs, the catalogue expands back to its median setting fairly quickly (over perhaps five seconds or so) and then gradually expands if you're spending more time there. In a way it's mimicking the actions you do with the grab bars to change the size of the window panes anyway; it's just doing it smoothly and unobtrusively in the background. You don't want it moving too quickly or changing your targets as you're using them, so all changes should happen over tens of seconds and any change in direction (from growing smaller to getting larger) should be preceded by a pause to check that the user hasn't just strayed into that area by accident. Even the relatively speedy 'return back to median' would happen over a long enough period that if you were able to to pick something quickly and move back to your work area then it wouldn't involve too much of a wait for the windows to return to where they just were.

Of course this would take a lot of engineering to apply to an application. Or would it. We've got Devil's Pie, an application that can procedurally apply windowing effects to application windows. Could something similar be taught about adjusting the controls within an application? The possibilities are endless, but I have no idea at all how to go about doing it...

Seems to be the story of my life, really...