Re: [linux-audio-dev] memory management

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

Subject: Re: [linux-audio-dev] memory management
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Nov 26 2001 - 23:12:55 EET


>> i think this way lies madness, or at least possible foolishness.
>[snip]
>
>i do not understand. say i'm making a sw clone of the korg es-1
>'rhythm production sampler'. i need to edit the samples somehow, and
>then later apply some effects probably. what is the set of operations
>that i would want an editor to perform on the sample? (i don't know a
>better term than 'sample' here; perhaps i'll call it a clip.)
>
>- read in from a file
>- write to a file

if thats all you want to do, then use can use the time-honored unix
API's: fork(2) and exec(2).

API's like bonobo are designed to allow much tighter integration of
the different objects that the process model. you know this, sorry :)

>and all the interface is provided by the waveform editor 'control' (to
>use bonobo terminology). what is complicated about that?

what does this waveform editor actually do? does it work like ardour,
and (almost) never actually modify anything on the disk? does it
always work like DAP, and always overwrite data on disk? does it
generate audio output and feed it to a playback engine directly, or
does it somehow pass it to the "master" object? does it handle
multichannel data? does it do disk readahead, and if so, how much?

each time you answer one of these questions, you narrow the space of
possibilities of what this waveform editor could possibly do. nothing
wrong with that at all, its a necessary step. but defining that
particular set of possibilities means that the resulting object is of
no use to a program that requires a different set.

to get more concrete: early on in ardour, i looked into embedding snd
as ardour's editor. initially, it looked quite promising: it was
already compilable as a widget, and i quickly got a version of ardour
working with the snd widget in its own window. but then i had to start
trying to figure out how to get snd to generate audio output when i
was working within it and wanted to listen to what i was doing. that
was hard, since snd didn't control the audio interface anymore the way
it does when its an application. then i ran into another problem, even
more severe: snd expected to be able to fetch all disk data on demand,
which wouldn't work in the type of situations i wanted ardour to be
useful for. finally, as i began to understand more about editing music
and sounds the way that ProTools, Nuendo, VST, Samplitude and others
make possible, i realized that an actual waveform editor wasn't really
what i wanted at all. the end result? snd is compilable as an
incredibly high function widget, but it wasn't at all useful a way to
edit audio in my particular application.

i strongly suspect that this would happen again and again regardless
of the embeddable objects design.

go ahead and try to define what "editing the samples" means. good luck!

                                                          i could be
>showing my ignorance here, but i sure would like to pull a waveform
>editor in as a bonobo control. i don't understand, for this application,
>your argument about 'similar' vs 'dissimilar'.

dissimilar: an application that handles data of type Y wants to
               allow users to also work on data of type X within its
               general framework, and so uses an embeddable
               object to do so. Y and X do not intersect.

similar: an application that handles data of type Y doesn't do
               everything that could possibly be done with type Y.
               it wants to use an embeddable object to extend the set of
               operations it makes possible on data of type Y.

--p


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

This archive was generated by hypermail 2b28 : Mon Nov 26 2001 - 23:11:43 EET