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)
