11 Mar
2005
11 Mar
'05
4:17 a.m.
On Fri, 11 Mar, 2005 at 02:30PM +1000, Mark Constable spake thus:
Lee Revell wrote:
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.
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. 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.
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.
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)
--
"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)