On Thursday 10 March 2005 09:44 am, james(a)dis-dot-dat.net wrote: Anytime one has the authors email handy, that's a good idea. In light of the above, it's the actual "rendition" of the standard as recorded in that specific document that's at question. Like a copyright on a recording, as opposed to the copyright on the tune itself. Since it's publicly available, that fulfills the need. One could also make the interpretation that circulating it within the development community constitutes "internal". However, Mark's original email didn't supply sufficient background WRT to the standards origin. Is there sufficient legal structure behind it? IOW is it from a corporate structure with resources to make trouble?

On Thu, 2005-03-10 at 15:50 -0500, John Check wrote: I don't think this is a problem. Creative has never come after anyone for making and distributing their own soundfonts. They seem to have taken a hands-off attitude towards open source. Lee

On Thu, 2005-03-10 at 22:03 +0000, james(a)dis-dot-dat.net wrote: Yesm but there are many, many other standards (real standards, as ion ISO) implemented by open source software where the spec itself is not free. For example I don't even think the POSIX spec can be freely downloaded. Lee

On Thu, Mar 10, 2005 at 10:53:58PM +0100, Christoph Eckert wrote: I don't know how featurefull it is, but specimen's beef bank format might be worth looking into. I chatted with the author a while ago on #lad at freenode. My fuzzy memory is that it uses xml and wouldn't be too hard to script. -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact network(a)rfa.org.

Last Thursday 10 March 2005 22:21, Lee Revell was like: No, it's not necessary to re-invent the wheel. However, this is a discussion I've been waiting for for a while and I think it's useful to explore the possibilities. I would like to see the development of a standard GNU/Linux soundbank that is freely distributeable, so it could be bundled with DeMuDi and PlanetCCRMA etc. For this we need tools and to be sure we're using the right format. From what I understand, there is no limit on using the sf2 specification, but we wouldn't be able to change it. It is possible that new sample bank formats may come into existence naturally, but they would be unlikely to replace .sf2s at the present time. Any format will only catch on if there is a genuine need for it. I'm interested in some of the more peripheral issues that mostly affect new and non-technical users and I'm quite happy to work on it so that people dealing with core parts of the system don't have to bother with it. Remember we're on the user's list here. ;-) cheers, tim hall http://glastonburymusic.org.uk

yep, just my thoughts. I always wondered that sampling isn't more spread in the linux world. What about packing some flacs and some XML spec data into one 7zip file in a well defined arrangement and use this as a new file format? OK, it needs lots of knowledge to define the needed elements of the XML file and to create a really good file format, but IMHO this is something really needed. Best regards ce

Hi, well, to be honest, I'm not a coder, and I'm not familiar enough with sampling to create specs. Sounds as a wiki would be helpful. XML is hip, nothing else :) . Anyway, maybe it's wrong for a sampling format, but otherwise the advantage is that it is easily human readable as well as machine creatable. Just some hours before I read that there are people who'd like to create soundfonts automatically on remote machines; so the new format should be able to be created via shell scripts as well as defined easily be blind users or GUI frontends. So I guessed that XML isn't the least choice. This depends on the format. XML is a syntax or markup; you're right, there are XML files which are not very human readable. But we can do it better :) . I'm not that optimistic, but maybe I'm wrong. Best regards ce

Hi, Hmmm, my idea was not that much to create a new format due to features that soundfont lacks but to have a format which is absolutely free - and will ever be free. [...] Well, a further argument against XML is that if any device will ever be based on the new format, it needs lots of sontware in its firmware to read XML. So, perhaps a simpler format could be helpful. [...] Hehe, I'm not a pessimist at all, but I'm very pragmatic :) . Best regards & thanks for the thoughts ce

On Mon, 14 Mar, 2005 at 12:10AM +0100, Christoph Eckert spake thus: Fair enough. Your spec is "free SF2", then :) Good point. -- "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)

On Thu, 10 Mar, 2005 at 05:08PM -0500, Eric Dantan Rzewnicki spake thus: Sounds good, but until it's as common as SF2, I personally will stick with what we're trying to achieve here: a commandline SF2 processor, for mouse-o-phobics (like me) and for people that need something more accessible (like Julien). Which reminds me: Julien (if you're reading this) what would your requirements be? This isn't specifically for you, but you did cause this project to start, so you should have some input. James -- "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)

On Thu, 10 Mar, 2005 at 05:33PM -0500, Lee Revell spake thus: 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. -- "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)

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

On Thursday 10 March 2005 11:30 pm, Mark Constable wrote: All eminently sensible.

On Thursday 10 March 2005 04:53 pm, Christoph Eckert wrote: SoundFont != just sample data. If anything is an architecture for wavetable synthesis and a parameter storage format It might be feasible to spec something compatible though. IMO it would still be redundant.