On Fri, 11 Mar, 2005 at 11:37AM -0500, John Check spake thus: > On Friday 11 March 2005 11:08 am, james@xxxxxxxxxxxxxxx wrote: > > On Fri, 11 Mar, 2005 at 10:35AM -0500, John Check spake thus: > > > > <snip> > > > > > Too, there are a carload of parameters per sample * instruments * > > > presets. > > > > > > > Ideally, we want a way to be able to create soundfonts as they are > > > > needed with commandline tools. You get the accessibility, plus you > > > > can write the patch descriptions in any editor, or from a script, > > > > whatever. You then just compile the description and waves into a > > > > soundfont. This way is much more flexible. > > > > > > First thing that comes to mind from an efficiency POV is setting loop > > > points in the individual samples (snippet) that make up the instruments. > > > I don't know what kind of algorithm it would take.. finding zero > > > crossings is easy enough, but getting a smooth loop can be a challenge > > > WRT timbre. > > > > This is a good point, and although it relates to the commandline sf > > tools, it's probably best kept as a separate problem. If we get this > > part right, a sample auditor could be used that exports the loop > > points and puts them in the description file. > > > > Really, I was more concerned with the first part of that than timbre. > It would be nice if there was a quick way to audition the loop points. I mean the same thing. What we'll end up with here are a number of tools, not just one. Adding one more to work with loop offsets is probably a good idea, but we can ignore it for now and concentrate on the actual compiling/decompiling. I think your idea is a good one. > > > > > > > cheers, > > > > > > > > > > tim hall > > > > > http://glastonburymusic.org.uk > -- "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)
