Re: [linux-audio-user] sf2 soundfont spec license

On Thursday 10 March 2005 11:30 pm, Mark Constable wrote:
> Lee Revell wrote:
> >>Well, I'm looking at libinstpatch, which is what swami uses to process
> >>sf2 files. If it doesn't do what we need, then I'll start looking
> >>elsewhere. I'm expecting this to be the one to use though, since it's
> >>the file processing part of a patch editor.
> >
> > OK. Someone should describe their idea of how an accessible soundfont
> > editor should work.
>
> Julien wants something blind people can use, James wants
> something to feed his mouse-phobia, I want something I
> can run on remote web servers and be able to batch process,
> so a set of shell utilities (in the trues sense of *nix
> tools) would be the most "accessible".
>
> I find the top-left pane layout of smurf non-intuitive.
>
> It would be good if the sf2 decompiler would break open
> the original sf2 into instruments per folder inside a
> parent folder with the same/similar name as the original
> soundfont. The wav components could be named as the note
> the represent with perhaps a hint of extra meta info in
> the filename.. "a" (A note), "a+" (A# note), "a-" (Ab note).
> The non-wav meta info needs to be in the simplest plain
> text format possible and NOT XML nor scheme/lisp based if
> it's to be of any use with speech synths for blind people.
> Takashi's sf2text all-in-one format would be a nightmare
> for a speech synth to work thru... XML would be worse!
>
> The toplevel meta-text file inside the initial parent dir
> could contain something like...
>
> Name "8MBGSFX E-mu Rev B"
> SoundFont 2 0
> SamplePos 162 7393120
> InfoPos 24 118
> Presets 139
>
> then in each of the intrument folders the meta-text file
> would contain something like...
>
> 0
> Piano 1
> preset0
> bank0
> layer1 c.wav
> ... various info describing loop points, reverb settings...
>
> *IF* it was decided that following a heirarchical GM/GS
> layout was a good idea (I think so) then a folder layout
> something like this would be nice (from my point of view)...
>
> http://freepats.opensrc.org/freepats/Tone_000/
>
> with the variation that each instrument is contained within
> a folder simply called "000" then "001" etc. The results
> would be naturally sorted in standard file listings.
>
> 8mbgmsfx (parent folder)
> _ Tone (preset folder)
> _ _ 000 (instrument bank number)
> _ _ _ 000 (preset/instrument number)
> _ _ _ 001 (Piano 2 etc)
> _ Drum (drumset folder)
> _ _ 000 (drumset bank number)
> _ _ _ 000 (drumset patch)
>
> Now here is something that is quite simple and useful. Note
> the associated *.txt file to the 000_Acoustic_Grand_Piano.pat,
> the first line of that text file is used by a shell script
> in the parent directory to build a full Timidity *.cfg file
> with default extra settings per instrument (like amp and pan)
> and the rest of the file can be used for misc info like
> author, copyright, changelog or howto use stuff.
>
> This leads to each instrument being able to be independantly
> updated and managed, has crude version control via the misc
> notes in the associated text file, and the rebuild process
> can be simple and automated by shells scripts. Nice qualities.
>
> http://freepats.opensrc.org/mkcfg.sh.txt
> http://freepats.opensrc.org/mkdist.sh.txt
>
> Translate the above online GUSpat "repository" example to
> sf2 and it could easily be incorporated into the above site
> and also suit being a component of other online net-jamming
> setups... and of course, suit Juliens need for GUI-less
> usage.
>
> One other point about "inferior" GUI-less shell tools, when
> using channels like email/wikis/forums to provide help and
> usage instructions... it is overwhelmingly easier to copy
> and paste CLI based instructions, even verbatim, than it
> is to try and literally describe a bunch of point and click
> menu operations. Same principle with all those awful plain
> text config files we linux users have to put up with. As
> much as asoundrc and /etc/* config files can be a pain they
> sure do have that nice e-sharable quality about them.
>

All eminently sensible.

> > Does swami let you work with a MIDI keyboard, and assemble samples into
> > a soundfont while you play? Any soundfont editor that didn't have the
> > synth part built in would not be very usable.
>
> aplay should work. Perhaps it could be modified to play
> back a wav at a different pitch with an extra CLI arg.
>
> (Woops, I just noted this is probaby the wrong thread but
> I don't want to copy/type this all in again, apologies)
>
> --markc
Received on Fri Mar 11 20:08:36 2005