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