Peter Hanappe wrote:
>
> That would be a really good idea. I should study a little more the
> various required file access functions. My basic needs were just a
> file reading API. Off course, we would have to design a full file
> editing API.
>
> Since i'm not doing any editing, I can read all the samples in memory
> in one block. Smurf creates and inserts samples much more randomly.
> Both should be supported.
>
> Anyway, I'll start thinking about what kind of design I would propose
> and what I think should be in the API.
>
No. I meant an API for something like the Smurf Sound Font Editor (and
other sound font aware programs) to connect to the wavetable engine and
load/unload/update/query sound font patches in an arbitrary destination
sound font capable wavetable device (iiwusynth, AWE 32/64 Live!,
Timidity, whatever). The current sound font API is very SB AWE specific
and is still OSS based. Making a general Sound Font API would allow for
any synth (hardware or software) to be viewed as sound font capable and
transparent to other programs.
I am creating (like we discussed already off the list) a libsoundfont
library to handle the actual loading/saving/editing of sound font files,
which is more like what you described above.
Josh Green
