Subject: Re: [linux-audio-dev] soundfonts and csound
From: Josh Green (jgreen_AT_users.sourceforge.net)
Date: Tue Sep 19 2000 - 11:09:21 EEST
Dave Phillips wrote:
> Greetings:
>
> This message is directed to Josh Green, but may be of interest to other
> LAD members.
>
> Josh, here's an example csd file to activate a soundfont via Csound:
>
<cut>
>
> Anyway, the Maldonado code is a working SoundFont playback engine for
> Csound. It would be very interesting to see it incorporated into Smurf.
I think this would be very cool too. I'm trying to figure out the best way to
go about this task. Timidity++ I've heard also has SoundFont support.
Essentially what needs to happen is:
1. on demand patch loading into csound
2. an interface for selecting which preset/instrument/sample is active, note
on/off and other sequencer related controls
I'm not really familiar with csound. What do you forsee being accomplished by
incorporating csound into Smurf? Would this be for purposes of emulating a
wavetable card only, or do you see the ability for csound operations to also
occur along with the Smurf Sound Font Editor. I think this will determine how
we go about things. Here are 3 possible courses of action:
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)
2. just rip out the software wavetable related stuff and stick it right in
the Smurf source tree
PROs: probably the easiest to impliment
CONs: nothing else could take advantage of this interface, it would be a
software wavetable, only for Smurf, so the sound font would need to be loaded
again into the real csound for playing
3. some other server/client type communication set up between Smurf and
csound
PROs: keep csound functionality while allowing for Smurf interaction
CONs: another special server/client communication that only Smurf would
understand, and probably a bit of developement
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.
Course 2 is tempting, if we cannot get adequate information for course 1.
This would still not be the most convenient method as then we would lose the
csound capabilites. At least until the user loads the saved sound font into
the real csound.
Course 3 would probably be a lot of developement time for a server client
architecture that could be had via ALSA. So I don't see a reason to put
effort into this, if we can figure out how to use ALSA.
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.
Cheers,
Josh Green
This archive was generated by hypermail 2b28 : Tue Sep 19 2000 - 12:08:07 EEST