Re: [linux-audio-dev] multitrack and editor separate?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] multitrack and editor separate?
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat Oct 27 2001 - 19:40:12 EEST


>> when working with multitrack recordings, what one is often doing is
>> manipulating semantically meaningful chunks of audio so that they are
>> correctly aligned with each, have appropriate gain and other FX
>> applied, and are sent to the appropriate outputs.
>>
>> these tasks have little if anything to do with the process of editing
>> a waveform. you can make them both possible via the same GUI, or you
>> can create more optimized environments for both tasks. ProTools, for
>
>Huh, from a software engineering point of view they are distinctly
>seperate tasks but from a human interface viewpoint the user is
>"editing digital audio" where both aspects complete a whole picture,
>or sound(s) in this case.

i don't agree. the process of getting a sample of a drum hit, or a
bass riff, or the chorus, or the door slam, into "shape" is totally
different than the task of put the drum hit in the right place,
copying it, pasting it, and so forth.

i agree that to use two applications with different UI conventions for
this would be confusing, but the only alternative to that is to
require that each program be capable of doing *everything*. The Unix
Way (TM) provides some hope of avoiding that, but perhaps not enough
in a world where the data is highly ordered (and not really just a
stream of bytes at the semantic level we care about).

anyway, it would appear that if i'm headed anywhere with this, it
would be toward an embedded wave editor for Regions, so in some ways,
we're in violent agreement.

>What would be brilliant is to make Ardour and friends embeddable
>widgets that can be incorporated into the dozens of front end GUI
>systems that are available under linux (and windows too, courtesy
>of us penguin heads).

You have to be kidding? Ardour as an embeddable widget?

Ardour exists as a shared library that can be used by a variety of
different user interfaces. But any given instance of Ardour
(e.g. gtk-ardour, ksi-ardour), which combines the library with some
kind of user-interface (not necessarily graphical), is a complex piece
of work, and the idea that you could just make it an embeddable widget
is a little crazy. Besides, we'd be right back the same old
Gtk/Qt/Gtk--/WxWindows/FLTK/XFORMS issues that we've touch upon here
so many times before. You can't embed widgets from one toolkit into an
application that uses another without some disgusting hacks being
present in the toolkit(s) themselves.

                       These C/C++ and script driven IDEs are maturing
>nicely and allow a hacker muso to _design_their_own_ interface which,
>to me, offers the ultimate in flexibility and totally scrunches the
>whole idea that ones mans meat is another mans poison when it comes
>to calling shots on GUI presentation and layout.

Sure. Then just use libardour, which has no UI code of any kind at
all. its less than 1/3 of the total source code of gtk-ardour,
however, so you can plan on spending quite some time working on your
own GUI for it :)


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Oct 27 2001 - 19:37:43 EEST