Subject: Re: [linux-audio-dev] memory management
From: Josh Green (jgreen_AT_users.sourceforge.net)
Date: Tue Nov 27 2001 - 04:49:32 EET
On Mon, 2001-11-26 at 13:12, Paul Davis wrote:
> >
> >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).
>
Perhaps I should define more specifically what I would like to do with
my particular app, Smurf Sound Font Editor.
1. Active setting of loop points in a sample. So you can listen while
you set them.
2. A convenient method to edit a sample in a sound font with the user's
favorite editor (MONO or STEREO 16 bit samples)
The first item I think I will just implement in Smurf, as there is no
guarantee that another editor will have this kind of functionality and
setting loop points is one of the most common tasks in making a sound
font.
For the second item, something slightly more sophisticated than EXEC'ing
an editor would be nice. With sound fonts we're dealing with fairly
small individual samples (a sound font bank could be in excess of 100MB
or more, but this is typically divided among thousands of samples). So
we can expect samples to usually be under lets say, throwing out a
figure, 8MB. This is why, currently, Smurf operates on samples entirely
in memory. Only one sample is in memory at a time though, for displaying
and editing (currently just cutting) purposes.
So Smurf doesn't really need to have concurrent access to the sample as
it is being edited (as long as the editor allows you to listen to it).
Here is what I see as the editing cycle:
1. Sample is selected in sound font tree
2. User clicks "EDIT" button
3. Sample is extracted from sound font (or wherever it resides) and
stored in a temporary file
4. Smurf spawns custom editor passing the temporary file name (via
command line arguments)
5. User does editing
6. User saves file in editor
7. Smurf is polling for change on file or perhaps user must manually
click an option to reload the edited sample
Since sound fonts deal with many samples, it is best to cut down on the
amount of time and steps it takes during the edit operation.
Ideally the editor should have some support for loading multiple samples
and the ability to load a specific file specified from the command line
(without spawning a new copy of the program).
The other part is getting the sample back into Smurf. I guess some sort
of timed polling of the stat of the file or something would work just
fine.
The other problem is if Smurf happens to be using the audio device (for
iiwusynth wavetable engine perhaps). This becomes a problem when the
user tries to listen to the edited sample in their editor. Not sure how
to deal with this one. Maybe streaming the audio data back to Smurf to
be played by whatever audio engine it is using, or perhaps I should
leave it up to the user to figure this out. Could jack be used for
something like this? (I think I asked this question before)
So really, now that I think about it, it probably wouldn't be MUCH more
complicated than a simple EXEC on Smurf's part. It would be nice if
sample editors implemented same session loading of multiple samples from
the command line though (maybe some editor already has this?).
For things like batch sample operations and such I could have an option
to export all the sample data to individual wave files in a directory
where editing could take place and then re-imported back.
Anyways, hope I haven't overwhelmed this list with my big email. I'll
try to write less :)
-- Josh Green Smurf Sound Font Editor (http://smurf.sourceforge.net)
This archive was generated by hypermail 2b28 : Tue Nov 27 2001 - 04:44:58 EET