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
