[iiwusynth-devel] Re: [Swami-devel] Not so quiet list anymore [was RE: Hi - Very quiet list - my first post]

[Josh Green]

On Wed, 2003-01-22 at 11:04, Peter L Jones wrote:
> 
> I think I see where Mark's heading.
> 
> Now I've played with Windows for a while, all the tools I've come across are
> incredibly restricted compared with Linux.  A "soundfont" synth, e.g.
> Bismark BS-1, implements a single instrument under a software sequencer by
> loading a single soundfont and responding to midi events.  The sequencer
> decides which midi channel to send to the soundfont synth.
> 
> One of my "back of my mind" projects is to implement FluidSynth as a VSTi
> plugin.  This would give the Windows world a real soundfont synth.  The
> problem is, VSTi expects to only provide a single instrument that responds
> on a single midi channel.  So I probably won't try this.
> 

FluidSynth I believe does already run on win32 (although I have not
tried it myself). I have gotten Swami to compile and run in win32 as
well but not linked with FluidSynth or a sample library (so it wasn't
all that useful). I will return to getting it running in win32 and Mac
OS X at a later time.

> >From this, I think Mark saw FluidSynth as such a tool - a single instrument
> synthesiser.
> 
> Of course, FluidSynth is designed for full GM/GS/XG Soundfont files, not
> single instrument soundfonts.  This means it uses MIDI channel number and
> MIDI program change messages to decide how to respond to each NoteOn
> message.  (The point being to be able to play any Standard MIDI File
> correctly given a GM/GS/XG soundfont.)
> 
> So...
> 
> To support single instrument or non-GM soundfonts, it would be nice to be
> able to assign the desired bank and program numbers, overriding those in the
> soundfont.  SWAMI or FluidSynth?
> 

For that particular question I think both should support it. The virtual
bank format I mentioned before could easily be handled by Swami and
FluidSynth. The format I am talking about is the one Takashi Iwai
created (usually with a .bnk extension). Its a text format and might
need a few extensions (allowing to escape spaces in file names) but it
is generic enough to allow virtual banks to be created from different
patch formats. Virtual banks I believe are the best way to tackle this
problem. Just drag presets from different patch files into a virtual
bank and voila!

The current design of Swami and FluidSynth is to make them independent
of one another. In my opinion they certainly like working together,
though :) In the future I will be adding other wavetable backends to
Swami (OSS EMU 8k/10k support, maybe Timidity++?) but for now FluidSynth
is the only wavetable support (which is quite excellent anyways, who
could want anything more?).

When running FluidSynth stand alone it uses its own SoundFont loading
code (derived from the older Smurf Sound Font Editor project). When
using FluidSynth through Swami, all the patch related loading is done
through Swami (thanks to the nice API that FluidSynth provides).

FluidSynth will most likely stay SoundFont oriented though, while Swami
is moving into the general Wavetable patch area. It will still be
possible to use FluidSynth to synthesize other formats using Swami, when
the time comes, by translating a patch instrument into the SoundFont
oriented FluidSynth api.

> Support for multiple GM/GS/XG soundfonts would be improved by allowing a
> "base bank" or "bank offset" to be supplied.  SWAMI or FluidSynth?
> 

This kind of functionality would probably be the most useful at the
FluidSynth level. I think the ability to edit virtual banks covers this
feature already, though.

> I'd like to be able to load multiple soundfonts and pick instruments from
> each and call that a bank -- this is definitely into SWAMI territory...
> 

Editing such files would be in Swami's territory (and maybe also the
FluidSynth shell). Using these files could be in both territories :)

> (One day I'll have time to have another go at getting this working on
> Windows...)
> 
> -- Peter
> 

Yes.. When I get the devel branch in some state of workingness I will be
looking into supporting other platforms (is probably pretty trivial).
Things may actually work now, just need the right development
environments (was using a cross compiled mingw32 environment before and
testing the resulting binaries with wine, I don't do windows :) Cheers.
        Josh Green