On Thu, 15 May 97 17:08:09 -0500, Eric Scheirer wrote:
>In message <199705151513.RAA26743@saturn.riv.be> Adam writes:
>> 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.
That's a very good point, from the viewpoint of the content provider. For
this purpose, I'd been taking the HTML point of view, where renderings
may be of different qualities, but the "content" (hopefully) remains the
same, regardless of browser. Having a filter become unstable certainly
changes the content. (Fun!)
So, do we specify such a thing as a minimum precision, or a minimum and
maximum requirement?
>>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?
You see, everything else is so precise elsewhere, so it would be nice to
establish a standard that does things "right." I'm an advocate of a
windowed sinc.
We certainly shouldn't say linear interpolation is the upper limit. But
there are plenty of efficiency arguments against band-limiting.
>>...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 point was supposed to be a general summary, and not about the allpass.
It was another way of saying the content should scale with the
implementation, but be usable everywhere. But, as above, the standard
should also provide the opportunity for near-"perfect" rendering.
>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.
Sounds great. That would make me happy on the filter performance end,
but...
> 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).
Oh, I know those opcodes well. (I know for my uses, 'reson' was the most
useful. Where did that one go?)
My argument isn't on what I would use it for, but just for providing a
comprehensive tool/framework. CSound provided several obscure short cuts
among the table generators ('logbessel' and 'cheby_poly' being the most
notable) which allowed for some powerful stuff integrated with the
language. I think that doing the same with parameterized filter design is
a reasonable application of the same philosophy, providing a powerful,
all-in-one tool for those who know how to use it.
>>[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.
No pattern recognition, no general signal processing. *Synthesis* is one
of SAOL's applications, but--as with when we were trying to define
SAFX--sophisticated audio processing is at least as important. If I need
a 31-pt FIR lowpass filter with a transition band from...[blah blah], do
I, as a content creator, need to design it also?
>>"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.
I think I see what you mean. Then all that needs to be changed is:
ksig 'MIDIbend' allows access to MIDI "pitchbend" information for this
note's *channel*
Guess I should point out the distinction between note "aftertouch" and
"channel pressure," which is more common in MIDI implementations.
"channel pressure" should probably be available in a similar way to
MIDIbend.
Adam
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Adam T. Lindsay, Research Scientist phn: 32.2.721.5454
Riverland Research fax: 32.2.721.5380
adam@riv.be url: www.riv.be/research/
"Proposal: A Book of Flemish Noses--
coffee-table type, like Roadside Shrines of India" -Brian Eno
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:11:08 EDT