Subject: Re: [linux-audio-dev] Soundfont synthesizer (Was: LinuxTag 2001)
From: Josh Green (jgreen_AT_users.sourceforge.net)
Date: Wed May 30 2001 - 04:29:56 EEST
Peter Hanappe wrote:
> Okay! I see what you mean now. I guess the main functionnality should
> be:
>
> - synthesizer interface: it should integrate with
> Frank van der Pol's sequencer API (or implement the rawmidi API?).
>
Yes. The patch data, commands etc would be passed via the ALSA sequencer
API.
> - detection of supported patches: SF2, GUS, DLS, ...
>
There should probably be a number of capability flags related to the
wavetable device. Real time modulator support, sample data get support
(perhaps some wavetable cards can't read back sample data?), etc.
> - load/unload/update/query sound font patches
>
> I don't know the ALSA API nor the OSS AWE 32/54 API but I'll check
> it out. As you said, I could use the synthesizer as a test.
Yes. First we should start defining the API though. I started writing
something up but got side tracked for the moment. It would be nice to
have some others involved who have knowledge of various wavetable card
limitations, so we can keep them in mind when designing the API. At this
point it isn't absolutely necessary to know about the ALSA API, until we
actually start coding it. Its basically just going to be a data stream
that contains headers describing the command followed by the data for
the command, etc. Some of this is already built into the ALSA sequencer
API though.
The overly simplified API data stream will look something like this:
<command> (Create, Update, Remove, Query - Already something of this
sort in ALSA)
<objectID> (Preset, Instrument, Sample Info, Sample Data, Zone?,
Generator?, Modulator?)
<parameters> command parameter data would follow
Need to come up with an ID system. The "Query" command would allow an
application to get information on the currently loaded sound fonts. If
an application wanted to update a sound font with the name "8mbgmgs" it
would first query for that sound font to get its ID and to see if it
exists. Then do an "Update" with the object type (Preset) and ID (an
integer) followed by a preset header describing the # of zones, then the
zones themselves, etc.
Its questionable as to whether we should provide support for Updating at
the Zone, Generator (parameter) or Modulator level, as this can be done
(albeit more complicated and slower) by querying then updating the
entire object (Preset or Instrument) that its part of.
>
> Did you get the change to take a look at the Downloadable Sounds
> (DLS) specifications? It's designed by the MIDI Manufacturers
> Association (MMA) and it very closely ressembles SF2. I used the
> specs to understand SF2 a little better. The file format also looks
> similar so it might be interesting to make a common API.
> (http://www.midi.org/about-midi/dls/dls2spec.htm)
>
I have briefly looked at it in the past. As far as what I have gathered
from others, and I agree as well, effort shouldn't be made to make a
unified patch API. This is because there are just too many options and
differences between patch formats. I have considered providing editing
support for other types of patch files in Smurf though, I guess I'd have
to change the name to Smurf Audio Patch Editor or something :) I suppose
there will probably end up being some common routines that can be used
by any wavetable implimentation (ALSA kernel API?), custom routines per
wavetable driver and application routines in libasound. I'm still not
familiar enough with ALSA to know how that will all work though.
> The MMA also worked on a draft to combine a midi and a DLS file
> into one archive file (a RMID file)
> (http://www.midi.org/about-midi/rp29spec(rmid).pdf).
> It's very useful if someone wants to distribute her MIDI file
> together with her SoundFont and people can listen to it with, for
> example, XMMS.
>
Good to know. I have thought about this many times myself, as there is
an obvious need to supply instrument sounds with MIDI files (I often
forget what patches I was using with a particular sequence). Perhaps
something like that could be abstracted even more to just be a
compressed archive of MIDI and patch files (SF2, DLS, etc). The client
would then need support for the particular patch format.
> However, I don't know if the format is well supported by the available
> sequencers and other MIDI tools.
>
I'm not too worried about that. If its an open standard and it gets
used, support will follow. Lates..
Josh Green
This archive was generated by hypermail 2b28 : Wed May 30 2001 - 06:20:24 EEST