Interesting read, and i'll add this for discussion. We have tremendous potential in Linux for making music, and images, be they stills or film. Unlike commercial operation systems, we can operate free of limitations. For someone like me, who uses a lot of everything, be they ports, tracks, etc.., writing music and recording it in a Linux environment gives me, for the first time in over 25 years, the chance to use 'everything at once'. I run 64bit, and have little or no interest in using VST's, or more generally plugins, as sound creation devices.So apart from needing a lot of ports, tracks, and great midi editing tools, my needs could be viewed as fairly simple. I used to record my orchestral mates on an 8 track, and had a lot of fun doing so. It was faster than using a computer, because i hit record, and voila, we're off and running. (more or less) When i started using a computer to do the same, for a living, i spent a lot of time tweaking, and maintaining, and those who used Gigastudio in the past will know what i'm talking about here. It took a lot longer, and often proved to be a larger barrier than the 8 track method, which was hit record and go. Despite that, i soldiered on, as it wasn't everyday i could muster up likeminded orchestral players, and record them. (and i did the same for them as they recorded for themselves in the same way, and i played for their work.) Dave Phillips got me into Linux, after over twenty years of using Win and Mac, and it proved to be a great move. (And thanks again Dave. It's been excellent) I'm closer to the "setup and record" method than i've ever been, using a computer instead of an 8 track, but one thing remains, that i think would put the icing on the cake for not only me, but linux audio and midi application users and developers alike. And that's workflow. Like the commercial world for our particular niche, there's a heavy dependency on mousestrokes. For those of us who use a computer for orchestral and film writing, using a mouse kills the workflow. This may not be so readily apparent for the user who generally works with 4, 8, 12, or 16 tracks, but when writing for 60, 70, 80, and more tracks, the limitations of a mousecentric workflow paradigm become painfully apparent. This is particularly true for midi inputting and editing, where we might have a thousand segments, or items, to manage and edit, and constantly swapping between a mouse and the few keystrokes available kills any semblance of efficient workflow, and makes the donkey work of editing, even harder. In linux apps defence, they are no better or worse than commercial apps, but with the opportunity to exceed commercial offerings, we could get close to that '8 track' paradigm, and forge a path that few could follow. Using an 8 track was enjoyable, still had limitations, and relied on a good relationship between composer and player to get something done. Our little community of players stuck together, and helped each other out, and that worked for us. Using an orchestral sample library can be the same, if the tools are complimentary to workflow, and remove as many obstacles as possible in the record and edit process. I continue to be a big supporter of Linux, and the remarkable work done in our niche, by talented people. We still have workarounds yes, but in my case, not nearly as many as before. And i'm constantly aware of the undeniable fact that i'm in a niche, within a niche, as i've very few linux composers who write similiar music to me. (2 so far.) For developers looking to mature their apps further, i respectfully ask that you consider workflow, particularly navigation, as an important part of what you code, when making your project decisions. I was told recently by a talented dev, that many of you don't use your own apps that often, something i found amusing and ironic, so from a power user who uses linux audio and midi apps are part of a fulltime working environment, i share this view in the hope that you'll consider the efficiency of using keystroke maps as an added asset, and code accordingly. Using a mouse for so many tracks, items, and actions, is counterproductive, and introduces an element of building frustration that works against creative workflow. Gaining momentum and keeping it is essential, imho. I tend to be a bit geekish about workflow, so please take the above comments in context. I tend to examine every action stroke, in a workflow "chain", and work to reduce the number of stroke actions required, assigning keystrokes where possible, within the limitations of a coded application. If this was considered, and coded, at app development level, i'm confident the user experience, and their perception of the excellence of an application would change considerably for the better, form the already high regard many apps are held in. There's already much to enjoy in our niche community with the tools that are built, and i view great workflow as the "8 track" experience, on a computer, something few in any world, linux or commerical have achieved so far. Coding keystrokes, and examining workflow to a fine degree, including studying every action in a workflow chain when building your app might not seem very glamorous, or even interesting, but, imho, it's the....last 10% that seperates great apps from good ones. Sorry for the ramble, but i thought this important to add, when reflecting on the 8 track experience, and the potential to get close to this using a computer. Alex. On Tue, Jun 2, 2009 at 11:39 AM, Jostein Chr. Andersen <jostein(a)vait.se> wrote: -- www.openoctave.org

Ray, Traverso's an interesting navigational exercise, i'd certainly agree with that. I guess i should additionally qualify what i wrote with my view that using a mouse to navigate, or perform edit functions is, imho, counterproductive, and contrary to efficient workflow. I don't like the digital rodent in professional workflow at all, so my comments should be regarded with this mind. I'd also add Denemo to the great apps list, in regard to actions and navigation, as they've worked to give users a great range of choices, with user definable keystroke options, in a smart, and, you guessed it, efficient way. Alex. On Tue, Jun 2, 2009 at 1:06 PM, Ray Rashif <schivmeister(a)gmail.com> wrote: -- www.openoctave.org

alex stone wrote: some of the graphics apps - gimp and blender come to mind - have addressed this very well, in their own ways. In the commercial world CAD programs and Final Cut Pro, with big development teams and huge budgets, have done this in their fields - for a price. Using an app for graphics almost always involves mouse/pen, keyboard, screen very closely. With audio one can completely leave this interface behind, or work text-only, in some workflows. Think the braille/CL interfaces that some on this list use, or the various midi or tactile/hardware interfaces to boxes with little or no gui that some people use. Here the modularity and flexibility of linux really stands out. Simon

alex stone wrote: I guess a lot of the effort put into workflow in linux audio is focussed on studio recording/mixing or assembling custom live performance tools rather than editing or setting things up. Ardour now has a quite flexible and quick method of binding midi to app controls, but it is best with a reasonably recent version and you do need to dig around a bit to find out that it even exists, let alone which keystrokes to use. It is quite new and understandably getting it working has been more important to the developers than documenting it, but I'd guess that anyone who offered to write good documentation would be very welcome. Like most efficient shortcut systems you won't stumble across them by just bashing away - what is efficient and ergonomic is probably not the most obvious and find-able method. That is one of the reasons that the point-and-click interfaces, while wildly inefficient, are so widely used. Often a potential user will open an app, poke around for a while, open a menu or two, click on the icons that they can see. If they can't get it going that way they often drop it as too obscure, too hard to use. Lots of users choose their tools based on a pretty screen and an easily discoverable mouse-menu interface, and those interfaces take a lot of work to build. By contrast the initial learning curve for Blender is very steep, you are very likely to get frustrated and give up if you just bash away hoping to get something happening. Lots of users won't touch command line tools at all - looking at an empty terminal window can be daunting at first and it takes quite a lot of practice before a new user has learnt enough of the vocabulary to be efficient. It is a big choice for a developer - spend big efforts in making an attractive and immediately usable point-and-click gui or expect potential users to climb a steeper learning curve before they can start making music, and focus instead on making an efficient text/keyboard interface? An app with a steep learning curve needs a very keen, vocal and enthusiastic user base prepared to offer lots of support to new users. Simon

Paul Davis wrote: ouch, I only discovered it a year or so ago, and its been great! Thanks for all the work, and a really vital app in the audio world. Simon

On Mon, 2009-06-15 at 14:36 -0500, Brent Busby wrote: Yeah.. I actually like the visual aspect in a DAW.. but I am also a hardware sequencer and synth kind of person...