In message <199705151513.RAA26743@saturn.riv.be> Adam writes:
>Hello, all. Since things have been quiet lately, I thought I'd throw out
>a few comments, suggestions, what-ifs, and how-abouts to provoke some
>discussion.
Thanks to Adam for these.
>One major issue that I've mentioned briefly to Eric is the divide between
>language specification and implementation requirements. I think there a
>few things that are "hard-wired" in the draft that needn't be, and
>vice-versa.
In general, I agree that this is one of the trickiest areas of the standardization
process. There's a huge debate raging on one of the other MPEG reflectors
about appropriate levels of normativity and validation for structured
media contant, like synthetic audio.
> About the internal representation of a sample as double-precision float,
>I know there was some discussion on this. Is this something that must be
>part of the specification? For example, is it appropriate for the
>MIDI-only profile?
This last is a good point. I see no good reason for standardizing numeric
precision for the MIDI profile past that necessary to provide reasonable
temporal granularity. I'll include it in the next change list.
My major concern about numeric precision is for certain numerically-sensitive
opcodes, like IIR filters implemented with 'biquad'. It's difficult to
see what to do in the case that (1) low-precision and high-precision
results will differ for some instrument, and (2) people want to implement
things in low-precision. I'm happy to hear more thoughts.
>The "Sample Conversion" subsection was changed to include fracdelay, to
>distinguish efficient delays from less efficient, accurate, dynamic
>delays. It seems like the first time this distinction has been made:
>upsamp specifies linear interpolation, and the oscil family makes no
>mention of it whatsoever. Should we address band-limited interpolation?
I agree that the oscil family should mention it. Linear interpolation?
>"allpass" has a similar sort of inconsistency in the line, "The delay is
>specified in seconds and rounded to the nearest sample for
>implementation."
I'm not sure why this is "inconsistant". Integer-delay allpasses and
combs ("comb" has the same semantics) are quite useful. If better
interpolation is needed in some unusual application, you can deliver
your own routine.
>...the bigger point being that I can envision SAOL being used by a wide
>variety of users. Some are going to be mastering content for digital
>distribution, and therefore exacting about the sound quality. Others
>could be playing it through a mono speaker, and couldn't give a whit
>about a little foldover.
The problem with only having integer delays in these opcodes isn't
foldover (aliasing), it's quantization of the frequency response peaks --
that is, the sampling rate limits the accuracy with which we can set
these peaks. For most of the instruments and applications I'm aware
of incorporating allpasses, for example, this isn't much of a concern.
>The filter options seem a little limited.
>How about adding some FIR filter design table generators (a la MATLAB's
>sigproc)?
>A convolution opcode?
>A filter opcode (using two tables instead of serial biquads)?
I'm planning to include both 'fir' and 'iir' opcodes in the next draft.
Also pow, log10, asin, acos, floor, ceil, min, max, ftsetloop, ftsetend,
and ftsetbase. I don't really think that filter design needs to be
included, but I'm willing to listen to an argument. ('lopass', 'bandpass',
etc already implement simple parametric filtering).
>I think all of these would get more use than Chebyshev Polynomials...
Only because not enough people know how to use Chebyshev Polynomials!
>[as an aside, I think chebys are cool. But I also think that SAOL's
>design is a little too influenced by its academic heritage-- some
>meat-and-potato signal processing is left as an exercise to the student.]
I agree with this in part; on the other hand, SAOL is meant for
*synthesis*, not general-purpose signal processing or audio pattern
recognition. We're not trying to replace Matlab! The expansion of the
standard -- making implementations that much larger and more expensive
for producers/consumers -- should be driven by clear application needs.
>"ksig MIDIbend allows access to MIDI "pitchbend" information for this
>note."
>I believe pitchbend is typically by channel. Minor, niggling point.
Yes, but the standard names are available on a note-to-note basis. That
is, the instrument may be triggered on multiple channels at once, and
thereby the MIDIbend will differ from note to note, where the notes
are separate instrument instantiations. The channel->note mapping
is orthogonal to the instrument->note mapping.
-- Eric
+-------------------+
| Eric Scheirer | A-7b5 D7b9 | G-7 C7 | Cb C-7b5 F7#9 | Bb | B-7 E7 |
| eds@media.mit.edu | < http://sound.media.mit.edu/~eds >
| 617 253 0112 | A A/G# F#-7 F#-/E | Eb-7b5 D7b5 | Db | C7b5 B7b5 | Bb |
+-------------------+
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:11:08 EDT