11 Mar
2005
11 Mar
'05
8:14 a.m.
Okay, looking at both libinstpatch and sf2text, I'm getting a feel for
what we might want.
I have something that does /some/ extraction of info into a formatted
file. Still no wavs, but that's just because I wanted to get
something going quite quickly.
Rather than rabble on, here's an (incomplete) example:
head{
name=User Bank
sfversion=2.0
#0 presets, 0 instruments, 2 samples
}
samples{
sample{
#Sample 0
name=0sib
loopstart=102260
loopend=104523
rate=44100
opitch=60
pitchc=0
samplelink=0
type=1
}
sample{
#Sample 1
name=6mi
loopstart=158834
loopend=159451
rate=44100
opitch=60
pitchc=0
samplelink=0
type=1
}
}
It's fairly easy to follow, I think. Comments start with a # - these
are put in automatically for the decoding to add some extra info for
the human reader.
Now for some detail. At the moment, you'll see I have missed out
samplestart and sampleend. I don't think we need this in the text
file because it just relates to the wavs once they are packed - our
compiler should work all that out at compile-time.
We can also chop our rate, because it's something the wavs will
specify.
Original pitch and pitch correction are more awkward - numbers for
pitch aren't great. Can we agree on a format for this? Like C-1 for
first octave C, etc.
Pitch correction I think is in semitones - if not, I think we should
convert it to that and back again so the user can work with a musical
abstraction rather than anything more low level.
Sample link I think we should remove completely and replace it with a
sample file name - the order means nothing outside of the soundfont.
And type can be made more readable.
Instruments will be similar, as will presets. All references should
be made by name, I think, ratehr than position, for obvious reasons.
Okay - does anyone have any thoughts on this? Any
suggestions/corrections/better ideas?
Oh, and I've only just noticed that we're using the LAU list and
probably ought to move either to the LAD list or a separate one
altogether of we're going to keep up this volume - awkward choice
because more eyes means more input, but also more annoyance for
uninterested readers. Thoughts, anyone?
James
On Fri, 11 Mar, 2005 at 01:27AM +1000, Mark Constable spake thus:
james(a)dis-dot-dat.net wrote:
--
"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)
I see you're already on top of checking out
the licensing.
It's as much to see if there are others out there with
a similar interest... and maybe someones been way down
this path already and has got some time-saving comments.
Shall we agree, then, on the first step?
We can always try :-)
I think we should take a look at the format in
detail, see exactly
what goes into it and then agree on how we want to structure our
soundfont-source file. Once we have that, we can start writing the
compiler/decompiler to a specification, or working on a sf processing
library that we can then use to make the apps.
I skimmed thru the pdf spec and lasted about 15 minutes
before going cross-eyed.
If we both start examining the file and writing a
preliminary source
format, we can take the best from both and ensure neither of us has
missed anything.
Sound like a good start?
Well we could keep "talking about it" forever so I agree
it would be better if we independantly dived in and got
some hands on with the spec and some code... then compare
serious "paper" notes.
Once we have something to work on, we can sort out
where we're going
to keep things (cvs/sourceforge/savannah/etc) and how we're going to
divide up the work.
My goodness, sounds like a plan! For now we can throw
comments and URLs at each other and if others show any
interest we can externalize and formalize the process in
a number of conventional ways.
Heh... here's a note of some related effort and some code
that could perhaps provide some hints... maybe.
http://sourceforge.net/mailarchive/forum.php?thread_id=6703044&forum_id…