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: Sun Oct 28 2001 - 19:36:32 EET


>Both aspects squarely come under "digital audio editing" where the
>end goal is to have processed audio ready for further distribution.
>Creating a 3D model, assembling a scene, then animating a whole
>sequence uses distinctly seperate tecniques for each part but the
>overall process is _often_ viewed as a single procedure.

sure, but lets the take CGI industry. those guys don't believe that
you use the same tool to do rendering as you do for modelling. i think
that comparison is instructive.

>BTW I was not sugggesting complex GUI interaction via a high level
>scripted language but being able to call up and "embed" (for want
>of a better word) "chunks of code" (for want of 3 better words) in
>different layouts, and yes, most likely on a monitor (but not always).

this assumes there is an exchangeable data format plus an agreed upon
communication protocol. we have neither.

>> You have to be kidding? Ardour as an embeddable widget?
>
>Not at all. You would be aware of OpenGL. It is far more sophisticated
>than Audour may ever be... it exists to facilitate both presentation
>of and interaction with visual 3D objects. The ability to prototype
>a usable app quickly, actually use it, then have the option of further
>streamlining certain parts of the app in C/C++ is very "natural" with
>gigahertz++ boxes these days.

I don't think you understand enough of what's going in a multitrack
editor. I can easily saturate a 1.2GHz machine with just a few LADSPA
plugins on each of 24 tracks of audio. *easily*, without even thinking
about it. The potential for unbelievable computational loads here is
so vast that it doesn't bear thinking about. We will always, always be
able to think beyond where the h/w is.

>> 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 :)
>
>Not impossible at all then. If libardour is in any way built like
>OpenGL (perhaps even OpenAL) then I might be able to have my cake
>and eat it too (use your GUI and roll my own 3D one too).

libardour isn't an audio toolkit. its not like MAX, or jMax or PD
or Csound. its a library for streaming multiple channels of audio to
and from disk, with realtime processing along the way. MAX or jMax or
PD will fall over rapidly if you try to do that without significant
extensions to those programs.

> For those
>who think I'm strectching CPU cycles... my next box will be 3 ghtz
>and next year we'll have 64 bit varieties. "we" are only a year or
>so away from having more CPU cycles then we know what to do with.

it will never happen. even a 3 orders of magnitude increase in
computing power (i.e. 2 TeraHz) wouldn't be enough to do full
realtime physical modelling synthesis of a full orchestra.

--p


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

This archive was generated by hypermail 2b28 : Sun Oct 28 2001 - 19:34:35 EET