>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
