[linux-audio-user] Re: Anyone interested in helping with melotron

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@email-addr-hidden-dot-dat.net wrote:
> >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=12842
>
>

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