Subject: Re: [linux-audio-dev] soundfonts and csound
From: Scott McNab (sdm_AT_fractalgraphics.com.au)
Date: Wed Sep 20 2000 - 10:23:14 EEST
> 1. develope csound ALSA sequencer support
> PROs: Generic interface that any sequencing program can use
> CONs: more developement time, not sure if a patch loading standard has
> been developed in ALSA yet (critical)
[stuff cut]
> I think 1 is probably the best course of action. This wouldn't even really
> involve Smurf except in getting full ALSA support. I still don't know where
> native ALSA patch loading is at though. If anybody has any information on
> this, please let me know. I really don't have any information on proposals or
> anything, do any exist? Is each wavetable capable device going to have its
> own patch loading routines, or is there going to be a generic interface?
> These are all things that would need to be solved for course 1.
I played about a bit with ALSA patch loading when writing the Trident synth
driver and the mikmod alsa-seq driver. There is basic support for instrument
loading, but it is still very incomplete and is not at all well documented.
Currently there is very primitive support for loading simple wave instruments
on Trident and GUS cards (suitable for playing .mod files), Interwave patches
on GUS cards, and OPL3 FM instruments for cards with an FM chip. Obviously,
the EMU8k and EMU10k drivers support soundfonts, but only through OSS emulation.
Instrument patch loading works by first checking the capabilities of the synth
device to see if it supports instrument loading, and then sending an appropriate SND_SEQ_EVENT_INSTR_PUT event to bind instrument data to a specified bank/program
number. It is then up to the receiver of this event (soundcard driver/user-space
soft synth) to then react and parse this event appropriately.
Patches can be loaded so they are persistent and accessible across clients (so
you can load a piano sound as program 0 and play it from a second application)
or they can be private to that particular application (so loading a machine-gun
sound effect as program 0 will not affect another application playing a piano
tune!).
There are numerous other events defined in asequencer.h which presumably would
support complete instrument loading, querying and patch editing, but afaik most
of this is still undefined and unimplemented. I think this general type of
API is quite usable though and I'd like to see it get properly defined so people
can start using it.
> ALSA ALSA ALSA.. I think that is the way to go. We could do some sort of
> cross between these options. Like perhaps developing ALSA sequencer support
> for csound and then some hack to on demand load the patches until an ALSA
> solution comes around. Anyone else have any thoughts on this?? I suppose I
> could post my "what is the status of patch loading in ALSA?" question again
> on alsa-devel. But I didn't get a response the first time, and I hate to nag
> programmers who are hard at work doing the basics.
Its been a few months now since the topic was last discussed so it might not
hurt to try raising it again. Takashi seems to be the one now in charge of
sequencer stuff although I think most of the existing instrument loading support
was Jarsoslav's work.
Even if the API is not implemented at the driver level yet, having the events
defined properly would at least let people play with it in userspace (eg. with
smurf and timidity). Support in the kernel drivers could be added later with the
instrument loading/editing tools already existing.
Scott
This archive was generated by hypermail 2b28 : Wed Sep 20 2000 - 11:17:26 EEST