[linux-audio-user] sf2 soundfont spec license

[Mark Constable]

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.

> 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