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

From: <james@email-addr-hidden-dot-dat.net>
Date: Fri Mar 11 2005 - 10:17:31 EET

On Fri, 11 Mar, 2005 at 02:30PM +1000, Mark Constable spake thus:
> 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).

I'm not certain about this naming - sample data has a name associated
with it in the sf2 file already, and I think we should honour that.

> 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.

I agree - and not just for the blind. I wouldn't like having to write
three times as much just because it's in XML.

I do think, however, that some kind of scope clues are needed, perhaps
as start/end tags, bracketing or indentation (like python). Whatever
is easiest to understand and pass to a speech synth. Julien: advice?

> 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

I think we could get rid of samplepos and infopos (they only make
sense in the binary sf2) and even presets - why not let our compiler
count them?

> 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...

The only problem is that this doesn't really fit well with the
structure of the sf2 file. A single preset might make use of multiple
instruments, and those instruments might be used by other presets -
which dir would we put it in? We can't repeat the data.

I think a single top level file is probably best, with sections
describing presets, instruments and samples (although probably in
reverse order) with a sample dump dir or dirs. Not as pretty, but it
makes more sense, I think.

The hierarchy would be in the patch file - made as intuitive as
possible, of course.

We could have an include directive in the files - this way, you could
easily organise you patch dir in the way you suggest without forcing
it. Then, if you're having a one-to-one mapping between instruments
and presets and sample collections and instruments, you can do this.

> *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.

Agreed, although this is something for later, when the core
functionality is there. Personally, I'm not over fussed about this
part because I'm expecting to know the pitches of files already - I
intend to name them as their notes, as most people would.

While we're talking about these kinds of extra features, though - how
about something for determining the pitch automagically? A separate
tool that just returns a note (C-4, for example) when given a wav.
This would make it nice and simple to put a soundfont together without
having to listen to every sample. Unpitched samples ibviously won't
work, but you won't need them to.

> (Woops, I just noted this is probaby the wrong thread but
> I don't want to copy/type this all in again, apologies)
>
>

-- 
"I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb.  Thank you."
(By Vance Petree, Virginia Power)
Received on Fri Mar 11 12:15:04 2005

This archive was generated by hypermail 2.1.8 : Fri Mar 11 2005 - 12:15:05 EET