Sorry, for 'gianl' below read 'signal'.
On Thu, Jun 14, 2012 at 11:41:01AM -0700, Miller Puckette wrote:
I've been thinking about this for some days. I agree there are two fundamentally different approaches (A: deal with each incoming sample independently, for each one adding some sort of filter kernel into the table; or B: advancing systematically through the table, filling each point by interpolating from the input signal).
I think in approach A it's better not to attempt to normalize for speed since there would always be a step where you have to differentiate the location pointer to get a speed value and that's fraught with numerical peril. Plus, we don't know how much the 'user' will know about write pointer speed - perhaps there's a natural way to determine that, in which case the numerically robust way to deal is to have the user take care of it appropriately for the situation.
Aanyway, if we're simulating a real moving source (my favorite example being lightning) it's physically correct for the amplitude to go up if the source moves toward the listener, even to the point of generating a sonic boom.
In the other scenario it seems that the result is naturally normalized, in the sense that a signal of value '1' should put all ones in the table (because how else should you interpolate a function whose value is 1 everywhere?)
Choosing (A) for the moment, for me the design goal would be, "if someone writes a gianl equal to 1 and sent it to points 0, a, 2a, 3a, ... within some reasonable range of stretch values _a_, would I end up with a constant (which I wold suggest should be 1/a) everywhere in the table? If not you'd hear some sort of _a_ - dependent modulation.
I think you have to put a bound on _a_ - if it's allowed to be unbounded there's no fixed-size kernel that will work, and varying the size of the kernel again involves judging the "velocity" _a_ from the incoming data which I argued against already.
cheers Miller
On Thu, Jun 14, 2012 at 12:24:32PM -0500, Charles Henry wrote:
On Wed, Jun 13, 2012 at 6:14 PM, katja katjavetter@gmail.com wrote:
There should be an (optional) amplitude compensation for up- and downsampling, as an amplitude effect would be inconvenient in the case of a variable-speed sound-on-sound looper.
Katja
I think that a consideration here to justify a scaling effect is to deliver the same rate of power.
I like looking at this problem with sinc functions, because the spectrum becomes easy to see, and the energy is easy to calculate.
The function with sampling rate f_s and unit spectrum from -f_s/2 to f_s/2 is f_s*sinc(t*f_s). This function when it's convolved with itself, equals itself.
and if you have f1 < f2, f1*sinc(t*f1) convolved by f2*sinc(t*f2) = f1*sinc(t*f1) which is important for comparing interpolators at different frequencies.
The L2 norm of f_s*sinc(t*f_s) = f_s. Here's the term that grows larger when we increase f_s.
In a given block, you're always writing N samples. Your goal is to write N orthogonal functions that fills all the values in some interval and keep normalized the power during that interval.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list