iiwusynth-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[iiwusynth-devel] Re: [Swami-devel] Not so quiet list anymore [was RE:


From: Josh Green
Subject: [iiwusynth-devel] Re: [Swami-devel] Not so quiet list anymore [was RE: Hi - Very quiet list - my first post]
Date: 22 Jan 2003 22:49:58 -0800

On Wed, 2003-01-22 at 11:07, Mark Knecht wrote:
> 
> Personally I'm not really excited by 'banks' and 'program changes'. I
> typically make a MIDI track for each and every instrument I write a part
> for, so I don't need program changes. The violin track is always a
> violin track, and it only talks to the synth that plays violin sounds.
> 
> I am way more excited by great sounds. In my experience just today, I
> might find an interesting synth in one soundfont file, and then a good
> drum in another file. I want to use those two sounds, but not any of the
> others.
> 
> In fact, weren't program changes invented so that a hardware synth that
> could only produce a certain, limited number of voices had a way to
> change voices? In this computer/memory driven environment, why can't I
> just load many copies of iiwusynth, each playing a different soundfont? 
> 
> I guess I just don't understand the purpose of program changes or banks
> in this environment.
> 

I see what you mean actually. It is a pain to enter in bank:preset
numbers in another program (even after one makes a virtual bank). This
has been discussed before on LAD and ALSA. I don't think a protocol has
been developed yet, but basically an instrument information querying
protocol is required. If you could get a popup list of the instrument
names in a sequencer then one would not need to know bank:preset #s (the
program would still use them though). I still think virtual banks come
in handy. It would allow one to group instruments together for a
particular song.

Bank:Preset numbers are part of the MIDI standard if you didn't know.
Basically MIDI started out with only a Program Change (i.e. Preset
Change) command, which limited the # of instruments to 128 (yuck). So
they added a bank which I believe is a 14 bit # (I think SoundFont files
only use 7 bit #s though). For your particular use you would just have 
bank:program changes at the beginning of your song, and then just forget
about it.

The next thing to tackle is binding patch files to sequences. I believe
the MIDI organization has done just that, although I don't know what the
format looks like (since they don't publish it on the web).

> > 
> > Support for multiple GM/GS/XG soundfonts would be improved by allowing a
> > "base bank" or "bank offset" to be supplied.  SWAMI or FluidSynth?
> 
> Or a way to say "Please use the instrument at program 51 from GM.sf2 on
> MIDI channel 11", and only that specific part of the General MIDI
> soundfont file would be used in memory.
> > 
> > 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...
> 
> Yes, but I don't want to build new sound font files. I just want to use
> soundfonts. If being a Swami user means that I'm spending time making my
> own multi instrument soundfonts, then that is time I'm not spending
> making music. That's not to say Swami isn't necessary, but it might be
> of more interest to people making soundfonts on Linux DAWs, and less
> interesting to composers. Or it might be used to add special effects to
> a soundfont I like. I do not know. 
> 

Creating a virtual bank is fairly simple, its just pointers to other
files and bank:preset pairs. In a GUI (Smurf Sound Font Editor has
support for these) its just a matter of cutting and pasting presets from
different SoundFont files into the virtual bank. I can see Swami
becomming an instrument/bank manager in the future as well. So one would
use it while they are sequencing. As things are, I like to use Swami to
control effects in real time (not polyphonic yet, but could be).

Cheers.
        Josh Green





reply via email to

[Prev in Thread] Current Thread [Next in Thread]