Re: [PD] better tabread4~
On Sat, Jul 19, 2008 at 10:33 PM, Matt Barber [EMAIL PROTECTED] wrote: Right -- wouldn't this be equivalent to doing the (defined) interpolation and the anti-aliasing as a filter in one step? You're modulating the interpolating function to include the effects of the appropriate anti-aliasing filter -- like a one-step sample rate converter. Except, the ratio between the source and target rates is variable. Is this an inappropriate way to be thinking about it? Yes, that's it. I guess one problem is how speed is measured -- do you just use absolute value of the index delta from one sample to the next (what happens when the index is not a linear function of time)? Or could you fill something like a delay line with past index positions and then use those to find speed as a three- or five-point approximation of the first derivative -- this would add a few samples of delay but might give a better estimate of speed. Sorry to be dense with the questions, but I want to keep up the best I can. =o) Yes, that's exactly right, also. The input is a sequence of table indexes, so the speed is the first derivative of the input. There is something problematic, when the user wants to jump between different positions in the table. Those instances shouldn't be treated as playing at high speed--it would just be glitchy. I would suggest a look-ahead method to figure out the speed, when there are rapid changes, to avoid having an error. I've got two basic ideas that I'm playing with. The first is to modify the interpolation function continuously adding a series of bumps that are spaced exponentially outward from the original function. If there's some good spectral properties, there could be a way to make a smooth transition and hold the number of calculations to O(log(speed)) instead of O(speed) My second idea is to replace the points and their derivatives, with filters (low-pass filters for the points and band-pass filters for the derivatives). Then, fit a polynomial as before and interpolate. Like existing schemes, this could be turned into continuous functions for impulse response, which vary as functions of speed. Any ideas? Can you give a quick example of the form of each idea? Not particularly... I'm only working with intuition for the idea so far. It's going to take some insight or inspiration. Do you have any ideas? In the first, are you adding bumps to the interpolator's impulse response? In the second are you saying you would replace a point with the impulse response of a low-pass filter (e.g. in a 5th-degree polynomial with coefficients a0 a1 a2 a3 a4 and a5, instead of matching a0+a1+a2+a3+a4+a5 with y[1] you'd match it with an impulse response centered on y[1])? Would the algebra still be such that you could keep the form for derivatives of the polynomials (in the last example, 2*a2+6*a3+12*a4+20*a5 as the 2nd derivative at y[1]) even though you're matching them with something other than an approximation? Feeling my way through, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Sorry it took me so long to make something usable out of that mess. I played around with factoring but it seems like it got me nowhere, so I finally just multiplied out all the polynomials to get the usual form. (given input points g[-2] g[-1] g[0] g[1] g[2] g[3] a5 = 3/64*g[-2] + 13/64*g[-1] - 27/32*g[0] + 27/32*g[1] - 13/64*g[2] - 3/64*g[3] a4 = -3/16*g[-2] - 19/64*g[-1] + 63/32*g[0] - 9/4*g[1] + 23/32*g[2] + 3/64*g[3] a3 = 9/32*g[-2] - 9/16*g[-1] + 9/16*g[1] - 9/32*g[2] a2 = -3/16*g[-2] + 5/4*g[-1] - 17/8*g[0] +5/4*g[1] - 3/16*g[2] a1 = 3/64*g[-2] - 19/32*g[-1] + 19/32*g[1] - 3/64*g[2] a0=g[0] output[x]=a5*x+a4)*x+a3)*x+a2*x)+a1)*x+a0 and I did some analysis of the function: This function is continuous up to the 3rd derivative with derivative approximations: g'(0)=3/64*g[-2] - 19/32*g[-1] + 19/32*g[1] - 3/64*g[2] g''(0)=-3/8*g[-2] + 5/2*g[-1] - 17/4*g[0] + 5/2*g[1] - 3/8*g[2] g'''(0)=27/16*g[-2] - 27/8*g[-1] + 27/8*g[1] - 27/16*g[2] but here's the rub. These approximations of the derivatives are horrible. They have terrible spectral response and are not very good for higher frequencies. I'm not sure what this all means in terms of how they sound, but I've got a solid grasp on how this problem works. 1st off: the number of computations is roughly linearly proportional to the number of points, and the degree of the polynomial. 2nd: High frequency response can be obtained by increasing the number of points, beyond the number of points required to constrain the problem for a given degree of polynomial. 3rd: The set of functions specifying the impulse response as sums of (|t|-a)^n*(|t| a) should be used to construct interpolating polynomials for two clear reasons. First, the lowest degree of polynomial, n, that is used determines the number of continuous derivatives (for n=2, there is 1 continuous derivative, for n=4, there are 3 continuous derivatives). Second, n determines the fastest possible rate of attenuation in the stop-band (for n=2, 1/w^3, for n=4, 1/w^5, etc...) In the accompanying graphs, the newest spectrum has been added in magenta. And the question is, where do we go from here are there any remaining problems with tabread's? Is the high-frequency response good enough? Do we need faster attenuation? I think there is little point in trying to increase the rate of attenuation. 1/w^3 is good for a fast interpolator. 1/w^5 should be good enough for a high-accuracy interpolator (in my opinion) so if this were carried out to 8-point, 10-point and so on we could get better high-frequency response. a. I don't know! Chuck attachment: spectrum_tab6.png___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Chuck, Thanks again for this. Quick question: out of curiosity, how much would this differ from the one which has the standard derivative approximations? Also, if one wanted to put together the one with the standard approximations, would you use the best approximations available for each derivative, or would you use the ones which come from the same series of approximations? I don't know how to call them, but one series of approximation derivations need a 3 points for 1st and 2nd derivatives, and 5 points for 3rd and 4th -- while the next series up needs 5 points for 1st and 2nd and 7 for 3rd and 4th -- can you mix these freely in a 6-point interpolation using the 5-point approximations for everything? I guess one important next direction is to work on the anti-aliasing problem -- you mentioned modulating the interpolation coefficients depending on the speed through the table -- would this be a continuous thing, or would there be a pre-defined set of ideal functions among which to choose? Or would this be a matter of figuring out the linear combination of the appropriate anti-aliasing filter (which might need to change with each sample?) and a standard interpolation function? (or am I totally misunderstanding?) Thanks again, Matt On Sat, Jul 19, 2008 at 3:40 PM, Charles Henry [EMAIL PROTECTED] wrote: Sorry it took me so long to make something usable out of that mess. I played around with factoring but it seems like it got me nowhere, so I finally just multiplied out all the polynomials to get the usual form. (given input points g[-2] g[-1] g[0] g[1] g[2] g[3] a5 = 3/64*g[-2] + 13/64*g[-1] - 27/32*g[0] + 27/32*g[1] - 13/64*g[2] - 3/64*g[3] a4 = -3/16*g[-2] - 19/64*g[-1] + 63/32*g[0] - 9/4*g[1] + 23/32*g[2] + 3/64*g[3] a3 = 9/32*g[-2] - 9/16*g[-1] + 9/16*g[1] - 9/32*g[2] a2 = -3/16*g[-2] + 5/4*g[-1] - 17/8*g[0] +5/4*g[1] - 3/16*g[2] a1 = 3/64*g[-2] - 19/32*g[-1] + 19/32*g[1] - 3/64*g[2] a0=g[0] output[x]=a5*x+a4)*x+a3)*x+a2*x)+a1)*x+a0 and I did some analysis of the function: This function is continuous up to the 3rd derivative with derivative approximations: g'(0)=3/64*g[-2] - 19/32*g[-1] + 19/32*g[1] - 3/64*g[2] g''(0)=-3/8*g[-2] + 5/2*g[-1] - 17/4*g[0] + 5/2*g[1] - 3/8*g[2] g'''(0)=27/16*g[-2] - 27/8*g[-1] + 27/8*g[1] - 27/16*g[2] but here's the rub. These approximations of the derivatives are horrible. They have terrible spectral response and are not very good for higher frequencies. I'm not sure what this all means in terms of how they sound, but I've got a solid grasp on how this problem works. 1st off: the number of computations is roughly linearly proportional to the number of points, and the degree of the polynomial. 2nd: High frequency response can be obtained by increasing the number of points, beyond the number of points required to constrain the problem for a given degree of polynomial. 3rd: The set of functions specifying the impulse response as sums of (|t|-a)^n*(|t| a) should be used to construct interpolating polynomials for two clear reasons. First, the lowest degree of polynomial, n, that is used determines the number of continuous derivatives (for n=2, there is 1 continuous derivative, for n=4, there are 3 continuous derivatives). Second, n determines the fastest possible rate of attenuation in the stop-band (for n=2, 1/w^3, for n=4, 1/w^5, etc...) In the accompanying graphs, the newest spectrum has been added in magenta. And the question is, where do we go from here are there any remaining problems with tabread's? Is the high-frequency response good enough? Do we need faster attenuation? I think there is little point in trying to increase the rate of attenuation. 1/w^3 is good for a fast interpolator. 1/w^5 should be good enough for a high-accuracy interpolator (in my opinion) so if this were carried out to 8-point, 10-point and so on we could get better high-frequency response. a. I don't know! Chuck ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
The interpolation function is a filter. There would be no need to have an anti-aliasing filter and and interpolation function--there's just the one function. We use the fast interpolating function at speeds = 1. But we need a general interpolation function as a function of speed that converges to the original function as the speed decreases to 1. This would provide the needed generality and flexibility, while having the same general characteristics of the fast interpolating function on which it is based. I'm open to any ideas on this thing... I think I need to take my eyes off of interpolation for a while, and stop beating up the pd list with tables :) Right -- wouldn't this be equivalent to doing the (defined) interpolation and the anti-aliasing as a filter in one step? You're modulating the interpolating function to include the effects of the appropriate anti-aliasing filter -- like a one-step sample rate converter. Except, the ratio between the source and target rates is variable. Is this an inappropriate way to be thinking about it? I guess one problem is how speed is measured -- do you just use absolute value of the index delta from one sample to the next (what happens when the index is not a linear function of time)? Or could you fill something like a delay line with past index positions and then use those to find speed as a three- or five-point approximation of the first derivative -- this would add a few samples of delay but might give a better estimate of speed. Sorry to be dense with the questions, but I want to keep up the best I can. =o) I've got two basic ideas that I'm playing with. The first is to modify the interpolation function continuously adding a series of bumps that are spaced exponentially outward from the original function. If there's some good spectral properties, there could be a way to make a smooth transition and hold the number of calculations to O(log(speed)) instead of O(speed) My second idea is to replace the points and their derivatives, with filters (low-pass filters for the points and band-pass filters for the derivatives). Then, fit a polynomial as before and interpolate. Like existing schemes, this could be turned into continuous functions for impulse response, which vary as functions of speed. Any ideas? Can you give a quick example of the form of each idea? In the first, are you adding bumps to the interpolator's impulse response? In the second are you saying you would replace a point with the impulse response of a low-pass filter (e.g. in a 5th-degree polynomial with coefficients a0 a1 a2 a3 a4 and a5, instead of matching a0+a1+a2+a3+a4+a5 with y[1] you'd match it with an impulse response centered on y[1])? Would the algebra still be such that you could keep the form for derivatives of the polynomials (in the last example, 2*a2+6*a3+12*a4+20*a5 as the 2nd derivative at y[1]) even though you're matching them with something other than an approximation? Feeling my way through, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
More tables and math... Let me go ahead and re-print the previous table of fourier transforms and add some more functions to it, that will simplify things. remember, these functions are non-zero on the interval from [-a,a] and zero, elsewhere f(t) | F(w) 1 | 2/w*sin(aw) |t|| 2a/w*sin(aw) + 2/w^2*(cos(aw)-1) t^2 | 2a^2/w*sin(aw) + 4a/w^2*cos(aw) - 4/w^3*sin(aw) |t|^3 | 2a^3/w*sin(aw) + 6a^2/w^2*cos(aw) - 12a/w^3*sin(aw) - 12/w^4*(cos(aw)-1) and a new set of functions that seem to be more useful, because terms cancel. I'll also include another column for the limit as w-0. f(t) | lim(w-0) F(w) | F(w) |t| - a |-a^2 |2/w^2*(cos(aw)-1) (|t| - a)^2 | 2/3*a^3 |4a/w^2 - 4/w^3*sin(aw) (|t| - a)^3 | -1/2*a^4 | -6a^2/w^2 - 12/w^4*(cos(aw)-1) (|t| - a)^4 | 2/5*a^5 |8a^3/w^2 - 48a/w^4 + 48/w^5*sin(aw) (|t| - a)^5 | -1/3*a^6 | -10a^4/w^2 + 120a^2/w^4 + 240/w^6*(cos(aw)-1) (|t| - a)^6 | 2/7*a^7 |12a^5/w^2 - 240a^3/w^4 + 1440a/w^6 - 1440/w^7*sin(aw) (|t| - a)^7 | -1/4*a^8 | -14a^6/w^2 + 420a^4/w^4 - 5040a^2/w^6 - 10080/w^8*(cos(aw)-1) There is a general form for these functions, but I'm struggling to put it in a good way. I will show the last 4 functions F(w) to show the pattern. (if anyone wants to continue this work to bigger and bigger polynomials, I hope this spares some headaches) (|t| - a)^4 |4*2*a^3/w^2 - 4!/(4-3)!*2*a/w^4 + 4!*2/w^5*sin(aw) (|t| - a)^5 | -5*2*a^4/w^2 + 5!/(5-3)!*2*a^2/w^4 + 5!*2/w^6*(cos(aw)-1) (|t| - a)^6 |6*2*a^5/w^2 - 6!/(6-3)!*2*a^3/w^4 + 6!/(6-5)!*2*a/w^6 - 6!*2/w^7*sin(aw) (|t| - a)^7 | -7*2*a^6/w^2 + 7!/(7-3)!*2*a^4/w^4 - 7!/(7-5)!*2*a^2/w^6 - 7!*2/w^8*(cos(aw)-1) okay, to business. We want to construct a 6-point polynomial, whose spectrum falls off at a rate of 1/w^5. I haven't exactly worked out the rationale, but this math is tedious and slow and haven't gotten much of a solid pattern established. We will construct a fully constrained polynomial, using the functions (|t|-a)^4 and (|t|-a)^5 using a=1, a=2, and a=3. To try to keep the terms clear, b4 is the coefficient of (|t| - 1)^4 on the interval [-1,1] b5 is the coefficient of (|t| - 1)^5 on the interval [-1,1] c4 is the coefficient of (|t| - 2)^4 on the interval [-2,2] c5 is the coefficient of (|t| - 2)^5 on the interval [-2,2] d4 is the coefficient of (|t| - 3)^4 on the interval [-3,3] d5 is the coefficient of (|t| - 3)^5 on the interval [-3,3] We need to set the following constraints: 1. 1/w^2 terms cancel 8*b4 - 10*b5 + 64*c4 - 160*c5 + 216*d4 - 810*d5 = 0 2. 1/w^4 terms cancel -48*b4 + 120*b5 - 96*c4 + 480*c5 -144*d4 + 1080*d5 = 0 3. f(0)=1 b4 - b5 + 16*c4 - 32*c5 + 81*d4 - 243*d5 = 1 4. f(1)=0 c4 - c5 + 16*d4 - 32*d5 = 0 5. f(2)=0 d4 - d5 = 0 6. lim(w-0, F(w)) = 1 2/5*b4 - 1/3*b5 + 64/5*c4 - 64/3*c5 + 486/5*d4 - 729/3*d5 = 1 Solve by linear algebra, b4= -125/64 b5= -67/64 c4= 29/32 c5= 5/32 d4= 3/64 d5= 3/64 f(t)= (|t| 1) * [ -67/64*(|t| - 1)^5 - 125/64*(|t| - 1)^4 ] + (|t| 2) * [ 5/32*(|t| - 2)^5 + 29/32*(|t| - 2)^4 ] + (|t| 3) * [ 3/64*(|t| - 3)^5 + 3/64*(|t| - 3)^4 ] F(w) = 1/w^5*( -375/4*sin(w) + 87/2*sin(2w) + 9/4*sin(3w)) + 1/w^6*(405/2 - 1005/4*cos(w) + 75/2*cos(2w) + 45/4*cos(3w)) okay, so now, we've set the spectrum and impulse response 1st, and we need to work backwards to find the polynomial interpolation. We need to re-write everything in terms of x on [0,1] from the left: substitute t = -2 -x (coefficient of g[-2]) 3/64*(| -2 - x| - 3)^5 + 3/64*(| -2 -x| - 3)^4) =3/64*(x-1)^5 + 3/64*(x-1)^4 substitute t = -1 -x (coefficient of g[-1]) 3/64*(| -1 - x| - 3)^5 + 3/64*(| -1 -x| - 3)^4) + 5/32*(| -1 -x| - 2)^5 + 29/32*(|-1 - x| - 2)^4 =3/64*(x-2)^5 + 3/64*(x-2)^4 + 5/32*(x-1)^5 + 29/32*(x-1)^4 substitute t = -x (coefficient of g[0]) 3/64*(| -x| - 3)^5 + 3/64*(| -x| - 3)^4) + 5/32*(| -x| - 2)^5 + 29/32*(| - x| - 2)^4 + 3/64*(| -x| - 3)^5 + 3/64*(| -x| - 3)^4 - 67/64*(| -x| - 1)^5 - 125/64*(| -x| - 1)^4 =3/64*(x-3)^5 + 3/64*(x-3)^4 + 5/32*(x-2)^5 + 29/32*(x-2)^4 - 67/64*(x-1)^5 - 125/64*(x-1)^4 ---substitute t = 1 -x (coefficient of g[1]) 3/64*(|1 -x| - 3)^5 + 3/64*(|1 -x| - 3)^4) + 5/32*(|1 -x| - 2)^5 + 29/32*(|1 - x| - 2)^4 + 3/64*(|1 -x| - 3)^5 + 3/64*(|1 -x| - 3)^4 - 67/64*(|1 -x| - 1)^5 - 125/64*(|1 -x| - 1)^4 =3/64*(-x-2)^5 + 3/64*(-x-2)^4 + 5/32*(-x-1)^5 + 29/32*(-x-1)^4 - 67/64*(-x)^5 - 125/64*(-x)^4 = -3/64*(x+2)^5 + 3/64*(x+2)^4 - 5/32*(x+1)^5 + 29/32*(x+1)^4 + 67/64*x^5 - 125/64*x^4 ---substitute t = 2 -x (coefficient of g[2]) 3/64*(| 2 - x| - 3)^5 + 3/64*(| 2 -x| - 3)^4) + 5/32*(| 2 -x| - 2)^5 + 29/32*(| 2 - x| - 2)^4 =3/64*(-x-1)^5 + 3/64*(-1x-1)^4 + 5/32*(-x)^5 + 29/32*(-x)^4 = -3/64*(x+1)^5 + 3/64*(x+1)^4 - 5/32*x^5 + 29/32*x^4 --substitute t = 3 -x (coefficient of g[3]) 3/64*(| 3 - x| - 3)^5 +
Re: [PD] better tabread4~
Matt Barber a écrit : Cyrille, Could you try this optimization for the tabread6c~ I threw together? It uses the same general notation as the tab4c~ suite: t_sample a3plusa4plusa5 = 0.25f*c+0.125f*e-0.333f*d-0.0417*a; t_sample fminusa = f-a; t_sample eminusb = e-b; t_sample dminusc = d-c; a5 = 0.208f*((fminusa-5.f*eminusb+10.f*dminusc)); a4 = 2.667f*eminusb-0.5f*fminusa-5.5f*dminusc-a3plusa4plusa5; a3 = a3plusa4plusa5-a4-a5; a2 = 0.667f*(d+b)-0.0417f*(a+e)-1.25f*c; a1 = 0.667f*(d-b)+0.0833f*(a-e); a0 = c; *out++ = a5 * frac + a4 ) * frac + a3) * frac + a2) * frac + a1) * frac + a0; ok I've tested it and I think it works... I count 20 *'s and 25 +'s = 45 ops vs. 31 *'s, and 27 +'s = 58 ops (if the fractions were written out as decimals). The compiler should be intelligent enough to convert (2./3.) to 0.666... but using more precision than the 8 digit you write in your code. so i prefer the exact fraction than approximation... cyrille Thanks, Matt Date: Tue, 08 Jul 2008 18:35:51 +0200 From: cyrille henry [EMAIL PROTECTED] Subject: Re: [PD] better tabread4~ To: Charles Henry [EMAIL PROTECTED] Cc: pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed hello Chuck, i tested this. (and commited) i think tabread6c~ is a bit better than tabread4c~. but differences are more smaller thx Cyrille Charles Henry a ?crit : On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry [EMAIL PROTECTED] wrote: The coefficients used in this scheme are a0= Y[0] a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2] a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] + 7/24*Y[3] a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] - 1/2*Y[3] a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] + 5/24*Y[3] ___ 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
Re: [PD] better tabread4~
On Wed, Jul 9, 2008 at 4:39 AM, cyrille henry [EMAIL PROTECTED] wrote: Matt Barber a écrit : Cyrille, Could you try this optimization for the tabread6c~ I threw together? It uses the same general notation as the tab4c~ suite: t_sample a3plusa4plusa5 = 0.25f*c+0.125f*e-0.333f*d-0.0417*a; t_sample fminusa = f-a; t_sample eminusb = e-b; t_sample dminusc = d-c; a5 = 0.208f*((fminusa-5.f*eminusb+10.f*dminusc)); a4 = 2.667f*eminusb-0.5f*fminusa-5.5f*dminusc-a3plusa4plusa5; a3 = a3plusa4plusa5-a4-a5; a2 = 0.667f*(d+b)-0.0417f*(a+e)-1.25f*c; a1 = 0.667f*(d-b)+0.0833f*(a-e); a0 = c; *out++ = a5 * frac + a4 ) * frac + a3) * frac + a2) * frac + a1) * frac + a0; ok I've tested it and I think it works... I count 20 *'s and 25 +'s = 45 ops vs. 31 *'s, and 27 +'s = 58 ops (if the fractions were written out as decimals). The compiler should be intelligent enough to convert (2./3.) to 0.666... but using more precision than the 8 digit you write in your code. so i prefer the exact fraction than approximation... A great point I had considered a while back but didn't trust -- I'm glad you let me know this would work. I'm making a collection of these schemes, so I'll go check that out in the other formulas. Thanks again, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
hello Chuck, i tested this. (and commited) i think tabread6c~ is a bit better than tabread4c~. but differences are more smaller thx Cyrille Charles Henry a écrit : On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry [EMAIL PROTECTED] wrote: ok, i'll try that. but i don't think adjusting the 2nd derivative is the best thing to do. for me, having a 6 point interpolation would be more important. I put together a 6-point interpolation formula and analyzed it. For this I used a 5th degree polynomial, and 6 constraints: (I want to change up the notation a bit, and not use the letters a, b, c, etc... when switching to 6-point. Y[-2],Y[-1],Y[0], Y[1], Y[2], Y[3] are the points from the table. a5 is the coefficient of x^5, a4 is the coeff. of x^4, ... a0 is a constant term. f(x) is the interpolation polynomial.) f(0)=Y[0] f(1)=Y[1] f'(0)= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] f'(1)= 1/12*Y[-1] - 2/3*Y[0] + 2/3*Y[2] - 1/12*Y[3] f''(0)= -1/12*Y[-2] + 4/3*Y[-1] - 5/2*Y[0] + 4/3*Y[1] - 1/12*Y[2] f''(1)= -1/12*Y[-1] + 4/3*Y[0] - 5/2*Y[1] + 4/3*Y[2] - 1/12*Y[3] This uses improved approximations for the derivative. One advantage of going to 6-point interpolation is to get better numerical derivatives. These approximations of the 1st and 2nd derivatives are accurate up to a higher frequency than before. We can also continue to increase the number of points arbitrarily, without necessarily having to increase the degree of the polynomial. The degree of the polynomial is only determined by the number of constraints, not the number of points. The coefficients used in this scheme are a0= Y[0] a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2] a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] + 7/24*Y[3] a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] - 1/2*Y[3] a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] + 5/24*Y[3] After that, I continued with the impulse response calculations and spectral response calculations, which are a bit disappointing. I'll spare you the equations (for now) and post the graphs. The new traces for the 6-point interpolator are shown in green. It's a little bit hard to see, but the things to look for are the rate at which the graph falls off and the locations of the peaks. The 6-point function has a flatter spectrum, which comes up closer to the Nyquist frequency, and falls off faster. These are the key characteristics of the spectrum we want. The green trace falls off according to 1/w^4, compared to 1/w^3 for tabread4c~ and 1/w^2 for tabread4~ You can see the impulse response in the first graph along with the spectrum. The log vs. dB scale is used same as before, and secondly, I've posted a linear graph, so you can see the difference between functions near the Nyquist frequency (x=pi). It gives me some ideas for another 6-point scheme, more like tabread4c~, which will fall off at a rate of 1/w^5 and have more notches in the frequency response. I'll work on it a bit, and see how it goes. Chuck ___ 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
Re: [PD] better tabread4~
Hey, Cyrille, I kind of thought so... we are quickly running into the law of diminishing returns. I was up late, last night, working on the analysis some more. I think I can have another 6-point version with better characteristics tonight. Chuck On Tue, Jul 8, 2008 at 11:35 AM, cyrille henry [EMAIL PROTECTED] wrote: hello Chuck, i tested this. (and commited) i think tabread6c~ is a bit better than tabread4c~. but differences are more smaller thx Cyrille Charles Henry a écrit : On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry [EMAIL PROTECTED] wrote: ok, i'll try that. but i don't think adjusting the 2nd derivative is the best thing to do. for me, having a 6 point interpolation would be more important. I put together a 6-point interpolation formula and analyzed it. For this I used a 5th degree polynomial, and 6 constraints: (I want to change up the notation a bit, and not use the letters a, b, c, etc... when switching to 6-point. Y[-2],Y[-1],Y[0], Y[1], Y[2], Y[3] are the points from the table. a5 is the coefficient of x^5, a4 is the coeff. of x^4, ... a0 is a constant term. f(x) is the interpolation polynomial.) f(0)=Y[0] f(1)=Y[1] f'(0)= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] f'(1)= 1/12*Y[-1] - 2/3*Y[0] + 2/3*Y[2] - 1/12*Y[3] f''(0)= -1/12*Y[-2] + 4/3*Y[-1] - 5/2*Y[0] + 4/3*Y[1] - 1/12*Y[2] f''(1)= -1/12*Y[-1] + 4/3*Y[0] - 5/2*Y[1] + 4/3*Y[2] - 1/12*Y[3] This uses improved approximations for the derivative. One advantage of going to 6-point interpolation is to get better numerical derivatives. These approximations of the 1st and 2nd derivatives are accurate up to a higher frequency than before. We can also continue to increase the number of points arbitrarily, without necessarily having to increase the degree of the polynomial. The degree of the polynomial is only determined by the number of constraints, not the number of points. The coefficients used in this scheme are a0= Y[0] a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2] a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] + 7/24*Y[3] a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] - 1/2*Y[3] a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] + 5/24*Y[3] After that, I continued with the impulse response calculations and spectral response calculations, which are a bit disappointing. I'll spare you the equations (for now) and post the graphs. The new traces for the 6-point interpolator are shown in green. It's a little bit hard to see, but the things to look for are the rate at which the graph falls off and the locations of the peaks. The 6-point function has a flatter spectrum, which comes up closer to the Nyquist frequency, and falls off faster. These are the key characteristics of the spectrum we want. The green trace falls off according to 1/w^4, compared to 1/w^3 for tabread4c~ and 1/w^2 for tabread4~ You can see the impulse response in the first graph along with the spectrum. The log vs. dB scale is used same as before, and secondly, I've posted a linear graph, so you can see the difference between functions near the Nyquist frequency (x=pi). It gives me some ideas for another 6-point scheme, more like tabread4c~, which will fall off at a rate of 1/w^5 and have more notches in the frequency response. I'll work on it a bit, and see how it goes. Chuck ___ 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
Re: [PD] better tabread4~
ok, cool now, it would also be nice to have a good band limited table reader... cyrille Charles Henry a écrit : Hey, Cyrille, I kind of thought so... we are quickly running into the law of diminishing returns. I was up late, last night, working on the analysis some more. I think I can have another 6-point version with better characteristics tonight. Chuck On Tue, Jul 8, 2008 at 11:35 AM, cyrille henry [EMAIL PROTECTED] wrote: hello Chuck, i tested this. (and commited) i think tabread6c~ is a bit better than tabread4c~. but differences are more smaller thx Cyrille Charles Henry a écrit : On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry [EMAIL PROTECTED] wrote: ok, i'll try that. but i don't think adjusting the 2nd derivative is the best thing to do. for me, having a 6 point interpolation would be more important. I put together a 6-point interpolation formula and analyzed it. For this I used a 5th degree polynomial, and 6 constraints: (I want to change up the notation a bit, and not use the letters a, b, c, etc... when switching to 6-point. Y[-2],Y[-1],Y[0], Y[1], Y[2], Y[3] are the points from the table. a5 is the coefficient of x^5, a4 is the coeff. of x^4, ... a0 is a constant term. f(x) is the interpolation polynomial.) f(0)=Y[0] f(1)=Y[1] f'(0)= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] f'(1)= 1/12*Y[-1] - 2/3*Y[0] + 2/3*Y[2] - 1/12*Y[3] f''(0)= -1/12*Y[-2] + 4/3*Y[-1] - 5/2*Y[0] + 4/3*Y[1] - 1/12*Y[2] f''(1)= -1/12*Y[-1] + 4/3*Y[0] - 5/2*Y[1] + 4/3*Y[2] - 1/12*Y[3] This uses improved approximations for the derivative. One advantage of going to 6-point interpolation is to get better numerical derivatives. These approximations of the 1st and 2nd derivatives are accurate up to a higher frequency than before. We can also continue to increase the number of points arbitrarily, without necessarily having to increase the degree of the polynomial. The degree of the polynomial is only determined by the number of constraints, not the number of points. The coefficients used in this scheme are a0= Y[0] a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2] a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] + 7/24*Y[3] a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] - 1/2*Y[3] a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] + 5/24*Y[3] After that, I continued with the impulse response calculations and spectral response calculations, which are a bit disappointing. I'll spare you the equations (for now) and post the graphs. The new traces for the 6-point interpolator are shown in green. It's a little bit hard to see, but the things to look for are the rate at which the graph falls off and the locations of the peaks. The 6-point function has a flatter spectrum, which comes up closer to the Nyquist frequency, and falls off faster. These are the key characteristics of the spectrum we want. The green trace falls off according to 1/w^4, compared to 1/w^3 for tabread4c~ and 1/w^2 for tabread4~ You can see the impulse response in the first graph along with the spectrum. The log vs. dB scale is used same as before, and secondly, I've posted a linear graph, so you can see the difference between functions near the Nyquist frequency (x=pi). It gives me some ideas for another 6-point scheme, more like tabread4c~, which will fall off at a rate of 1/w^5 and have more notches in the frequency response. I'll work on it a bit, and see how it goes. Chuck ___ 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
Re: [PD] better tabread4~
Cyrille, Could you try this optimization for the tabread6c~ I threw together? It uses the same general notation as the tab4c~ suite: t_sample a3plusa4plusa5 = 0.25f*c+0.125f*e-0.333f*d-0.0417*a; t_sample fminusa = f-a; t_sample eminusb = e-b; t_sample dminusc = d-c; a5 = 0.208f*((fminusa-5.f*eminusb+10.f*dminusc)); a4 = 2.667f*eminusb-0.5f*fminusa-5.5f*dminusc-a3plusa4plusa5; a3 = a3plusa4plusa5-a4-a5; a2 = 0.667f*(d+b)-0.0417f*(a+e)-1.25f*c; a1 = 0.667f*(d-b)+0.0833f*(a-e); a0 = c; *out++ = a5 * frac + a4 ) * frac + a3) * frac + a2) * frac + a1) * frac + a0; I've tested it and I think it works... I count 20 *'s and 25 +'s = 45 ops vs. 31 *'s, and 27 +'s = 58 ops (if the fractions were written out as decimals). Thanks, Matt Date: Tue, 08 Jul 2008 18:35:51 +0200 From: cyrille henry [EMAIL PROTECTED] Subject: Re: [PD] better tabread4~ To: Charles Henry [EMAIL PROTECTED] Cc: pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed hello Chuck, i tested this. (and commited) i think tabread6c~ is a bit better than tabread4c~. but differences are more smaller thx Cyrille Charles Henry a ?crit : On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry [EMAIL PROTECTED] wrote: The coefficients used in this scheme are a0= Y[0] a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2] a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] + 7/24*Y[3] a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] - 1/2*Y[3] a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] + 5/24*Y[3] ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
The reason why the spectrum is necessary for the interpolator is not
exactly obvious or simple. It has to do with manipulations in the
time domain and what they do, in the frequency domain.
The basis of sampling starts with the following function, a dirac comb
g(t)= sum(k=-inf:inf, dirac-delta( (t-k/fs)) )
It is a series of pulses spaced 1/fs apart. It's Fourier transform
G(f)=integral( g(t)*e^(-i*2*pi*f*t) *dt)
G(f)= integral( sum(k=-inf:inf, dirac-delta( (t-k/fs)) )*e^(-i*2*pi*f*t)*dt)
Interchange the order of the integral and summation:
G(f)= sum(k=-inf:inf, integral(dirac-delta( (t-k/fs)) )*e^(-i*2*pi*f*t)*dt)
G(f)= sum(k=-inf:inf, e^(-i*2*pi*f*k/fs) )
G(f)= 1+ sum(k=1:inf, 2*cos(2*pi*f*k/fs) )
Here we have a periodic function, with period fs. We can re-write
this function as a Fourier series of a dirac-delta, in the frequency
domain.
integral(-fs/2:fs/2 , dirac-delta(f)*1 df) / integral(-fs/2:fs/2,
1*1 df) = 1/fs
so,
1=fs*integral(-fs/2:fs/2 , dirac-delta(f)*1 df) /
integral(-fs/2:fs/2, 1*1 df) * 1
likewise,
2*cos(2*pi*f*k/fs)=fs*integral(-fs/2*fs/2:
dirac-delta(f)*cos(2*pi*f*k/fs) df)/integral(-fs/2:fs/2:
cos(2*pi*f*k/fs)*cos(2*pi*f*k/fs) df) * cos(2*pi*f*k/fs)
This shows that
G(f)=fs*dirac-delta(f) on the interval [-fs/2,fs/2] and by periodic
extension, we get
G(f)=fs*sum(k=-inf:inf, dirac-delta(f-fs*k)
Suppose we have a band-limited function on f=[-fs/2:fs/2] in the time
domain, h(t).
we can get a sampled version of h(t) by multiplying by g(t)
s(t)=h(t)*g(t) = sum(k=-inf:inf, dirac-delta(t-k/fs)*h(t-k/fs))
And multiplication in the time domain is convolution in the frequency domain.
S(f)=conv(H(f), G(f))
S(f)=fs*sum(k=-inf:inf, H(f-k*fs))
The result is a periodic spectrum which repeats itself every fs Hz.
We still have all the information from h(t), except we no longer know
which band of frequencies that information comes from. In real valued
frequencies, it could be [0, fs/2], or [fs/2, fs] or [fs, 3*fs/2],
etc...
We can only reconstruct a continuous signal choosing one band of
frequencies. Our ideal interpolator is:
i(t)=1/fs*sinc(fs*t) where sinc(x)=sin(pi*x)/(pi*x)
I(f)={ 1/fs, -fs/2 f fs/2 and 0, elsewhere
Convolution in the time domain is multiplication in the frequency domain, so
h(t)=conv(i(t), s(t))
means that we multiply our spectrum from -fs/2:fs/2 by factor fs, and
everwhere else 0.
Because h(t) was bandlimited on -fs/2:fs/2 , we now have back our
original signal up to a difference of a finite number of points.
|h(t) - conv(i(t), s(t))|^2 = 0
(This is by the way, how we can resolve the problem of holes and
discontinuities, that vary between functions at only a finite number
of points--no jump discontinuities, those have infinite spectral
content and no asymptotes, either. We can consider two functions
f(x), g(x) to be congruent up to a finite number of points if
|f(x)-g(x)|^2=0.)
Okay, so back to the subject at hand. The situation in variable speed
playback is this:
We have a continuous function (a sound) in the time domain. We sample
it by multiplying by our dirac comb and convolve by an interpolation
function. The time-domain function and its spectrum has an impact on
the quality of the reconstructed function.
When we play our sound back at a variable speed, we are interpolating
(evaluating our convolution) at a series of specified points. prior
to playback at specified points, we have a continuous function with
spectrum defined on (-inf:inf). When we turn that continuous function
into a discrete series again, we stretch or compress this spectrum and
resample, producing aliasing and other artifacts of the spectrum.
If we playback at a speed A:
m(t)=conv(h(t)*g(t), i(t) )
n(t)=m(A*t)
Then,
N(f)=M(f/A)
When we playback at slow speeds, A1, we map the spectrum of our
reconstructed signal onto a smaller interval. e.g. [-fs/2,fs/2]
|- [-fs/2A, fs/2A]
This is not much of a problem, except that we now have some high
frequencies from above fs/2 now that appear in our desired range of
frequencies.
At speeds A1, we get aliasing. My big idea for anti-aliasing
tabread's is to modify the interpolation function continuously with
speed changes, so that even as the spectrum is compressed, the cutoff
frequency of the interpolation function stays exactly the same. The
simplest way to do this is to stretch the function in time.
1/A*i(t/A) has the same spectrum when played back at speed A as the
original function i(t)
But as I've said, this tends to be an expensive method to use, and I'm
still looking for alternatives.
If you want to compute the spectrum of interpolating polynomials, I
have come up with the following method (shown by example).
starting with the tabread4c~ polynomial:
g(x)=(-1/2*f[-1] + 3/2*f[0] - 3/2*f[1] + 1/2*d)*x^3
+ (f[-1] - 5/2*f[0] + 2*f[1] - 1/2*f[2])*x^2
+ (-1/2*f[-1] + 1/2*f[1]) + f[0]
Re-write terms as products with f[-1],f[0],f[1], and f[2]
g(x)=(-1/2*x^3 + x^2 - 1/2*x)*f[-1]
+
Re: [PD] better tabread4~
On Sat, Jul 5, 2008 at 1:42 PM, Matt Barber [EMAIL PROTECTED] wrote: Chuck, thanks for the explanation! One question about this -- would working back from the spectrum possibly mean that you wouldn't necessarily match any of the points (would this mean you could say the impulse response would not have a value of 1 at t=0)? This would be an interesting proposition, and maybe it might help temper the tendency of polynomial interpolation to deliver values 1 or -1 when the curve has a maximum or minimum between samples? I'm not sure if that would be the result, but I like the sentiment. =o) Yes, there are some situations where we could construct something that looks good on the face of things, but actually behaves poorly. However, there are a number of free variables involved. I will try to work through an example (so that I can figure it out). Anyway, thanks again. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Wed, 2 Jul 2008, Matt Barber wrote: Seriously though, I tend to agree with you -- this should explain my unease about searching for every polynomial possibility with a certain number of points. I want to help out as much as I can, but I just don't want to be the one to close a door on an option. While it's good to make software very open-ended in order to not close doors on options, it's best to close a door on an option that both is useless and takes special efforts to support. The distinction I make is that useless features that are simple combinations of existing features are fine, and it's normal to be able to patch silly things, but you really don't have to spend time on code that specifically is not going to be used. On the other hand, doesn't [tabread4~]'s Lagrange interpolator have a continuous 2nd derivative while the [tabread4c~] Hermite one does not? No. A Lagrange interpolator on N points is a polynomial of degree N-1, and so its Nth derivative is a flat zero function without holes, and so it is infinitely differentiable. However, those are pieced together as a disparate mosaïc in a way that is not even C1 (continuous 1st derivative), which is what prompted Cyrille to work on a replacement in the first place. Note that a discontinuous 1st derivative implies that all other orders of derivatives are discontinuous. I don't know what that would mean spectrally, if anything. It's the almost in the almost-arbitrary curves you mention that I don't know how to gauge I mean that if you have one Lagrange cubic going through x[-1] x[0] x[1] x[2] and then a new one going through x[0] x[1] x[2] x[3], how are those two polynomials specially related, other than the three intersections that they need to have? perhaps not in any way that matters, and that must be why [tabread4~] looks wrong. -- intuitively one could imagine that the more pieces of its surrounding environment are matched, the better the interpolation, I wouldn't even claim that as more pieces are matched, the interpolation wouldn't get worse. I'd claim the opposite. Matching too many points exactly is not just pointless, it's harmful. It gives importance to things that shouldn't be important. Matching points approximately is a completely different matter, as long as it's approximate enough that the process doesn't let itself be inappropriately influenced by any single point; but then, that is usually called linear regression (or polynomial regression, etc.) Of course, there's more than a strong possibility that this wheel has already been invented several times over and that the answers have been thoroughly established somewhere. Reinventing the wheel is fun. It's tempting more than a few, every day. The thing that keeps bothering me is that the smart people who designed Pd and Csound both arrived at the Lagrange interpolation, Maybe it's some kind of artistic statement that they made... perhaps it could be called Lagrangism. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On the other hand, doesn't [tabread4~]'s Lagrange interpolator have a continuous 2nd derivative while the [tabread4c~] Hermite one does not? No. A Lagrange interpolator on N points is a polynomial of degree N-1, and so its Nth derivative is a flat zero function without holes, and so it is infinitely differentiable. However, those are pieced together as a disparate mosaïc in a way that is not even C1 (continuous 1st derivative), which is what prompted Cyrille to work on a replacement in the first place. Note that a discontinuous 1st derivative implies that all other orders of derivatives are discontinuous. I'm with you on the general piecewise Lagrange not being C1, but I don't think it follows that all other orders are discontinuous -- can't they alternate? At any rate, check out the 2nd derivatives of the piecewise cubic Lagrange. I believe that at x=0 it will be y[-1] - 2*y[0] + y[1], while at x=1 it will be y[0] - 2*y[1] + y[2]. Therefore, since the terms match at the points on adjacent pieces, the 2nd derivative is continuous even though the first isn't. I'd imagine you could run into this kind of phenomenon especially with piecewise functions. Not sure what it means for the spectral response of the interpolator, though. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Thu, 3 Jul 2008, Matt Barber wrote: I'm with you on the general piecewise Lagrange not being C1, but I don't think it follows that all other orders are discontinuous -- can't they alternate? No. Any derivative inherits all discontinuities from the original function. It's a basic fact of life. Therefore, since the terms match at the points on adjacent pieces, the 2nd derivative is continuous even though the first isn't. Ok, well, there's usually a distinction made between a continuous function and one with holes. Even though you can use a limit operator to remove the holes, the result of that is just not the same function... unless you see that through limit-operator-coloured glasses. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Thu, 2008-07-03 at 04:01 -0400, Matt Barber wrote: On the other hand, doesn't [tabread4~]'s Lagrange interpolator have a continuous 2nd derivative while the [tabread4c~] Hermite one does not? No. A Lagrange interpolator on N points is a polynomial of degree N-1, and so its Nth derivative is a flat zero function without holes, and so it is infinitely differentiable. However, those are pieced together as a disparate mosaïc in a way that is not even C1 (continuous 1st derivative), which is what prompted Cyrille to work on a replacement in the first place. Note that a discontinuous 1st derivative implies that all other orders of derivatives are discontinuous. I'm with you on the general piecewise Lagrange not being C1, but I don't think it follows that all other orders are discontinuous -- can't they alternate? At any rate, check out the 2nd derivatives of the piecewise cubic Lagrange. I believe that at x=0 it will be y[-1] - 2*y[0] + y[1], while at x=1 it will be y[0] - 2*y[1] + y[2]. Therefore, since the terms match at the points on adjacent pieces, the 2nd derivative is continuous even though the first isn't. I'd imagine you could run into this kind of phenomenon especially with piecewise functions. Not sure what it means for the spectral response of the interpolator, though. yo, i am not too much a math guy, so correct me, if i am talking non-sense, but doesn't the a derivative describe the slope of of the original function at any point? if so, a function with one ore more discontinuities cannot have continuous derivative, because a jump at a certain point would result in a infinitely high value at this point of the derivative. one could argue, that in an analogue continuous world - if the jump is short enough - the peak would be too short to be noticed, but this certainly wouldn't be true in a digital, time discrete domain. after all, i still don't get, how it could be figured out in the digital domain, whether a curve is continuous or not. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Wed, Jul 2, 2008 at 1:51 PM, Matt Barber [EMAIL PROTECTED] wrote: Seriously though, I tend to agree with you -- this should explain my unease about searching for every polynomial possibility with a certain number of points. I want to help out as much as I can, but I just don't want to be the one to close a door on an option. I am only qualified to deliver some of the formulae and maybe do some of the programming, but I don't pack the mathematical guns to do the kinds of analytical work Chuck has been doing. I have a bit of insight on the math of the problem, because I've been working through some examples. And I still don't have an objective idea how to design the right interpolator for the job. Because there's so many possibilities, I think we should employ a few heuristics to guide the design. I think we are working with 3 main types of variations (please suggest more if possible): 1. degree of polynomial 2. number of points 3. setting constraints on derivatives and points My observations: 1. increasing the degree of polynomial allows to increase the rate of stop-band falloff (e.g 1/w^3 is best possible for a cubic, 1/w^5 is best possible for 5th degree) 2. increasing number of points allows improved derivatives, leading to better high-frequency response I think we could even turn this around, and specify aspects of the function, like rate of stop-band falloff and location of -3 dB cutoff frequency (which it turns out, is much lower than the Nyquist frequency). That might be the best case for what we can do. Chuck ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Matt Barber wrote: Any ideas?? have a look at how iemlib's filters are implemented. most of them are really just abstractions wrapping the correct parameters for a generic implementation class for the non-maths among us. fgamsdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
a good place to find different kind of audio interpolator : http://www.student.oulu.fi/~oniemita/dsp/deip.pdf cyrille Matt Barber a écrit : For polynomial interpolation using four points, if the above is right there are 5 ways to do it, and they are ordered first by degree of polynomial, then from fewest to greatest number of derivatives matched. I tend to agree with other posters who suggested that this kind of organization might best lend itself to one object with interpolation type specified by an argument or message. The argument could follow one of a couple standards: 1) a numeral or letter in order, as above, or 2) a descriptive argument. The descriptive argument could work something like this: [tabread4~ array] -- default to cubic Lagrange [tabread4~ array 3] -- explicit cubic Lagrange [tabread4~ array 3d] -- cubic, C1 [tabread4~ array 5dd] -- fifth-degree, C2 etc. [tabread4~ array 3dd] -- cubic, C2 -- doesn't exist, object doesn't create -- might post a list of available options. The d or dd could be replaced with whatever, as long as it was descriptive of the level of continuity. After further thought, there are some more problems with this kind of naming scheme. While the above would be exhaustive for the four-point interpolations, it would not be for a 6-point one. With 6-point interpolations you'd have the opportunity to match more than two first and second derivatives, so there are two ways, for example, to make a 9th-degree C2 curve -- one that fixes all six points, two first derivatives and two second derivatives, and one that fixes four points, four first derivatives, and two second derivatives. An alternate notation would be something like: [tabread4~ arrayname 4] -- fix all four points (default). [tabread4~ arrayname 2 2] -- fix points at x=0 and 1, and first derivatives at x=0 and 1 [tabread4~ arrayname 4 2 2] fix points at -1 0 1 and 2, f' at 0 and 1, and f'' at 0 and 1 [tabread6~ arrayname 6 4 2 2] fix all 6 points, all 4 first derivatives, and two second and third derivatives (13th-degree polynomial). Obviously this starts to get ridiculous. In fact if we wanted an exhaustive set of 6-point interpolations, I count 13 of them, assuming you don't ever want to constrain more first derivatives than points, or more second derivatives than first, etc., and assuming you only constrain up to the 2nd derivative. If you want to start constraining 3rd and 4th derivatives (possible with 6 points but not with 4), then it goes up to 25 different interpolations, and up to a 17th-degree polynomial (fixing 6 points, 4 each of the 1st and 2nd derivatives, and 2 each of the 3rd and 4th... yikes!). That would allow for the following: 1 C0 option, 5 C1 options, 7 C2 options, 6 C3 options, and 6 C4 options. It also starts to put the onus on the user to figure out what arguments to use, and requires that they know a little about the math behind it, which probably shouldn't be necessary. Maybe several classes could be made for the library -- for 4-point you could retain [tabread4~] as the C0 option, then have a [tabread4c1~] option for the continuous first derivative with an argument for the two different ways of doing it (there's a cubic one and a 5th-degree one). Then [tabread4c2~] for the 2 C2 options. This might help keep the classes from being too bloated with options, and would keep things organized by differing levels of continuity, but it means that more classes would have to be maintained... Not knowing enough of the math to test out the responses, I just don't know which direction to pursue, or whether an exhaustive set of options would make this more of an engineering curiosity than a library for high-quality audio. My intuition is that there are diminishing returns once you start getting higher than 5th- or 7th-degree polynomials, but I also generally hate arbitrary constraints. Any ideas?? Thanks, Matt ___ 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
Re: [PD] better tabread4~
On Fri, 27 Jun 2008, Charles Henry wrote: I get what you're saying now. I had to read it a couple times through to see :) You're referring to piecewise cubic polynomials, right? Yes, I'm always assuming that piecewise-cubics is all that we'll need. We would wind up with an overdetermined system of equations if we didn't float the 1st *and* 2nd derivatives, which would come out as a linear algebra problem of the size of the table. Yes, which is why we don't want to do that. but I think it gets even worse. There could be a non-zero null space to the problem. There are infinite solutions to interpolate a table full of zeros, with these conditions. What a mess :) In that case (which is when the algebra problem has the size of the table), there are two missing conditions, and then when you set them to x''[0]=0 and x''[last]=0, it is called «natural cubic spline». By expanding it out to more points, we could use a more accurate calculation of the derivative. Yes, but we don't want to get into that for this particular application, because the point is to be fast, and 4-point is the first N-point that makes sense (enough interpolation). Well, there is also 3-point, as used in Tk's Bézier splines (-smooth 1), but... hmm... what is possible with 3-point ? There's always a frequency dependent effect on the accuracy of 1st derivative approximations. And on the accuracy of all Nth derivative approximations. So there might be some value in expanding the number of points to include better approximations. Perhaps, but there is still a need for something fairly expedient to be used as the main interpolation method in pd. Yeah, a cubic polynomial makes the most sense for small changes. I haven't ever heard of people interpolating 4 points with a 5th degree polynomial but I think I could make it work It could work, but I don't know how much it's worth it. Higher derivatives of anything quite discrete will be rather jumpy. The Nth derivative of a white noise sample doubles its RMS at every derivation, for example, but when looking just at the near-Nyquist hiss, it's much worse than that. The more you use derivatives, the trickier it gets. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Sat, 28 Jun 2008, cyrille henry wrote: i personally consider that the interpolation should not add harmonics, and should remove non audible harmonics. i.e : a noise with freq from 20Hz to 20kHz shift 2 octave lower should result in a noise with freq from 20Hz to 5KHz. but it's ok for me if the result is from 5Hz to 5KHz. shifting it 2 octave higher should result in a 80Hz-20KHz frequency on the signal. (freq from 20KHz to 80Kz should be removed to kill alliasing effect. It's not the job of an interpolator to do anything about actual acoustics. To be Pd-like, your interpolator must not make any assumptions about the signal, which could be any kind of signal, sound or not, and which could be at a different apparent sample rate than what it will be played at. Using acoustic assumptions reduces the practical pluggability of objects in any way that the user sees fits, as less combinations are usable. This is why Pd doesn't use any acoustic assumptions. The Pd way to do what you want is to put a [hip~] after the interpolator. a table filled with alternate -1 and 1 can be seen as a 22KHz sinus (@ 44100 Hz sampling rate). shifting it higher should result in a null signal with an anti aliased interpolation. This is not an acoustic consideration, so this is fine. The choice of the Nyquist frequency of 22.05 kHz is an acoustic consideration, but it's not a choice that the interpolator itself makes, it's a choice that the interpolator just has to deal with, so it is fine. shifting it lower should result in a pure sinus wave. this is my opinion. i test this, and tabread4c~ is very close to the sinus wave, while tabread4~ is closer to a triangle wave. I will love tabread4c~... _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Sat, 28 Jun 2008, Matt Barber wrote: a1 = 0.5f * (c - a); a3 = 0.5f * (d - a) + 1.5f * (b - c); a2 = a - b + a1 - a3; *out++ = ((a3 * frac + a2) * frac + a1) * frac + b; 10 +'s 6 *'s If you compute twice the value of a1,a2,a3 and later multiply by 0.5, you end up with a multiplication of (a-b) by 2 that you can optimise by turning it into a single addition. In that case, 11 +'s 5 *'s, or 12 +'s 4 *'s if you also do the same with the multiplication by 3.0. It matters only if the CPU computes addition faster (not sure if that's still the case), or if redefining Pd samples to some weird type (floats with way too many bits, and such). I wonder what's the lowest possible number of operations. Some possible formulas wouldn't even have ((a3 * frac + a2) * frac + a1) * frac, but I wonder whether they can be any shorter. In any case, you need at least three multiplications ;) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Tue, 1 Jul 2008, Matt Barber wrote: Any ideas?? Just drop the idea of matching more than two sample points. It's what makes [tabread4~] miss the opportunity to be C1, but it's also in exchange for pretty much nothing. Well, maybe it's not nothing, but I still have no clue about what's the point of matching x[t-1] and x[t+2] for a curve that will only be used from x[t+0] to x[t+1]. When you get to x[t+2], one almost-arbitrarily different cubic has just passed, and you're entering another almost-arbitrarily different cubic, so the cubic used between x[t+0] and x[t+1] seems irrelevant at x[t+2]. Perhaps you have a totally different way of explaining it that would show that two adjacent cubic's continuations into each other are closely related and have special meaning, but if you do, please speak up cause I don't see any of it. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Wed, Jul 2, 2008 at 1:26 PM, Mathieu Bouchard [EMAIL PROTECTED] wrote: On Tue, 1 Jul 2008, Matt Barber wrote: Any ideas?? Just drop the idea of matching more than two sample points. It's what makes [tabread4~] miss the opportunity to be C1, but it's also in exchange for pretty much nothing. Well, maybe it's not nothing, but I still have no clue about what's the point of matching x[t-1] and x[t+2] for a curve that will only be used from x[t+0] to x[t+1]. When you get to x[t+2], one almost-arbitrarily different cubic has just passed, and you're entering another almost-arbitrarily different cubic, so the cubic used between x[t+0] and x[t+1] seems irrelevant at x[t+2]. Perhaps you have a totally different way of explaining it that would show that two adjacent cubic's continuations into each other are closely related and have special meaning, but if you do, please speak up cause I don't see any of it. Nope, I don't have any explanation; I'm just a kid! =o) Seriously though, I tend to agree with you -- this should explain my unease about searching for every polynomial possibility with a certain number of points. I want to help out as much as I can, but I just don't want to be the one to close a door on an option. I am only qualified to deliver some of the formulae and maybe do some of the programming, but I don't pack the mathematical guns to do the kinds of analytical work Chuck has been doing. On the other hand, doesn't [tabread4~]'s Lagrange interpolator have a continuous 2nd derivative while the [tabread4c~] Hermite one does not? I don't know what that would mean spectrally, if anything. It's the almost in the almost-arbitrary curves you mention that I don't know how to gauge -- intuitively one could imagine that the more pieces of its surrounding environment are matched, the better the interpolation, but I certainly wouldn't put money on that argument. The other side of the coin is, is it optimal that any points at all should be matched? I could imagine the existence of interpolations which deliver all kinds of spectral benefits but which aren't constrained to pass through any particular sample value... Also fairly intuitively one could imagine that some of this is signal-dependent, which would seem to stress the need for careful analysis and benchmarking. Curiosity would seem to demand testing a few options to feel out a direction before getting rid of any, testing some absurd options to confirm absurdity. Of course, there's more than a strong possibility that this wheel has already been invented several times over and that the answers have been thoroughly established somewhere. The thing that keeps bothering me is that the smart people who designed Pd and Csound both arrived at the Lagrange interpolation, and those who designed SC3 arrived at the Hermite, and I am certainly not qualified to second-guess any of them. I can do the algebra, though. =oD Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Mathieu Bouchard wrote: On Mon, 30 Jun 2008, IOhannes m zmoelnig wrote: i know for sure that starting Pd with -lib x -path y does something different than starting it with -path y -lib x. Does it? then why does -lib store its data in sys_externlist and that pd's main function looks up the libs only after the pdsettings, pdrc and commandline arguments are all loaded? darn you are right with the startup flags. i remember pretty well that this used to be different. apart from that, i can now (after a tiny test) confirm that at least [declare -lib x -path y] behaves differently than [declare -path y -lib x] [declare -lib x -path y]: tried /tmp/x.l_i386 and failed tried /usr/local/lib/pd/extra/x.l_i386 and failed tried /tmp/x.pd_linux and failed tried /usr/local/lib/pd/extra/x.pd_linux and failed tried /tmp/x/x.l_i386 and failed tried /usr/local/lib/pd/extra/x/x.l_i386 and failed tried /tmp/x/x.pd_linux and failed tried /usr/local/lib/pd/extra/x/x.pd_linux and failed [declare -path y -lib x] tried /tmp/y/x.l_i386 and failed tried /tmp/x.l_i386 and failed tried /usr/local/lib/pd/extra/x.l_i386 and failed tried /tmp/y/x.pd_linux and failed tried /tmp/x.pd_linux and failed tried /usr/local/lib/pd/extra/x.pd_linux and failed tried /tmp/y/x/x.l_i386 and failed tried /tmp/x/x.l_i386 and failed tried /usr/local/lib/pd/extra/x/x.l_i386 and failed tried /tmp/y/x/x.pd_linux and failed tried /tmp/x/x.pd_linux and failed tried /usr/local/lib/pd/extra/x/x.pd_linux and failed this is the behaviour i would have been expecting from the startup flags as well. mfg,asdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry [EMAIL PROTECTED] wrote: ok, i'll try that. but i don't think adjusting the 2nd derivative is the best thing to do. for me, having a 6 point interpolation would be more important. I put together a 6-point interpolation formula and analyzed it. For this I used a 5th degree polynomial, and 6 constraints: (I want to change up the notation a bit, and not use the letters a, b, c, etc... when switching to 6-point. Y[-2],Y[-1],Y[0], Y[1], Y[2], Y[3] are the points from the table. a5 is the coefficient of x^5, a4 is the coeff. of x^4, ... a0 is a constant term. f(x) is the interpolation polynomial.) f(0)=Y[0] f(1)=Y[1] f'(0)= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] f'(1)= 1/12*Y[-1] - 2/3*Y[0] + 2/3*Y[2] - 1/12*Y[3] f''(0)= -1/12*Y[-2] + 4/3*Y[-1] - 5/2*Y[0] + 4/3*Y[1] - 1/12*Y[2] f''(1)= -1/12*Y[-1] + 4/3*Y[0] - 5/2*Y[1] + 4/3*Y[2] - 1/12*Y[3] This uses improved approximations for the derivative. One advantage of going to 6-point interpolation is to get better numerical derivatives. These approximations of the 1st and 2nd derivatives are accurate up to a higher frequency than before. We can also continue to increase the number of points arbitrarily, without necessarily having to increase the degree of the polynomial. The degree of the polynomial is only determined by the number of constraints, not the number of points. The coefficients used in this scheme are a0= Y[0] a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2] a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] + 7/24*Y[3] a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] - 1/2*Y[3] a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] + 5/24*Y[3] After that, I continued with the impulse response calculations and spectral response calculations, which are a bit disappointing. I'll spare you the equations (for now) and post the graphs. The new traces for the 6-point interpolator are shown in green. It's a little bit hard to see, but the things to look for are the rate at which the graph falls off and the locations of the peaks. The 6-point function has a flatter spectrum, which comes up closer to the Nyquist frequency, and falls off faster. These are the key characteristics of the spectrum we want. The green trace falls off according to 1/w^4, compared to 1/w^3 for tabread4c~ and 1/w^2 for tabread4~ You can see the impulse response in the first graph along with the spectrum. The log vs. dB scale is used same as before, and secondly, I've posted a linear graph, so you can see the difference between functions near the Nyquist frequency (x=pi). It gives me some ideas for another 6-point scheme, more like tabread4c~, which will fall off at a rate of 1/w^5 and have more notches in the frequency response. I'll work on it a bit, and see how it goes. Chuck attachment: tabread6.pngattachment: tabread6lin.png___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
For polynomial interpolation using four points, if the above is right there are 5 ways to do it, and they are ordered first by degree of polynomial, then from fewest to greatest number of derivatives matched. I tend to agree with other posters who suggested that this kind of organization might best lend itself to one object with interpolation type specified by an argument or message. The argument could follow one of a couple standards: 1) a numeral or letter in order, as above, or 2) a descriptive argument. The descriptive argument could work something like this: [tabread4~ array] -- default to cubic Lagrange [tabread4~ array 3] -- explicit cubic Lagrange [tabread4~ array 3d] -- cubic, C1 [tabread4~ array 5dd] -- fifth-degree, C2 etc. [tabread4~ array 3dd] -- cubic, C2 -- doesn't exist, object doesn't create -- might post a list of available options. The d or dd could be replaced with whatever, as long as it was descriptive of the level of continuity. After further thought, there are some more problems with this kind of naming scheme. While the above would be exhaustive for the four-point interpolations, it would not be for a 6-point one. With 6-point interpolations you'd have the opportunity to match more than two first and second derivatives, so there are two ways, for example, to make a 9th-degree C2 curve -- one that fixes all six points, two first derivatives and two second derivatives, and one that fixes four points, four first derivatives, and two second derivatives. An alternate notation would be something like: [tabread4~ arrayname 4] -- fix all four points (default). [tabread4~ arrayname 2 2] -- fix points at x=0 and 1, and first derivatives at x=0 and 1 [tabread4~ arrayname 4 2 2] fix points at -1 0 1 and 2, f' at 0 and 1, and f'' at 0 and 1 [tabread6~ arrayname 6 4 2 2] fix all 6 points, all 4 first derivatives, and two second and third derivatives (13th-degree polynomial). Obviously this starts to get ridiculous. In fact if we wanted an exhaustive set of 6-point interpolations, I count 13 of them, assuming you don't ever want to constrain more first derivatives than points, or more second derivatives than first, etc., and assuming you only constrain up to the 2nd derivative. If you want to start constraining 3rd and 4th derivatives (possible with 6 points but not with 4), then it goes up to 25 different interpolations, and up to a 17th-degree polynomial (fixing 6 points, 4 each of the 1st and 2nd derivatives, and 2 each of the 3rd and 4th... yikes!). That would allow for the following: 1 C0 option, 5 C1 options, 7 C2 options, 6 C3 options, and 6 C4 options. It also starts to put the onus on the user to figure out what arguments to use, and requires that they know a little about the math behind it, which probably shouldn't be necessary. Maybe several classes could be made for the library -- for 4-point you could retain [tabread4~] as the C0 option, then have a [tabread4c1~] option for the continuous first derivative with an argument for the two different ways of doing it (there's a cubic one and a 5th-degree one). Then [tabread4c2~] for the 2 C2 options. This might help keep the classes from being too bloated with options, and would keep things organized by differing levels of continuity, but it means that more classes would have to be maintained... Not knowing enough of the math to test out the responses, I just don't know which direction to pursue, or whether an exhaustive set of options would make this more of an engineering curiosity than a library for high-quality audio. My intuition is that there are diminishing returns once you start getting higher than 5th- or 7th-degree polynomials, but I also generally hate arbitrary constraints. Any ideas?? Thanks, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Mathieu Bouchard wrote: Contrary to myself in this case, Johannes is hardly joking. but he is winking, which might qualify as well. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
And now, for the sake of absurdity, here is the 7th-degree polynomial for four points which fixes x[-1], x[0], x[1], x[2], x'[0], x'[1], x''[0], and x''[1]. easy-to-read: /*a7 = 1.25f*(b-c)+(5.f/12.f)*(d-a);*/ a7 = 1.25f*(b-c)+0.417f*(d-a); a6 = 3.5f*a7; a5 = 2.1f*a7; a4 = a6; a3 = 3.1f*a7; a2 = 0.5f*(c+a)-b; a1 = 0.5f*(c-a); a0 = b; *out++ = ((a7*frac-a6)*frac+a5)*frac+a4)*frac-a3)*frac+a2)*frac+a1)*frac+a0; or somewhat optimized: a7 = 1.25f*(b-c)+0.417f*(d-a); a4 = 3.5f*a7; a2 = 0.5f*(c+a)-b; a1 = 0.5f*(c-a); *out++ = ((a7*frac-a4) * frac+2.1f*a7) * frac+a4) * frac-3.1*a7) * frac+a2) * frac+a1) * frac+b; 13 +'s and 14 *'s Please test my algebra if you like, but I think it's right. It starts to get a little wobbly when there are more than two points in the same direction, which is to be expected (you can try with the 4-point table generated by the cosinesum method to an array, which makes 4 points and 3 guard points for a total of 7, to see the wobble). I worry that the oscillation will start to go nuts with the higher orders of polynomial -- I'd wonder if a six-point interpolation would gain much over a four-point, but we'd have to test... it might be worth investigating something other than the various kinds of polynomial interpolation, though. If we find that some of these vastly outperform others for various tasks, it would be good to try to optimize the formulas as much as possible -- the formula in the current [tabread4~] in Pd is rather hard to read, but it's pretty efficient... we might be able to do something similar with these others. Thanks, Matt PS -- Charles, you probably needn't spend your time analyzing this one, as it would most likely be a curiosity rather than anything usable. On Sat, Jun 28, 2008 at 12:46 PM, Matt Barber [EMAIL PROTECTED] wrote: On Sat, Jun 28, 2008 at 7:43 AM, cyrille henry [EMAIL PROTECTED] wrote: Matt Barber a écrit : ... The following bit of code might work to that end as a test, borrowing Cyrille's general notation: cminusb = c-b; aminusd = a-d; a0 = aminusd + 3.0 * cminusb; a1 = -2.5f * aminusd - 7.5f * cminusb; a2 = 1.5f * aminusd + 4.5f * cminusb; a3 = 0.5f * (c + a) - b; a4 = 0.5f * (c - a); a5 = b; *out++ = a0*frac+a1)*frac+a2)*frac+a3)*frac+a4)*frac+a5; ok, i'll try that. but i don't think adjusting the 2nd derivative is the best thing to do. for me, having a 6 point interpolation would be more important. well, we will see... This would work, as well. Changing the coefficient order to match the previous code (sorry I bollixed that up before). a4 and a3 are simple ratios of a5, but keeping a2 as explicitly the fourth coefficient... dropping a0, aminusd, and cminusb: a5 = a - d + 3.0f * (c - b); a2 = 0.5f * (c + a) - b; a1 = 0.5f * (c - a); *out++ = a5*frac-2.5f*a5)*frac+1.5*a5)*frac+a2)*frac+a1)*frac+b; I count 11 adds and 10 multiplies, vs. 9 +'s and 7 *'s in the original Lagrange algorithm in Pd, and 10 +'s and 9 *'s in the third order Hermite example. I don't know if it's as simple as all that, though, but it would seem to be on at least a similar order of performance. BTW, the following for the C1 interpolation might be slightly more efficient (I left the original line commented out): a1 = 0.5f * (c - a); /* a2 = a - 2.5 * b + 2.f * c - 0.5f * d; */ a3 = 0.5f * (d - a) + 1.5f * (b - c); a2 = a - b + a1 - a3; *out++ = ((a3 * frac + a2) * frac + a1) * frac + b; . 10 +'s 6 *'s Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
An idea on naming: It should be possible to exhaust all the different schemes for interpolations involving a given number of points, and it should be possible to do so hierarchically. For four points, e.g., we have: 3rd degree polynomial, setting: A) x[-1], x[0], x[1], x[2] (Pd's Lagrange default - match point values). B) x[0], x[1], x'[0], x'[1] (third order Hermite example in SC3, current [tabosc4c~] - match inner point values and first derivatives) 5th degree polynomial, setting: C) x[-1], x[0], x[1], x[2], x'[0], x'[1] (match all points, first derivatives at inner points) D) x[0], x[1], x'[0], x'[1], x''[0], x''[1] (match inner points, first derivatives, second derivatives) 7th degree polynomial, setting: E) x[-1], x[0], x[1], x[2], x'[0], x'[1], x''[0], x''[1] (match all points, first and second derivatives at inner points) (missing any?) For polynomial interpolation using four points, if the above is right there are 5 ways to do it, and they are ordered first by degree of polynomial, then from fewest to greatest number of derivatives matched. I tend to agree with other posters who suggested that this kind of organization might best lend itself to one object with interpolation type specified by an argument or message. The argument could follow one of a couple standards: 1) a numeral or letter in order, as above, or 2) a descriptive argument. The descriptive argument could work something like this: [tabread4~ array] -- default to cubic Lagrange [tabread4~ array 3] -- explicit cubic Lagrange [tabread4~ array 3d] -- cubic, C1 [tabread4~ array 5dd] -- fifth-degree, C2 etc. [tabread4~ array 3dd] -- cubic, C2 -- doesn't exist, object doesn't create -- might post a list of available options. The d or dd could be replaced with whatever, as long as it was descriptive of the level of continuity. Cons first: 1) No matter what, the argument will be somewhat opaque, and some people (myself included) would probably have a hard time easily remembering what the arguments mean, which ones are available, and why. 2) List of possible arguments grows a great deal with the number of points in the interpolation. Also, the first and second derivatives have more numerical approximations with a larger set of points -- one would assume you'd go with the most accurate. Do the third, fourth, etc. derivatives ever get used to derive the polynomial? 3) Having them organized hierarchically by type might imply to some users that they are also ordered by quality (Lagrange worst, 7th-degree best), while this might not be the case at all. 4) We haven't proven that an exhaustive set is even desirable. Also, it's unclear which should be the default from a theoretical standpoint (though obviously the current standard should be default for historical purposes). 5) This would force the user to apply an array name if they wanted to set the interpolation. Same with the class method set. Also, having a numeral or a symbol to call the interpolation (3 vs. 3d) might make things tough to implement -- this could be changed. Some Pros: 1) This scheme could be imported directly into Pd (vanilla) with very little cost, since the default would just be the normal Pd interpolation; this, provided Miller approved such an expansion of something relatively low-level. It would necessitate no change in the implementation of array methods (cosinesum, etc.) since all of these would be 4-point. It would also move the choice of best from programmers to users; the benchmarks could be referenced in the documentation and suggestions could be made for different applications (giving both a what's it do and a what's it for kind of documentation), and give users of vanilla access to a wider selection of interpolation. 2) The external library of other interpolations could be organized around how many points used ([tabread2~] for linear, [tabread6~] for 6-point). Naming becomes easier and more explicit. Objects which mimic array methods could be made for any of the various interpolations -- [arraycosinesum array size interpolpoints list of harmonic amps] 3) The formulas themselves could be tucked into functions for easy use in other external libraries, but you might not want to introduce a function call for every interpolation into the main tabread, tabosc, and vd object classes. I'd welcome any comments. Thanks, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: Cons first: 1) No matter what, the argument will be somewhat opaque, and some people (myself included) would probably have a hard time easily remembering what the arguments mean, which ones are available, and why. Actually this could be an argument for using only a single object that accepts arguments: All of the args could be documented in a single help file, which is fast to open, and the only thing to remember would be one object name. 4) We haven't proven that an exhaustive set is even desirable. Good question. ;) 5) This would force the user to apply an array name if they wanted to set the interpolation. Same with the class method set. Also, having a numeral or a symbol to call the interpolation (3 vs. 3d) might make things tough to implement -- this could be changed. An alternative might be keyword arguments as used in [declare -lib x -path y] which is the same as [declare -path y -lib x] regardless of order. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Frank Barknecht wrote: An alternative might be keyword arguments as used in [declare -lib x -path y] which is the same as [declare -path y -lib x] regardless of order. hmm, probably a bad example. even though i am not so intimate with [declare], i know for sure that starting Pd with -lib x -path y does something different than starting it with -path y -lib x. i think this is intentional and definitely has it's uses (another reason why i think that the current preferences system is less than optimal) fgamdsr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: Frank Barknecht wrote: An alternative might be keyword arguments as used in [declare -lib x -path y] which is the same as [declare -path y -lib x] regardless of order. hmm, probably a bad example. even though i am not so intimate with [declare], i know for sure that starting Pd with -lib x -path y does something different than starting it with -path y -lib x. True. I didn't think of this. Though for a new tabread4~ the order wouldn't have to matter. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Mon, 30 Jun 2008, IOhannes m zmoelnig wrote: i know for sure that starting Pd with -lib x -path y does something different than starting it with -path y -lib x. Does it? then why does -lib store its data in sys_externlist and that pd's main function looks up the libs only after the pdsettings, pdrc and commandline arguments are all loaded? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Sat, 28 Jun 2008, hard off wrote: legends of the pd-list gag department: Mattieu: We need a state-saving object class named [jesus]. Iohannes: this might be the reason why i prefer [lop~] over [cool_filter~] and Pd over reactor. Contrary to myself in this case, Johannes is hardly joking. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
okay, so here's what I came up with... For the original tabread4~, the impulse response and its Fourier Transform: g(t)=I[-2,2](t)*(-1/6*|t|^3 - 2*t^2 - 11/6*|t| + 1) + I[-1,1](t)*(2/3*|t|^3 - 2*t^2 + 4/3*|t|) G(w)= (1/w^2)*(1/3*cos(2w) - 4/3*cos(w) + 1) + (1/w^4)*(2*cos(2w) - 8*cos(w) + 6) and for the most recent version of tabread4c~ h(t)= I[-2,2](t)*(-1/2*|t|^3 + 5/2*t^2 - 4*|t| + 2) + I[-1,1](t)*( 2*|t|^3 - 5*t^2 + 4*|t| - 1) H(w)= (1/w^3)*(2*sin(2*w) - 4*sin(w)) + (1/w^4)*(18 - 24*cos(w) + 6*cos(2*w)) The graphs shown indicate that tabread4c~ has a faster frequency rolloff (at a maximum rate corresponding to the 1/w^3 term). The frequency response for tabread4~ is shown in red, and tabread4c~ is shown in blue. The y-axis is dB attenuation, and the x axis is a logarithmic scale for frequency. 0 corresponds to the location of the Nyquist frequency, and each increment corresponds to an octave. The plot was generated with Octave, and the code is below: f=pi/16:pi/1024:32*pi; g=1./f.^2.*(1/3*cos(2*f)-4/3*cos(f) + 1) + 1./f.^4.*(2*cos(2*f) - 8*cos(f)+6); h=1./f.^3.*(2*sin(2*f)-4*sin(f)) + 1./f.^4.*(18-24*cos(f)+6*cos(2*f)); plot(log(f/pi)/log(2), 20*log(g+0.1)/log(10)) hold on plot(log(f/pi)/log(2), 20*log(h+0.1)/log(10),'b') attachment: spectrum.png___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Date: Fri, 27 Jun 2008 00:39:18 -0500 From: Charles Henry [EMAIL PROTECTED] Subject: Re: [PD] better tabread4~ To: Mathieu Bouchard [EMAIL PROTECTED], pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 26, 2008 at 11:18 AM, Mathieu Bouchard [EMAIL PROTECTED] wrote: I fucked up here. To get a C2 curve you may need to solve an equation system covering the whole table (!). Anyhow, a C1 system is fine enough for most uses, and it would be already much better than pd's. The thing is that you can only match the 2nd derivatives if you let the 1st derivatives just match but freely float. Then there will be one curve going through all points of the whole table supposing that the 2nd derivative is zero at the beginning and end of the table. Clearly this is a wholly different game because you need to compute a 2nd table to remember what the 1st derivatives are supposed to be and then you can't change anything in the 1st table without recomputing the 2nd table from scratch, or something. I get what you're saying now. I had to read it a couple times through to see :) You're referring to piecewise cubic polynomials, right? We would wind up with an overdetermined system of equations if we didn't float the 1st *and* 2nd derivatives, which would come out as a linear algebra problem of the size of the table. but I think it gets even worse. There could be a non-zero null space to the problem. There are infinite solutions to interpolate a table full of zeros, with these conditions. What a mess :) It's also bad because while a natural cubic spline is conceivable for a tabread (fixing the 2nd derivative to zero on both ends, reading in and keeping all the derived data in a buffer somewhere), you might need a different kind of spline (periodic?) for a tabosc~, and it shouldn't work at all for a vd~ since there is no codified beginning or end to the table (yes-no?). or we could set x[0],x[1] and x'[0]=(x[1]-x[-1])/2 and x'[1]=(x[2]-x[0])/2 again, 4 constraints, cubic polynomial, etc... Seems reasonable. What I want has to have constraints on x'[0] and x'[1]. Those would be a possibility. The problem is that it uses a gap of 2 samples instead of one, so it uses a blurry derivative, but the alternative is to have to pick between forward-difference and backwards-difference. The blurry derivative happens to be the average of the 1-sample forward-difference and backward-difference. Which is equivalent to the slope between the 2-sample gap. This would have another advantage over forward- or backward-differences such that going through the table in reverse would produce a symmetric result. (or actually, would it matter after all, since the four points are in the same order whether you're going forward or backward through the table... ?) and x''[0]=x[1]-2*x[0]+x[-1] and x''[1]=x[2]-2*x[1]+x[0] 6 constraints, 5th degree polynomial I think that the replacement for tabread4~ should be another cubic, so that it takes almost the same time to compute it. What I said about C2 was based on a mistaken reading of webpages trying to refresh myself on splines. I should've been more careful. Yeah, a cubic polynomial makes the most sense for small changes. I haven't ever heard of people interpolating 4 points with a 5th degree polynomial but I think I could make it work The following bit of code might work to that end as a test, borrowing Cyrille's general notation: cminusb = c-b; aminusd = a-d; a0 = aminusd + 3.0 * cminusb; a1 = -2.5f * aminusd - 7.5f * cminusb; a2 = 1.5f * aminusd + 4.5f * cminusb; a3 = 0.5f * (c + a) - b; a4 = 0.5f * (c - a); a5 = b; *out++ = a0*frac+a1)*frac+a2)*frac+a3)*frac+a4)*frac+a5; The variables would have to be declared further up, obviously. Also, the compiler should optimize the a5 definition out and just use b (right?), so the above might be clearer and more explicit from a formal standpoint. I'm very prone to algebraic mistakes (especially on friday nights), so if someone else is interested you can check my work and see if you arrive at the same result (x''[n] = x[n-1] -2*x[n] + x[n+1] , x'[n] = 0.5*(x[n+1] - x[n-1]) for both x[0] and x[1] ) -- the result may be able to be further optimized as well due to some redundancies in the coefficients. Following the naming scheme of the other tests, this might be [tabread4fi~] or some such (fi for fifth-order-polynomial). As this line of experimentation proceeds, it might make sense to develop a set of benchmarks both for quality and performance. One place to start might be to test the residual error between all of the new and old [tabosc~] objects running through a cosine table and an [osc~] with the same frequency and phase, trying out different respective table sizes, and then further test with various cosinesum combinations. Of course the ear test will probably determine things more, especially with sampled data
Re: [PD] better tabread4~
Matt Barber a écrit : ... The following bit of code might work to that end as a test, borrowing Cyrille's general notation: cminusb = c-b; aminusd = a-d; a0 = aminusd + 3.0 * cminusb; a1 = -2.5f * aminusd - 7.5f * cminusb; a2 = 1.5f * aminusd + 4.5f * cminusb; a3 = 0.5f * (c + a) - b; a4 = 0.5f * (c - a); a5 = b; *out++ = a0*frac+a1)*frac+a2)*frac+a3)*frac+a4)*frac+a5; ok, i'll try that. but i don't think adjusting the 2nd derivative is the best thing to do. for me, having a 6 point interpolation would be more important. well, we will see... The variables would have to be declared further up, obviously. Also, the compiler should optimize the a5 definition out and just use b (right?), so the above might be clearer and more explicit from a formal standpoint. I'm very prone to algebraic mistakes (especially on friday nights), so if someone else is interested you can check my work and see if you arrive at the same result (x''[n] = x[n-1] -2*x[n] + x[n+1] , x'[n] = 0.5*(x[n+1] - x[n-1]) for both x[0] and x[1] ) -- the result may be able to be further optimized as well due to some redundancies in the coefficients. Following the naming scheme of the other tests, this might be [tabread4fi~] or some such (fi for fifth-order-polynomial). As this line of experimentation proceeds, it might make sense to develop a set of benchmarks both for quality and performance. One place to start might be to test the residual error between all of the new and old [tabosc~] objects running through a cosine table and an [osc~] with the same frequency and phase, trying out different respective table sizes, and then further test with various cosinesum combinations. yes, a benchmarking tool would be good to make. but i would not use osc~ as a reference, as it's output come from a table interpolation. (if i did understand pd code, osc~ comes from a linear interpolation of a 512 points table). (btw, if the interpolation lib is extended to a better audio synthesis lib, then a better osc~ can be add there to) the more i digg in pd audio code, the more i think it's important to make this kind of lib. But it would need lot's more work that i can do. and i also don't know much on this subject... Of course the ear test will probably determine things more, especially with sampled data, but it's still a little unclear to me exactly what these interpolations are supposed to do when the waveform has transients and discontinuities among the samples -- e.g. what bandwidth should result from moving through a table that's filled with white noise, or what should happen when moving slowly through a table that's filled with alternating 1 -1, or what should a snare-drum or bongo hit sound like at a fifth the speed? These seem to me to be more a matter of taste and interpretation than the cosine tests. i personally consider that the interpolation should not add harmonics, and should remove non audible harmonics. i.e : a noise with freq from 20Hz to 20kHz shift 2 octave lower should result in a noise with freq from 20Hz to 5KHz. but it's ok for me if the result is from 5Hz to 5KHz. shifting it 2 octave higher should result in a 80Hz-20KHz frequency on the signal. (freq from 20KHz to 80Kz should be removed to kill alliasing effect. a table filled with alternate -1 and 1 can be seen as a 22KHz sinus (@ 44100 Hz sampling rate). shifting it higher should result in a null signal with an anti aliased interpolation. shifting it lower should result in a pure sinus wave. this is my opinion. i test this, and tabread4c~ is very close to the sinus wave, while tabread4~ is closer to a triangle wave. best cyrille Thanks, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
legends of the pd-list gag department: Mattieu: We need a state-saving object class named [jesus]. Iohannes: this might be the reason why i prefer [lop~] over [cool_filter~] and Pd over reactor. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Sat, Jun 28, 2008 at 7:43 AM, cyrille henry [EMAIL PROTECTED] wrote: Matt Barber a écrit : ... The following bit of code might work to that end as a test, borrowing Cyrille's general notation: cminusb = c-b; aminusd = a-d; a0 = aminusd + 3.0 * cminusb; a1 = -2.5f * aminusd - 7.5f * cminusb; a2 = 1.5f * aminusd + 4.5f * cminusb; a3 = 0.5f * (c + a) - b; a4 = 0.5f * (c - a); a5 = b; *out++ = a0*frac+a1)*frac+a2)*frac+a3)*frac+a4)*frac+a5; ok, i'll try that. but i don't think adjusting the 2nd derivative is the best thing to do. for me, having a 6 point interpolation would be more important. well, we will see... This would work, as well. Changing the coefficient order to match the previous code (sorry I bollixed that up before). a4 and a3 are simple ratios of a5, but keeping a2 as explicitly the fourth coefficient... dropping a0, aminusd, and cminusb: a5 = a - d + 3.0f * (c - b); a2 = 0.5f * (c + a) - b; a1 = 0.5f * (c - a); *out++ = a5*frac-2.5f*a5)*frac+1.5*a5)*frac+a2)*frac+a1)*frac+b; I count 11 adds and 10 multiplies, vs. 9 +'s and 7 *'s in the original Lagrange algorithm in Pd, and 10 +'s and 9 *'s in the third order Hermite example. I don't know if it's as simple as all that, though, but it would seem to be on at least a similar order of performance. BTW, the following for the C1 interpolation might be slightly more efficient (I left the original line commented out): a1 = 0.5f * (c - a); /* a2 = a - 2.5 * b + 2.f * c - 0.5f * d; */ a3 = 0.5f * (d - a) + 1.5f * (b - c); a2 = a - b + a1 - a3; *out++ = ((a3 * frac + a2) * frac + a1) * frac + b; . 10 +'s 6 *'s Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Sat, Jun 28, 2008 at 7:43 AM, cyrille henry [EMAIL PROTECTED] wrote: Matt Barber a écrit : As this line of experimentation proceeds, it might make sense to develop a set of benchmarks both for quality and performance. One place to start might be to test the residual error between all of the new and old [tabosc~] objects running through a cosine table and an [osc~] with the same frequency and phase, trying out different respective table sizes, and then further test with various cosinesum combinations. yes, a benchmarking tool would be good to make. but i would not use osc~ as a reference, as it's output come from a table interpolation. (if i did understand pd code, osc~ comes from a linear interpolation of a 512 points table). (btw, if the interpolation lib is extended to a better audio synthesis lib, then a better osc~ can be add there to) the more i digg in pd audio code, the more i think it's important to make this kind of lib. But it would need lot's more work that i can do. and i also don't know much on this subject... I did not know that about [osc~] -- I'm still going through the code, but [osc~] has often felt kind of rough around the edges. I suppose that the error in various interpolation schemes from the tabosc objects would begin to converge with larger tables, so it's possible something like that could be used for the benchmark instead. With appropriate frequencies there could probably be some interesting fft tests as well. I've always liked the sound of SC3's SinOsc ugen... it might be worth looking through that code to see how it differs from [osc~]'s. Thanks, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On 25/06/2008, at 22.33, cyrille henry wrote: so finally, what should be the name of this object? is it ok if i remove the other test i made and to use only this one? I think you a free to name your code what you want. And also to delete it. I however think people would find it interesting with a lib* of tabread's with different interpolation schemes. At least i think it would be cool with a collection where also the interpolation methods of the others are included (fx, the SC one). Thanks for publishing. (* where ever its one-file-multi-class, one-class-per-file or multi- method-per-class.) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Thu, 26 Jun 2008, Damian Stewart wrote: one of the pushes to me finally learning Pd was discovering that there was an object called [moses], and it did what it said it did. We need a state-saving object class named [jesus]. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Tue, 24 Jun 2008, Charles Henry wrote: On Tue, Jun 24, 2008 at 9:24 PM, Mathieu Bouchard [EMAIL PROTECTED] wrote: I don't think that more than one alternative will be necessary. For 4-point table lookups that go through all the original points, I don't know why anyone would aim lower than a C2 piecewise-polynomial. Unfortunately, it would be somewhat too late to just call it [tabread4~]. Or not. How low is too low? hmmm I fucked up here. To get a C2 curve you may need to solve an equation system covering the whole table (!). Anyhow, a C1 system is fine enough for most uses, and it would be already much better than pd's. The thing is that you can only match the 2nd derivatives if you let the 1st derivatives just match but freely float. Then there will be one curve going through all points of the whole table supposing that the 2nd derivative is zero at the beginning and end of the table. Clearly this is a wholly different game because you need to compute a 2nd table to remember what the 1st derivatives are supposed to be and then you can't change anything in the 1st table without recomputing the 2nd table from scratch, or something. When we have an interval between samples, we wish to fit a polynomial (because it's fast, I guess) that satisfies our constraints. We could specify the polynomial has the same values at x[-1],x[0], x[1], x[2] (tabread4~). No, you don't set those 4 constraints because else you will get exactly the same polynomial that tabread4~ already figures out, and we know that it is not C1. You need to drop x[-1] and x[2] as conditions. or we could set x[0],x[1] and x'[0]=(x[1]-x[-1])/2 and x'[1]=(x[2]-x[0])/2 again, 4 constraints, cubic polynomial, etc... Seems reasonable. What I want has to have constraints on x'[0] and x'[1]. Those would be a possibility. The problem is that it uses a gap of 2 samples instead of one, so it uses a blurry derivative, but the alternative is to have to pick between forward-difference and backwards-difference. The blurry derivative happens to be the average of the 1-sample forward-difference and backward-difference. and x''[0]=x[1]-2*x[0]+x[-1] and x''[1]=x[2]-2*x[1]+x[0] 6 constraints, 5th degree polynomial I think that the replacement for tabread4~ should be another cubic, so that it takes almost the same time to compute it. What I said about C2 was based on a mistaken reading of webpages trying to refresh myself on splines. I should've been more careful. and if you additionally wanted it to actually go through x[-1] and x[2], it would be 7th degree No, you shouldn't care about matching those extra points because anyway only the curve between x[0] and x[1] is used. The two outer points should be used only to figure out what derivatives to use. But not all possibilities are worth analyzing... I'm not even sure what kind of method to use to narrow the field. The blurry derivative above seems to be fine... I'd have to try it, but I should be working on other things now. I suppose that Cyrille already has everything figured out anyway. I just feel like talking about math sometimes... ;) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Thu, Jun 26, 2008 at 11:18 AM, Mathieu Bouchard [EMAIL PROTECTED] wrote: I fucked up here. To get a C2 curve you may need to solve an equation system covering the whole table (!). Anyhow, a C1 system is fine enough for most uses, and it would be already much better than pd's. The thing is that you can only match the 2nd derivatives if you let the 1st derivatives just match but freely float. Then there will be one curve going through all points of the whole table supposing that the 2nd derivative is zero at the beginning and end of the table. Clearly this is a wholly different game because you need to compute a 2nd table to remember what the 1st derivatives are supposed to be and then you can't change anything in the 1st table without recomputing the 2nd table from scratch, or something. I get what you're saying now. I had to read it a couple times through to see :) You're referring to piecewise cubic polynomials, right? We would wind up with an overdetermined system of equations if we didn't float the 1st *and* 2nd derivatives, which would come out as a linear algebra problem of the size of the table. but I think it gets even worse. There could be a non-zero null space to the problem. There are infinite solutions to interpolate a table full of zeros, with these conditions. What a mess :) or we could set x[0],x[1] and x'[0]=(x[1]-x[-1])/2 and x'[1]=(x[2]-x[0])/2 again, 4 constraints, cubic polynomial, etc... Seems reasonable. What I want has to have constraints on x'[0] and x'[1]. Those would be a possibility. The problem is that it uses a gap of 2 samples instead of one, so it uses a blurry derivative, but the alternative is to have to pick between forward-difference and backwards-difference. The blurry derivative happens to be the average of the 1-sample forward-difference and backward-difference. By expanding it out to more points, we could use a more accurate calculation of the derivative. There's always a frequency dependent effect on the accuracy of 1st derivative approximations. For example, backwards difference: x' ~= x[n] - x[n-1] X'[z] = X[z] ( 1 - z^-1) Which has spectrum, X'[w]=1-e^(-j*w) |X'[w]|^2=(1-cos(w))^2+sin(w)^2, phase (X'[w])=arctan( sin(w)/(1-cos(w)) ) our ideal system has X'[w]=j*w Central divided difference x' ~= (x[n+1] - x[n-1])/2 X'[z] = X[z] ( z - z^-1)/2 Which has spectrum, X'[w]=(e^(j*w)-e^(-j*w))/2 X'[w]=j*sin(w) It still has trouble with the high frequencies. So there might be some value in expanding the number of points to include better approximations. and x''[0]=x[1]-2*x[0]+x[-1] and x''[1]=x[2]-2*x[1]+x[0] 6 constraints, 5th degree polynomial I think that the replacement for tabread4~ should be another cubic, so that it takes almost the same time to compute it. What I said about C2 was based on a mistaken reading of webpages trying to refresh myself on splines. I should've been more careful. Yeah, a cubic polynomial makes the most sense for small changes. I haven't ever heard of people interpolating 4 points with a 5th degree polynomial but I think I could make it work The blurry derivative above seems to be fine... I'd have to try it, but I should be working on other things now. I suppose that Cyrille already has everything figured out anyway. I just feel like talking about math sometimes... ;) It's all good by me :) Chuck ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: bsoisoi wrote: I agree, being able to specify interpolation via an inlet message would be great (from my users perspective). hmm, i am not totally convinced (but actually don't care) Is anyone else besides me reminded of a color of bike shed discussion? as this leads to bloated objects which can just do everything and you specify what they should do via parameters. why do we have objects then? However in this case I think, it does make sense to keep it in a single object and set interpolation through messages: all suggested tabread4~ variants do a table read using 4 table points for interpolation, so all of them could be named tabread4~. They only differ in the actual formula in use. Variants of 4-point interpolation may also be useful in other objects like vd~ and tabosc4~. Here the same message interface could be used again, which is good for mnemonics. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
For what it's worth, here's supercollider's cubic interpolation
function, which differs from csound's and Pd's, which I believe are
equivalent:
static float cubicinterp(float x, float y0, float y1, float y2, float y3)
{
// 4-point, 3rd-order Hermite (x-form)
float c0 = y1;
float c1 = 0.5f * (y2 - y0);
float c2 = y0 - 2.5f * y1 + 2.f * y2 - 0.5f * y3;
float c3 = 0.5f * (y3 - y0) + 1.5f * (y1 - y2);
return ((c3 * x + c2) * x + c1) * x + c0;
}
Matt
Date: Tue, 24 Jun 2008 23:50:06 -0500
From: Charles Henry [EMAIL PROTECTED]
Subject: Re: [PD] better tabread4~
To: Mathieu Bouchard [EMAIL PROTECTED], pd-list@iem.at
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Jun 24, 2008 at 9:24 PM, Mathieu Bouchard [EMAIL PROTECTED] wrote:
I don't think that more than one alternative will be necessary. For 4-point
table lookups that go through all the original points, I don't know why
anyone would aim lower than a C2 piecewise-polynomial. Unfortunately, it
would be somewhat too late to just call it [tabread4~]. Or not.
How low is too low? hmmm
tabread4~ is deficient as Cyrille pointed out, because the resulting
function is not continuously differentiable (thanks for the
correction). So, what characteristics would be best for a fast
interpolating function?
When we have an interval between samples, we wish to fit a polynomial
(because it's fast, I guess) that satisfies our constraints.
We could specify the polynomial has the same values at x[-1],x[0],
x[1], x[2] (tabread4~). Four constraints, determines a cubic
polynomial, works out as a linear algebra problem.
or we could set x[0],x[1] and x'[0]=(x[1]-x[-1])/2 and x'[1]=(x[2]-x[0])/2
again, 4 constraints, cubic polynomial, etc...
or another 4 point scheme, with continuous 2nd derivative
setting x[0], x[1], x'[0]=(x[1]-x[-1])/2 and x'[1]=(x[2]-x[0])/2
and x''[0]=x[1]-2*x[0]+x[-1] and x''[1]=x[2]-2*x[1]+x[0]
6 constraints, 5th degree polynomial
and if you additionally wanted it to actually go through x[-1] and
x[2], it would be 7th degree
So, even for 4-point interpolation, there are some options that could
all be called tabread4~.
But not all possibilities are worth analyzing... I'm not even sure
what kind of method to use to narrow the field.
Chuck
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Wed, Jun 25, 2008 at 10:32 AM, Matt Barber [EMAIL PROTECTED] wrote:
For what it's worth, here's supercollider's cubic interpolation
function, which differs from csound's and Pd's, which I believe are
equivalent:
static float cubicinterp(float x, float y0, float y1, float y2, float y3)
{
// 4-point, 3rd-order Hermite (x-form)
float c0 = y1;
float c1 = 0.5f * (y2 - y0);
float c2 = y0 - 2.5f * y1 + 2.f * y2 - 0.5f * y3;
float c3 = 0.5f * (y3 - y0) + 1.5f * (y1 - y2);
return ((c3 * x + c2) * x + c1) * x + c0;
}
Matt
a0=(3b-a-3c+d)/2(same as c3)
a1=a-5b/2+2c-d/2 (same as c2)
a2=(c-a)/2 (same as c1)
(b is c0)
f(x)=(((a0*x+a1)*x+a2)*x-+b
Actually that's just the same set of coefficients that I named in a
previous post... just in a different form. So, that's just the sort
of thing we could add to pd-extended
It's good to know what other people are doing in their software too
Chuck
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
PS -- also for what it's worth, a formula which seems equivalent to
the one used in [tabread4c~] is described here:
http://local.wasp.uwa.edu.au/~pbourke/other/interpolation/
it gives the following piece of code:
double CubicInterpolate(
double y0,double y1,
double y2,double y3,
double mu)
{
double a0,a1,a2,a3,mu2;
mu2 = mu*mu;
a0 = y3 - y2 - y0 + y1;
a1 = y0 - y1 - a0;
a2 = y2 - y0;
a3 = y1;
return(a0*mu*mu2+a1*mu2+a2*mu+a3);
}
Here's from tabread4c~, in case someone wants to see but couldn't find the file:
a = wp[-1].w_float;
b = wp[0].w_float;
c = wp[1].w_float;
d = wp[2].w_float;
a0 = d - c - a + b;
a1 = a - b - a0;
a2 = c - a;
*out++ = ((a0*frac+a1)*frac+a2)*frac+b;
Matt
On Wed, Jun 25, 2008 at 12:06 PM, Charles Henry [EMAIL PROTECTED] wrote:
On Wed, Jun 25, 2008 at 10:32 AM, Matt Barber [EMAIL PROTECTED] wrote:
For what it's worth, here's supercollider's cubic interpolation
function, which differs from csound's and Pd's, which I believe are
equivalent:
static float cubicinterp(float x, float y0, float y1, float y2, float y3)
{
// 4-point, 3rd-order Hermite (x-form)
float c0 = y1;
float c1 = 0.5f * (y2 - y0);
float c2 = y0 - 2.5f * y1 + 2.f * y2 - 0.5f * y3;
float c3 = 0.5f * (y3 - y0) + 1.5f * (y1 - y2);
return ((c3 * x + c2) * x + c1) * x + c0;
}
Matt
a0=(3b-a-3c+d)/2(same as c3)
a1=a-5b/2+2c-d/2 (same as c2)
a2=(c-a)/2 (same as c1)
(b is c0)
f(x)=(((a0*x+a1)*x+a2)*x-+b
Actually that's just the same set of coefficients that I named in a
previous post... just in a different form. So, that's just the sort
of thing we could add to pd-extended
It's good to know what other people are doing in their software too
Chuck
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
That's a good reference. I was kind of interested in the hermite
polynomials method, but I couldn't figure it out from tabread4h~.c.
On a tangential note, this entry seems interesting:
http://en.wikipedia.org/wiki/Hermite_polynomials#Hermite_Functions_as_Eigenfunctions_of_the_Fourier_Transform
Probably ought to study that one... Those should have some useful
spectral properties.
It's good to see that we haven't strayed too far from other people's
work, yet. I had been looking into some orthogonal polynomials for
interpolation, but I haven't made heads or tails out of that either.
Chuck
On Wed, Jun 25, 2008 at 12:48 PM, Matt Barber [EMAIL PROTECTED] wrote:
PS -- also for what it's worth, a formula which seems equivalent to
the one used in [tabread4c~] is described here:
http://local.wasp.uwa.edu.au/~pbourke/other/interpolation/
it gives the following piece of code:
double CubicInterpolate(
double y0,double y1,
double y2,double y3,
double mu)
{
double a0,a1,a2,a3,mu2;
mu2 = mu*mu;
a0 = y3 - y2 - y0 + y1;
a1 = y0 - y1 - a0;
a2 = y2 - y0;
a3 = y1;
return(a0*mu*mu2+a1*mu2+a2*mu+a3);
}
Here's from tabread4c~, in case someone wants to see but couldn't find the
file:
a = wp[-1].w_float;
b = wp[0].w_float;
c = wp[1].w_float;
d = wp[2].w_float;
a0 = d - c - a + b;
a1 = a - b - a0;
a2 = c - a;
*out++ = ((a0*frac+a1)*frac+a2)*frac+b;
Matt
On Wed, Jun 25, 2008 at 12:06 PM, Charles Henry [EMAIL PROTECTED] wrote:
On Wed, Jun 25, 2008 at 10:32 AM, Matt Barber [EMAIL PROTECTED] wrote:
For what it's worth, here's supercollider's cubic interpolation
function, which differs from csound's and Pd's, which I believe are
equivalent:
static float cubicinterp(float x, float y0, float y1, float y2, float y3)
{
// 4-point, 3rd-order Hermite (x-form)
float c0 = y1;
float c1 = 0.5f * (y2 - y0);
float c2 = y0 - 2.5f * y1 + 2.f * y2 - 0.5f * y3;
float c3 = 0.5f * (y3 - y0) + 1.5f * (y1 - y2);
return ((c3 * x + c2) * x + c1) * x + c0;
}
Matt
a0=(3b-a-3c+d)/2(same as c3)
a1=a-5b/2+2c-d/2 (same as c2)
a2=(c-a)/2 (same as c1)
(b is c0)
f(x)=(((a0*x+a1)*x+a2)*x-+b
Actually that's just the same set of coefficients that I named in a
previous post... just in a different form. So, that's just the sort
of thing we could add to pd-extended
It's good to know what other people are doing in their software too
Chuck
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Charles Henry a écrit :
On Wed, Jun 25, 2008 at 10:32 AM, Matt Barber [EMAIL PROTECTED] wrote:
For what it's worth, here's supercollider's cubic interpolation
function, which differs from csound's and Pd's, which I believe are
equivalent:
static float cubicinterp(float x, float y0, float y1, float y2, float y3)
{
// 4-point, 3rd-order Hermite (x-form)
float c0 = y1;
float c1 = 0.5f * (y2 - y0);
float c2 = y0 - 2.5f * y1 + 2.f * y2 - 0.5f * y3;
float c3 = 0.5f * (y3 - y0) + 1.5f * (y1 - y2);
return ((c3 * x + c2) * x + c1) * x + c0;
}
Matt
a0=(3b-a-3c+d)/2(same as c3)
a1=a-5b/2+2c-d/2 (same as c2)
a2=(c-a)/2 (same as c1)
(b is c0)
f(x)=(((a0*x+a1)*x+a2)*x-+b
Actually that's just the same set of coefficients that I named in a
previous post... just in a different form.
yes,
and it's certainly the best i tried.
So, that's just the sort
of thing we could add to pd-extended
I agree
so finally, what should be the name of this object?
is it ok if i remove the other test i made and to use only this one?
cyrille
It's good to know what other people are doing in their software too
Chuck
___
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
Re: [PD] better tabread4~
IOhannes m zmoelnig wrote: this might be the reason why i prefer [lop~] over [cool_filter~] and Pd over reactor. one of the pushes to me finally learning Pd was discovering that there was an object called [moses], and it did what it said it did. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Hans-Christoph Steiner [EMAIL PROTECTED] wrote: Yes that'right, hmm I guess I knew that but said it in a woolly way Amend that to [tabread~] - play back at exactly the original rate [tabread4~] - play back at close to the orginal rate [tabread4c~] - play back with wider transposition Perhaps these could have more descriptive names, especially if there was a tabread, etc. library. Some quick ideas: [tabread_tweak~] [tabread_transpose~] .hc I really hate to be a fart on this one, but I'm sorry to say I don't like this scheme at all. This implies that the tabread classes are only used for sampling. I understand that probably 95% of their use is for sampling, and that for a majority of users the more descriptive names might be helpful in that context, but I really feel bad about it for a number of reasons aside from the real estate arguments in other posts: 1) [tabread4~] has several other important applications (e.g. waveshaping), where the tweak and transpose appendages would have little relevance. 2) I tend to greatly prefer object names which say what the object does, not what it is for, especially with rather low-level objects. IMO, the latter labeling tends to constrain one's thinking about the use of an object in a way that the former does not. 3) In pedagogical situations I dislike black box objects which hide too much of the implementation. This probably wouldn't be the case with these objects, but it feels like it's leaning too far in that direction. One could argue that those who want to really know what's going on would have to page through the documentation just as much as someone who just wants things to work in the easiest way. I very much understand the need to get things done, however, and I am sensitive to the balance between having a substantial set of ready-to-use tools that you don't have to build, and the set of tools you would want to restrict yourself to if you were trying to learn the fundamentals of DSP and program flow. I think that vanilla Pd's leanness and explicitness make it an ideal teaching tool, but extended might better make Pd a production tool... however I don't think you would introduce descriptive names like this into vanilla, and especially into something as low-level as a table reader. All of that said, I think something like the [sampler~] object proposed in another post would be much in keeping with the user-friendly filter objects like [bp~] (as opposed to [rpole~] and [rzero~] which are the real building block kinds of filter classes). An object name like [sampler~] would indeed restrict its relevance to sampling, and the automatic interpolation schemes would support this restriction... such a thing might be useful in readsf~ contexts as well. Thanks, Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: All of that said, I think something like the [sampler~] object proposed in another post would be much in keeping with the user-friendly filter objects like [bp~] (as opposed to [rpole~] and [rzero~] which are the real building block kinds of filter classes). An object name like [sampler~] would indeed restrict its relevance to sampling, and the automatic interpolation schemes would support this restriction... such a thing might be useful in readsf~ contexts as well. Though I would rather avoid the terms sampler or sampling, as sample already has so many different meanings in the audio world, it almost lost all usefulness. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Hans-Christoph Steiner wrote: tabread4~ isn't such a great name that it should be used for the new one. hmm, from my elitist point of view, [tabread4~] tells me something about how this object works (its reading a table using 4 point interpolation) rather than [tabread_tweak~] which tells me exactly nothing apart from being a modified version of [tabread~] which might do what i want or not. certainly the exact meaning of the elements tab read 4 and ~ is something you have to get used to or learn by heart. but at least they make sense, once you know them. this might be the reason why i prefer [lop~] over [cool_filter~] and Pd over reactor. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Jun 24, 2008, at 11:36 AM, IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: tabread4~ isn't such a great name that it should be used for the new one. hmm, from my elitist point of view, [tabread4~] tells me something about how this object works (its reading a table using 4 point interpolation) rather than [tabread_tweak~] which tells me exactly nothing apart from being a modified version of [tabread~] which might do what i want or not. certainly the exact meaning of the elements tab read 4 and ~ is something you have to get used to or learn by heart. but at least they make sense, once you know them. this might be the reason why i prefer [lop~] over [cool_filter~] and Pd over reactor. fgmasdr IOhannes 4 stands for 4-point interpolation, that is true. But there are many algorithms for 4-point interpolation, as this thread as laid bare. tabread4~ could also describe something that reads 4 values and averages them, it could also be the 4th version of tabread~. Those are all existing naming conventions in Pd. Feel free to critique my suggestions, but it isn't really productive until there are suggestions for how to do it differently, rather than merely saying my suggestion is bad. How about putting the algorithm name in there somehow? .hc [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Jun 24, 2008, at 8:22 AM, Matt Barber wrote: Hans-Christoph Steiner [EMAIL PROTECTED] wrote: Yes that'right, hmm I guess I knew that but said it in a woolly way Amend that to [tabread~] - play back at exactly the original rate [tabread4~] - play back at close to the orginal rate [tabread4c~] - play back with wider transposition Perhaps these could have more descriptive names, especially if there was a tabread, etc. library. Some quick ideas: [tabread_tweak~] [tabread_transpose~] .hc I really hate to be a fart on this one, but I'm sorry to say I don't like this scheme at all. This implies that the tabread classes are only used for sampling. I understand that probably 95% of their use is for sampling, and that for a majority of users the more descriptive names might be helpful in that context, but I really feel bad about it for a number of reasons aside from the real estate arguments in other posts: 1) [tabread4~] has several other important applications (e.g. waveshaping), where the tweak and transpose appendages would have little relevance. 2) I tend to greatly prefer object names which say what the object does, not what it is for, especially with rather low-level objects. IMO, the latter labeling tends to constrain one's thinking about the use of an object in a way that the former does not. Yes, definitely, that's why I don't think 4c really says much about what it does or what it is for. .hc 3) In pedagogical situations I dislike black box objects which hide too much of the implementation. This probably wouldn't be the case with these objects, but it feels like it's leaning too far in that direction. One could argue that those who want to really know what's going on would have to page through the documentation just as much as someone who just wants things to work in the easiest way. I very much understand the need to get things done, however, and I am sensitive to the balance between having a substantial set of ready-to-use tools that you don't have to build, and the set of tools you would want to restrict yourself to if you were trying to learn the fundamentals of DSP and program flow. I think that vanilla Pd's leanness and explicitness make it an ideal teaching tool, but extended might better make Pd a production tool... however I don't think you would introduce descriptive names like this into vanilla, and especially into something as low-level as a table reader. All of that said, I think something like the [sampler~] object proposed in another post would be much in keeping with the user-friendly filter objects like [bp~] (as opposed to [rpole~] and [rzero~] which are the real building block kinds of filter classes). An object name like [sampler~] would indeed restrict its relevance to sampling, and the automatic interpolation schemes would support this restriction... such a thing might be useful in readsf~ contexts as well. Thanks, Matt kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Hans-Christoph Steiner wrote: 4 stands for 4-point interpolation, that is true. But there are many algorithms for 4-point interpolation, as this thread as laid bare. tabread4~ could also describe something that reads 4 values and averages them, it could also be the 4th version of tabread~. Those are all existing naming conventions in Pd. true that 4 doesn't say much about the interpolation alogrithm and that is definitely a weakness in the current naming scheme. it was not my intention to say that the current scheme is the non-plus-ultra in sophistication. it, however, was my intention to say that [tabread_tweak~] is one of the worst possible names i could think of. i do not say that this is is constructive criticism, rather i meant it as a preventive criticism. gmsdfr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Tue, 24 Jun 2008, IOhannes m zmoelnig wrote: true that 4 doesn't say much about the interpolation alogrithm and that is definitely a weakness in the current naming scheme. Well, I'd have expected 4 to be a cubic spline algorithm, because it uses a sliding window of 4 samples, polynomial interpolation is pretty much the default, 4-point polynomial leads to cubic curves (using Lagrange or not), and beyond having a continuous curve (C0) and continuous derivative (C1), it's also nice to have a continuous second-derivative (C2). All this leading to basically one specific formula, which [tabread4] doesn't use, but which I assumed [tabread4] was using, until Roman told me that Cyrille had looked at it closely and found it to be non-C1. (I made a mistake while talking to Roman. I said it's only C1, but the thing is that first derivatives are the last derivatives to be chosen according to samples. Second derivatives are chosen so that they fall to zero at every junction of pieces, and never anything else than zero. It's like that because there are 4 degrees of freedom, which are used up for start end points of f f'... that's 4, so f''(0) and f''(1) can't be set by variables... but it can be set by constants.) All this to say that I don't think that the current interpolator deserved to be called THE 4, because there's a more generally useful interpolator that uses up the same power and thus would've been a much better choice for a default. The point of a default value or default algorithm is so that you need to specify a non-default as seldom as possible, and an unqualified 4 looks like a default to me (the name of the algorithm is implied) it, however, was my intention to say that [tabread_tweak~] is one of the worst possible names i could think of. i do not say that this is is constructive criticism, rather i meant it as a preventive criticism. It's like the names of the codecs in Quicktime-related GUIs... they all come out with different names than what the rest of the world is calling them... I don't have any names off the top of my head anymore, but it sure is/was confusing. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Tue, 24 Jun 2008, Matt Barber wrote: [tabread_tweak~] [tabread_transpose~] I really hate to be a fart on this one You should love it, if you intend it for the good of pd. 2) I tend to greatly prefer object names which say what the object does, not what it is for, This is one of the major points of the DIY movement. I'm sure that there are men who buy themselves «bikini line trimmers» in pink boxes labelled «designed exclusively for women» just so that they can have more precision tailoring themselves a chin pinch, and this doesn't have anything to do with being gay or effeminate, though the peer pressure wouldn't miss making that kind of allusion or another of the same level. Some other people would use the same bikini line trimmer to perform intricate pruning on bonsaï trees. (doesn't anyone feel embarrassed that someone talks about a bikini line trimmer on pd-list? does it make me pervert, gay, or just oblivious to social customs? doesn't that exactly prove our point? consider the object for what it can do.) especially with rather low-level objects. IMO, the latter labeling tends to constrain one's thinking about the use of an object in a way that the former does not. I'd say that beyond what it does and what it's for, there is also what it's marketed as or what you will be told that it's for, which might be the same as what it's for, but modified and specialised to make it more obviously relevant to people's life. A major schism in the pd world is how GEM/PDP feel somewhat more what it's for than pd itself, whereas GF and pd are more what it does. This is about both the naming and how an object's multipurposeness is only multiple ways of thinking about what is the single thing that the object does, rather than have multipurposeness correspond to multiple behaviours defined separately, each matching a single what it's for. This is a gross generalisation. There are definitely GEM/PDP classes that were designed in a what it does way, and GF classes that are definitely what it's for in style, but when asking yourself the question of why something is different in GF than in [pix_...], that kind of difference is often the most important difference. All of that said, I think something like the [sampler~] object proposed in another post would be much in keeping with the user-friendly filter objects like [bp~] (as opposed to [rpole~] and [rzero~] which are the real building block kinds of filter classes). I consider [lop~] to be on essentially the same level as [rpole~], really. [rpole~] is simply a different kind of building block that appeals more to people who work in terms of so-called «transfer functions». _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: 4 stands for 4-point interpolation, that is true. But there are many algorithms for 4-point interpolation, as this thread as laid bare. tabread4~ could also describe something that reads 4 values and averages them, it could also be the 4th version of tabread~. Those are all existing naming conventions in Pd. I'm still fond of using only a single [tabread4~] object and being able to specify the type of 4-point interpolation to use with a [interpolate cubic( message or so. Additionally with a -interpolate cubic argument, maybe. Less strain on the global namespace and backwards compatible. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On 24/06/2008, at 12.17, Hans-Christoph Steiner wrote: Feel free to critique my suggestions, but it isn't really productive until there are suggestions for how to do it differently, rather than merely saying my suggestion is bad. Depends on what it is to be different from. If it is to be different from the current state then it excludes the possibility to argue for status quo. Best wishes for a happy day. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
I disagree entirely with the trend of this discussion towards naming or methods to choose an interpolation method. We need not get ahead of ourselves, when we don't even know if it's a better tabread (like the name of this discussion). Let's make sure this thing is solid and finds good usage before expanding the tabread4~ code with extra methods. It's nice to have descriptive names for the different interpolation schemes, but there is a big difference for naming them according to what they do or how they're used, as Matju said. I see no problem with shortening the names, because it's not practical to name these things concisely, e.g. tabread4_continuous_first_derivative~ or tabread4_anti_aliasing~ So, what's wrong with tabread4c~ or tabread4a~? plenty of alternatives, but really, this is short and memorable, while keeping with the notion that these are small differences from the original tabread4~ I think it's best to consider making a library of tabread4~ alternatives, and later consider moving the different interpolation schemes to tabread4~ methods, if it's worth-while. Chuck On Tue, Jun 24, 2008 at 4:12 PM, bsoisoi [EMAIL PROTECTED] wrote: I agree, being able to specify interpolation via an inlet message would be great (from my users perspective). Plus, deciding you want better interpolation (or none at all) in any given abstraction would not require the touching of code, which is a big + in my opinion. Sometimes I may want quality, sometimes not, and other times I don't know yet or might want to change it on the fly. That's what always bugged me about Reaktor's table object, you have to right-click on the table in the setup and enable interpolation manually, which to me is the equivalent and equally annoying to specifying a different object in Pd. If you have many of these in your app hunting is not very fun. Cheers m8s, ~brandon On Jun 24, 2008, at 10:25 AM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: 4 stands for 4-point interpolation, that is true. But there are many algorithms for 4-point interpolation, as this thread as laid bare. tabread4~ could also describe something that reads 4 values and averages them, it could also be the 4th version of tabread~. Those are all existing naming conventions in Pd. I'm still fond of using only a single [tabread4~] object and being able to specify the type of 4-point interpolation to use with a [interpolate cubic( message or so. Additionally with a -interpolate cubic argument, maybe. Less strain on the global namespace and backwards compatible. Ciao -- Frank Barknecht _ __footils.org__ ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
bsoisoi wrote: I agree, being able to specify interpolation via an inlet message would be great (from my users perspective). hmm, i am not totally convinced (but actually don't care) as this leads to bloated objects which can just do everything and you specify what they should do via parameters. why do we have objects then? That's what always bugged me about Reaktor's table object, you have to right-click on the table in the setup and enable interpolation manually, which to me is the equivalent and equally annoying to specifying a different object in Pd. If you have many of these in your app hunting is not very fun. anyhow, now for something constructive: you can always create an abstraction [tabread_tweaked~] that is like [inlet~] | [tabread~ $1] | [outlet~] and use this abstraction. if you later decide that you do want interpolation just make the abstraction to be like [inlet~] | [tabread4~ $1] | [outlet~] et voila. you could argue that then you would have to think of the variability beforehand; bit you would have to do this as well if you are using messages (unless you are up to hunting all the [tabread~] in your patch to add the special message) fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Excellent point, don't listen to me! :) From your example, I'm assuming you're hinting at including the ability in this abstraction to switch interpolation schemes by enabling/disabling sub-patched tabread~, tabread4~, and tabread4c~ objects via inlet messages or creation arguments. In the end, I would probably only use a tabread4c~ type object in special circumstances given tabread4~ is good enough. So whatever you decide to do I'm sure it's going to be legit (as Pd rocks). Cheers, ~Brandon On Jun 24, 2008, at 6:06 PM, IOhannes m zmoelnig wrote: hmm, i am not totally convinced (but actually don't care) as this leads to bloated objects which can just do everything and you specify what they should do via parameters. why do we have objects then? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Wed, 25 Jun 2008, IOhannes m zmoelnig wrote: hmm, i am not totally convinced (but actually don't care) as this leads to bloated objects which can just do everything and you specify what they should do via parameters. why do we have objects then? Objects and classes also have other benefits apart from making people believe that they should act a special way just because they are in presence of objects... if that's a benefit... I don't know of any docs that explain what is good and bad taste in designing pd object class interfaces. This is a topic that is always outside the scope of whichever pd workshop anyone ever takes. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Tue, 24 Jun 2008, Charles Henry wrote: I see no problem with shortening the names, because it's not practical to name these things concisely, e.g. tabread4_continuous_first_derivative~ or tabread4_anti_aliasing~ continuous first derivative is listed as continuously differentiable in the list of meanings of this abbreviation: http://en.wikipedia.org/wiki/C1 I think it's best to consider making a library of tabread4~ alternatives, and later consider moving the different interpolation schemes to tabread4~ methods, if it's worth-while. I don't think that more than one alternative will be necessary. For 4-point table lookups that go through all the original points, I don't know why anyone would aim lower than a C2 piecewise-polynomial. Unfortunately, it would be somewhat too late to just call it [tabread4~]. Or not. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Jun 23, 2008, at 7:52 AM, Andy Farnell wrote: On Mon, 23 Jun 2008 00:50:44 -0400 (EDT) Mathieu Bouchard [EMAIL PROTECTED] wrote: On Mon, 16 Jun 2008, Andy Farnell wrote: with [tabread4~] being good enough for playing back files at their original rate, If you are going to playback at original rate, [tabread4] is both useless and 10 times slower than [tabread]. All that [tabread4] is good at, is playing back at different non-original rates (that is anything else than +1 times and -1 times). _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec Yes that'right, hmm I guess I knew that but said it in a woolly way Amend that to [tabread~] - play back at exactly the original rate [tabread4~] - play back at close to the orginal rate [tabread4c~] - play back with wider transposition Perhaps these could have more descriptive names, especially if there was a tabread, etc. library. Some quick ideas: [tabread_tweak~] [tabread_transpose~] .hc -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Mon, 23 Jun 2008 11:38:27 +0200 Hans-Christoph Steiner [EMAIL PROTECTED] wrote: Perhaps these could have more descriptive names, especially if there was a tabread, etc. library. Some quick ideas: [tabread_tweak~] [tabread_transpose~] Hard to argue against, but I'm such a fan of Vanilla style compactness and brevity. :) This may have been discussed before, but to widen the discussion... I got thinking about a great discussion I read on music-dsp or harmony-central (sorry can't find the ref now) about sampler design. Since , as matju points out there's no interpolation advantage at unity pitch I remembered the hoopla proposed to make 'one size fits all' compromise designs. The conclusions were something indicationg that a general purpose [sampler~] (?) object would use the approach taken by Emu or Native Instruments, selecting the best method depending on the case. There are maybe 5 classes, each requiring different approaches for quality results. No transposition - very common for drum machines etc Very small transpositions - microtonal variations on existing scale multisamples Transpositions down within a fifth Transpositions down greater than a fifth Transpositions up With the interpolation choices being none, linear, cubic, oversampled sinc and several variations of decimation/resampling schemes. I'm not sure where 'very small' transpositions fit into that, aren't they actually a difficult case? When people talk about the 'sound quality' of Pd I suspect they are more casual musical users who largely do sample based work. It would be great to have a whole suite of [tabreadX~] for the programmers. But for more casual users I think extended might greatly benefit from a 'just works' [sampler~] object. You could give it arguments along the lines of polyphony, outputs etc... It could even do multi-sample (with many tables). Add that to a file reader [soundfiler-kontakt] or [soundfiler-akai] to automatically generate the tables for [sampler~] and Pd would become quite attractive to a larger user base I think. a. .hc -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list kill your television -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Jun 23, 2008, at 1:01 PM, Andy Farnell wrote: On Mon, 23 Jun 2008 11:38:27 +0200 Hans-Christoph Steiner [EMAIL PROTECTED] wrote: Perhaps these could have more descriptive names, especially if there was a tabread, etc. library. Some quick ideas: [tabread_tweak~] [tabread_transpose~] Hard to argue against, but I'm such a fan of Vanilla style compactness and brevity. :) This compactness only really helps speed up the typing of code. It hinders the reading of code and the learning of code. Plus it means that us mere mortals, who cannot remember what c in [tabread4c~] means, it means we have to constantly ride the reference pages rather than just writing code. Trading all this for typing a few less keystrokes seems to me a very bad deal. Apparently, people who use Smalltalk, Java, Python, Ruby, Obj-C and even sometimes C++ seem to agree. .hc This may have been discussed before, but to widen the discussion... I got thinking about a great discussion I read on music-dsp or harmony-central (sorry can't find the ref now) about sampler design. Since , as matju points out there's no interpolation advantage at unity pitch I remembered the hoopla proposed to make 'one size fits all' compromise designs. The conclusions were something indicationg that a general purpose [sampler~] (?) object would use the approach taken by Emu or Native Instruments, selecting the best method depending on the case. There are maybe 5 classes, each requiring different approaches for quality results. No transposition - very common for drum machines etc Very small transpositions - microtonal variations on existing scale multisamples Transpositions down within a fifth Transpositions down greater than a fifth Transpositions up With the interpolation choices being none, linear, cubic, oversampled sinc and several variations of decimation/resampling schemes. I'm not sure where 'very small' transpositions fit into that, aren't they actually a difficult case? When people talk about the 'sound quality' of Pd I suspect they are more casual musical users who largely do sample based work. It would be great to have a whole suite of [tabreadX~] for the programmers. But for more casual users I think extended might greatly benefit from a 'just works' [sampler~] object. You could give it arguments along the lines of polyphony, outputs etc... It could even do multi-sample (with many tables). Add that to a file reader [soundfiler-kontakt] or [soundfiler-akai] to automatically generate the tables for [sampler~] and Pd would become quite attractive to a larger user base I think. a. .hc -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list - --- kill your television -- Use the source It is convenient to imagine a power beyond us because that means we don't have to examine our own lives., from The Idols of Environmentalism, by Curtis White ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Mon, 23 Jun 2008 13:18:11 +0200 Hans-Christoph Steiner [EMAIL PROTECTED] wrote: This compactness only really helps speed up the typing of code. It hinders the reading of code and the learning of code. Plus it means that us mere mortals, who cannot remember what c in [tabread4c~] means, it means we have to constantly ride the reference pages rather than just writing code. Trading all this for typing a few less keystrokes seems to me a very bad deal. Apparently, people who use Smalltalk, Java, Python, Ruby, Obj-C and even sometimes C++ seem to agree. Can't disagree with any of that. You're absolutely right. I have had rather a special case interest in compact code - writing the sound design book. Many diagrams would have been impossible to typeset or fit onto a page if Pd used long object names. You might think Ah heck, what difference a few characters makes?! But when you multiply that by 20, 30, 40 objects in a patch the real-estate issues get quite tough. I've spent hours refactoring and shuffling patches about to make them presentable. -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Mon, 2008-06-23 at 06:52 +0100, Andy Farnell wrote: Yes that'right, hmm I guess I knew that but said it in a woolly way Amend that to [tabread~] - play back at exactly the original rate [tabread4~] - play back at close to the orginal rate [tabread4c~] - play back with wider transposition i don't see any justification to keep [tabread4~] in this list. cyrille once mentioned that his new class isn't computationally more expensive. if there is a difference between [tabread4~] and [tabread4c~], then it is, that [tabread4c~] is _better_ than [tabread4~] (according to some previous posts regarding this subject). the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Mon, June 23, 2008 2:17 pm, Roman Haefeli wrote: the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo. Witch is a good enough reason to keep it, imho. I much prefer Frank's suggestion. I.e. using the tabread4 name for a /class/ that offered a bunch of /methods/ - f.x. one like how tabread4 does now and one like how tabread4c. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Mon, 2008-06-23 at 14:35 +0200, Steffen Juul wrote: On Mon, June 23, 2008 2:17 pm, Roman Haefeli wrote: the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo. Witch is a good enough reason to keep it, imho. i wasn't proposing to deprecate it, but i was only saying, it is the _only_ reason to keep it i can think of. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
well, tabread4c~ is far from perfect, it has the same aliasing problem than tabread4~ and it create more distortion than tabread4~. (but in lower frequency). one told me that modern commercial audio software can use 32 points shannon interpolation. http://en.wikipedia.org/wiki/Whittaker–Shannon_interpolation_formula i'd like to try that... it will be more expensive, but this is negligible on recent hardware, and sound quality worth it. so, for now, i'll try different interpolation schematic, and we will see latter what to use... cyrille Roman Haefeli a écrit : On Mon, 2008-06-23 at 06:52 +0100, Andy Farnell wrote: Yes that'right, hmm I guess I knew that but said it in a woolly way Amend that to [tabread~] - play back at exactly the original rate [tabread4~] - play back at close to the orginal rate [tabread4c~] - play back with wider transposition i don't see any justification to keep [tabread4~] in this list. cyrille once mentioned that his new class isn't computationally more expensive. if there is a difference between [tabread4~] and [tabread4c~], then it is, that [tabread4c~] is _better_ than [tabread4~] (according to some previous posts regarding this subject). the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ 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
Re: [PD] better tabread4~
On Jun 23, 2008, at 2:58 PM, Roman Haefeli wrote: On Mon, 2008-06-23 at 14:35 +0200, Steffen Juul wrote: On Mon, June 23, 2008 2:17 pm, Roman Haefeli wrote: the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo. Witch is a good enough reason to keep it, imho. i wasn't proposing to deprecate it, but i was only saying, it is the _only_ reason to keep it i can think of. tabread4~ isn't such a great name that it should be used for the new one. Why not use a more descriptive name for the new one? Also, changing the code of tabread4~ will change the sound quality of a piece. I think it is very important to keep the same sound quality since many people have spent a lot of time building patches around tabread4~ and like the way those patches sound. .hc All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Mon, Jun 23, 2008 at 8:23 AM, cyrille henry [EMAIL PROTECTED] wrote: well, tabread4c~ is far from perfect, it has the same aliasing problem than tabread4~ and it create more distortion than tabread4~. (but in lower frequency). Strictly speaking, these interpolations don't create distortion in as much as they have a non-flat frequency response. No matter which method you use, the interpolation function can be re-written as a convolution, which is linear. In my prior analysis of the tabread4~ impulse response, I obtained the following function for the impulse response. g(t)=I[-2,2](t)(-1/6*|t|^3 - 2*t^2 - 11/6*|t| + 1) + I[-1,1](t)(2/3*|t|^3 - 2*t^2 + 4/3*|t|) And it's fourier transform, where w=pi represents the Nyquist frequency. (by the way, the angular frequency notation greatly simplifies the calculus involved) G(w)=(1/w^2)*[1/3*cos(2w) - 4/3*cos(w) + 1]+ (1/w^4)*[2*cos(2w) - 8*cos(w) + 6] This function falls off at a rate of at most -6 dB/octave (according to the 1/w^2 term). What you are referring to as distortion is not actually distortion, but aliasing and a non-flat frequency response. The spectrum of this function is pretty nice, but everything above pi rad/sec is aliased, which causes some additional frequencies, mostly high frequencies. I'm reluctant to do the same for tabread4c~ because it takes several hours to do. If you come up with a good set of coefficients that seem to be pretty solid, I'll spare some time for the frequency response. one told me that modern commercial audio software can use 32 points shannon interpolation. http://en.wikipedia.org/wiki/Whittaker–Shannon_interpolation_formula i'd like to try that... it will be more expensive, but this is negligible on recent hardware, and sound quality worth it. I doubt that it would be negligible. I do agree that it would find many applications, but not as a replacement for a fast, good-enough tabread. 32-point windowed sinc interpolation borders on anal retentive. Instead of that, it might be better to probe out what degree of fast polynomial interpolation will have a good-enough spectrum. Chuck so, for now, i'll try different interpolation schematic, and we will see latter what to use... cyrille Roman Haefeli a écrit : On Mon, 2008-06-23 at 06:52 +0100, Andy Farnell wrote: Yes that'right, hmm I guess I knew that but said it in a woolly way Amend that to [tabread~] - play back at exactly the original rate [tabread4~] - play back at close to the orginal rate [tabread4c~] - play back with wider transposition i don't see any justification to keep [tabread4~] in this list. cyrille once mentioned that his new class isn't computationally more expensive. if there is a difference between [tabread4~] and [tabread4c~], then it is, that [tabread4c~] is _better_ than [tabread4~] (according to some previous posts regarding this subject). the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Hello, The speed of this conversation makes me a little uncomfortable. Perhaps [tabread4~] is not so weird after all: if I'm not mistaken, this is algebraically identical to the interpolation used in csound's opcodes (e.g. oscil3)... I'm pretty sure both are piecewise Lagrange polynomial interpolators (with x_i values equal to -1, 0, 1, and 2, and interpolation between x=0 and x=1). There seems to be, then, at least some consensus about what generic cubic interpolation means, given csound's rather long history to sort this out (though, I'm surprised they haven't pulled together some of the algebra to reduce the number of divides... maybe this leads to a more accurate result?). I would be a lot more comfortable if it could be established exactly what kind of cubic interpolation is in the [tabread4c~] -- this would help with the naming standards as well. Whatever new algorithms become available should be extended to the vd~ class (or copies thereof) as well. BTW, the naming difference between csound's oscil3 and [tabread4~] (one has 3 and the other 4) seems justified, since csound will automatically calculate the two extra guard points you need (tables in csound can come with one guard point, but not more, so the 3 is a clear reminder that it's doing cubic interpolation), and in PD, the guard points should be put in the table by hand (so the 4 is a reminder that it's always using 4 points). This is one important reason [tabread_transpose~] and the like should not be implemented, unless the guard points are automatically generated in the object class. For the value of the consumer I appended the relevant code snippets... Pd code, from d_array.c: a = wp[-1].w_float; b = wp[0].w_float; c = wp[1].w_float; d = wp[2].w_float; cminusb = c-b; *out++ = b + frac * ( cminusb - 0.167f * (1.-frac) * ( (d - a - 3.0f * cminusb) * frac + (d + 2.0f*a - 3.0f*b) ) ); csound code, from OOps/ugens2.c: MYFLT frsq = fract*fract; MYFLT frcu = frsq*ym1; MYFLT t1 = y2 + y0+y0+y0; ar[n] = amp * (y0 + FL(0.5)*frcu + fract*(y1 - frcu/FL(6.0) - t1/FL(6.0) - ym1/FL(3.0)) + frsq*fract*(t1/FL(6.0) - FL(0.5)*y1) + frsq*(FL(0.5)* y1 - y0)); Date: Mon, 23 Jun 2008 14:17:36 +0200 From: Roman Haefeli [EMAIL PROTECTED] Subject: Re: [PD] better tabread4~ To: pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain On Mon, 2008-06-23 at 06:52 +0100, Andy Farnell wrote: Yes that'right, hmm I guess I knew that but said it in a woolly way Amend that to [tabread~] - play back at exactly the original rate [tabread4~] - play back at close to the orginal rate [tabread4c~] - play back with wider transposition i don't see any justification to keep [tabread4~] in this list. cyrille once mentioned that his new class isn't computationally more expensive. if there is a difference between [tabread4~] and [tabread4c~], then it is, that [tabread4c~] is _better_ than [tabread4~] (according to some previous posts regarding this subject). the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo. roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Mon, 16 Jun 2008, Andy Farnell wrote: with [tabread4~] being good enough for playing back files at their original rate, If you are going to playback at original rate, [tabread4] is both useless and 10 times slower than [tabread]. All that [tabread4] is good at, is playing back at different non-original rates (that is anything else than +1 times and -1 times). _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Yes that'right, hmm I guess I knew that but said it in a woolly way Amend that to [tabread~] - play back at exactly the original rate [tabread4~] - play back at close to the orginal rate [tabread4c~] - play back with wider transposition On Mon, 23 Jun 2008 00:50:44 -0400 (EDT) Mathieu Bouchard [EMAIL PROTECTED] wrote: On Mon, 16 Jun 2008, Andy Farnell wrote: with [tabread4~] being good enough for playing back files at their original rate, If you are going to playback at original rate, [tabread4] is both useless and 10 times slower than [tabread]. All that [tabread4] is good at, is playing back at different non-original rates (that is anything else than +1 times and -1 times). _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Wed, 11 Jun 2008, cyrille henry wrote: ok, if you don't wish to compile in order to test, here are 2 samples : http://www.chdh.free.fr/tab/tabosc4.wav http://www.chdh.free.fr/tab/tabosc4c.wav note that this is the worst case for tabread4~ : a very small table play at low frequency. I believe that the difference will be more perceivable in non-sound contexts or at least non-waveform contexts, e.g. video/OpenGL, or sequencing. for bigger table, the difference can be very small. For a normal 4-point interpolator, the size of the table does not matter, because you always only use the previous two points and the next two points. It's just the scale at which you are looking at the thing, that gives the impression of large details. I tried [tabread4] between two arrays of different sizes, to visualise interpolation, and just clicking around in one array for a few minutes got me to produce quite wild discontinuities of first derivative. This has little to do with the twice-continuously-differentiable (C2) nice things that I learned in school and such. In very large tables, the interpolation will get lousy because the resolution of floats gets too close to the resolution of the table indices themselves (that is, there are not enough fractions between two consecutive integers). But this does not happen at the beginning of the table. On average, though, or on worst-case (which often matters), bigger tables make things worse in pd. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Sounds like tabread4c~ is very useful, but I would be hesistant to replace the built-in tabread4~ with it, since it would change the sound of existing pieces that use it. Perhaps there could be a library of different interpolating table reading functions? .hc On Jun 16, 2008, at 1:15 AM, Andy Farnell wrote: Yep, definitely improved for downwards transposition. So, I suppose [tabread4c~] should be the choice for musical samplers, with [tabread4~] being good enough for playing back files at their original rate, and [tabread~] for control signals and suchlike. On Mon, 16 Jun 2008 00:45:51 +0200 Roman Haefeli [EMAIL PROTECTED] wrote: especially when transposing very low downwards. i couldn't hear any difference, when transposing upwards, though. -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Sounds like tabread4c~ is very useful, but I would be hesistant to replace the built-in tabread4~ with it, since it would change the sound of existing pieces that use it. Perhaps there could be a library of different interpolating table reading functions? Maybe one could select the interpolation method to use with a message and argument to [tabread4~] and let the old one be the default. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Hans-Christoph Steiner a écrit : Sounds like tabread4c~ is very useful, but I would be hesistant to replace the built-in tabread4~ with it, since it would change the sound of existing pieces that use it. Perhaps there could be a library of different interpolating table reading functions? yes, that was my plan c .hc On Jun 16, 2008, at 1:15 AM, Andy Farnell wrote: Yep, definitely improved for downwards transposition. So, I suppose [tabread4c~] should be the choice for musical samplers, with [tabread4~] being good enough for playing back files at their original rate, and [tabread~] for control signals and suchlike. On Mon, 16 Jun 2008 00:45:51 +0200 Roman Haefeli [EMAIL PROTECTED] wrote: especially when transposing very low downwards. i couldn't hear any difference, when transposing upwards, though. -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ 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
Re: [PD] better tabread4~
On Tue, Jun 17, 2008 at 12:22 PM, cyrille henry [EMAIL PROTECTED] wrote: Hans-Christoph Steiner a écrit : Sounds like tabread4c~ is very useful, but I would be hesistant to replace the built-in tabread4~ with it, since it would change the sound of existing pieces that use it. Perhaps there could be a library of different interpolating table reading functions? yes, that was my plan c If I can figure out ways to improve the anti-aliasing table read (tabread4a~)--I'd also like to contribute to the tabreadx~ library. I've been stuck on it for a while, trying to figure out ways to reduce the computational load. It works, but it's still quite literal--it does exactly what you tell it to, and the computations grow linearly with speed. Chuck .hc On Jun 16, 2008, at 1:15 AM, Andy Farnell wrote: Yep, definitely improved for downwards transposition. So, I suppose [tabread4c~] should be the choice for musical samplers, with [tabread4~] being good enough for playing back files at their original rate, and [tabread~] for control signals and suchlike. On Mon, 16 Jun 2008 00:45:51 +0200 Roman Haefeli [EMAIL PROTECTED] wrote: especially when transposing very low downwards. i couldn't hear any difference, when transposing upwards, though. -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
hello,
Charles Henry a écrit :
On Tue, Jun 10, 2008 at 10:29 AM, cyrille henry
[EMAIL PROTECTED] wrote:
...
I'm having trouble compiling, due to the garray_getfloatwords symbol.
Which version of Pd are you using?
vanilia 0.41.4
I'd like to see the waveform and test it out. Here's my analysis of key points
(a=x[-1], b=x[0], c=x[1], d=x[2])
83 a0 = d - c - a + b;
84 a1 = a - b - a0;
85 a2 = c - a;
86 *out++ = ((a0*frac+a1)*frac+a2)*frac+b;
At frac=0, output should be b. Check!
At frac=1, output should be c
((a0*1+a1)*1+a2)*1+b
=a0+a1+a2+b
=d-c-a+b + a-b-(d-c-a+b) + c-a + b
=d-c-a+b + a-b-d+c+a-b + c-a + b
=d-c-a+b + 2a-2b+c-d + c-a + b
=c
Check!
1st derivatives:
At frac=0,
d/dx f(x) = c-a
(This quantity really ought to be (c-a)/2, but let's see how the rest comes out)
At frac=1,
d/dx f(x) = 3*(d-c-a+b) + 2*(a-b-d+c+a-b) + c-a
=d-b
So, we've got 1st derivatives that match between samples. Check!
This looks like a really good plan. I might suggest some new
coefficients to try:
a0=(3b-a-3c+d)/2
a1=a-5b/2+2c-d/2
a2=(c-a)/2
ok, i don't have time for now to test anything.
i'll have more time in 1 or 2 weeks.
The only difference is the 1st derivatives are (c-a)/2 and (d-b)/2,
respectively.
Maybe you could try a 5th-degree polynomial next and set the 2nd
derivatives for continuity. This would involve 4-points as before,
but it might introduce a ripple in the interpolation (cubic
interpolation can't do that, since it only has two critical points).
i tried a Hermite interpolation.
it sound great, but i did not had time yet to explore the tension parametter.
here is the code if you wish to explore it.
I'm not keen on doing the spectral analysis, because it would take
about 4 hours, to do it by hand.
There's something I would like to see (once I can compile it). I made
a patch (attached) a while back to view the tabread4~ interpolation
function (impulse response). Give it a try if you're inclined to do
so, because it might surprise you.
attachement is a pict of the impulse response of tabread4~ and tabread4c~.
cyrille
Chuck
cyrille
Chuck
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
// GPL
// 99% comes from pd. just the interpolation shem is diferent and comes from :
// http://local.wasp.uwa.edu.au/~pbourke/other/interpolation/
#include m_pd.h
/ tabosc4h~ ***/
/* this is all copied from d_osc.c... what include file could this go in? */
#define UNITBIT32 1572864. /* 3*2^19; bit 32 has place value 1 */
/* machine-dependent definitions. These ifdefs really
should have been by CPU type and not by operating system! */
#ifdef IRIX
/* big-endian. Most significant byte is at low address in memory */
#define HIOFFSET 0/* word offset to find MSB */
#define LOWOFFSET 1/* word offset to find LSB */
#define int32 long /* a data type that has 32 bits */
#endif /* IRIX */
#ifdef MSW
/* little-endian; most significant byte is at highest address */
#define HIOFFSET 1
#define LOWOFFSET 0
#define int32 long
#endif
#if defined(__FreeBSD__) || defined(__APPLE__)
#include machine/endian.h
#endif
#ifdef __linux__
#include endian.h
#endif
#if defined(__unix__) || defined(__APPLE__)
#if !defined(BYTE_ORDER) || !defined(LITTLE_ENDIAN)
#error No byte order defined
#endif
#if BYTE_ORDER == LITTLE_ENDIAN
#define HIOFFSET 1
#define LOWOFFSET 0
#else
#define HIOFFSET 0/* word offset to find MSB */
#define LOWOFFSET 1/* word offset to find LSB */
#endif /* __BYTE_ORDER */
#include sys/types.h
#define int32 int32_t
#endif /* __unix__ or __APPLE__*/
union tabfudge
{
double tf_d;
int32 tf_i[2];
};
static t_class *tabosc4h_tilde_class;
typedef struct _tabosc4h_tilde
{
t_object x_obj;
t_float x_fnpoints;
t_float x_finvnpoints;
t_word *x_vec;
t_symbol *x_arrayname;
t_float x_f;
double x_phase;
t_float x_conv;
} t_tabosc4h_tilde;
static void *tabosc4h_tilde_new(t_symbol *s)
{
t_tabosc4h_tilde *x = (t_tabosc4h_tilde *)pd_new(tabosc4h_tilde_class);
x-x_arrayname = s;
x-x_vec = 0;
x-x_fnpoints = 512.;
x-x_finvnpoints = (1./512.);
outlet_new(x-x_obj, gensym(signal));
inlet_new(x-x_obj, x-x_obj.ob_pd, s_float, gensym(ft1));
x-x_f = 0;
return (x);
}
static t_int
Re: [PD] better tabread4~
On Wed, 2008-06-11 at 12:52 +0100, Andy Farnell wrote: I'm really looking forward to giving this the 'ear test'. Maybe I'm growing old but differerences in interpolation methods are very subtle to my perception. What would be the hard case to test it? It would be when the signal is greatly transposed, right? Remember when I tested your stab at sinc interpolation Charles, I honestly couldn't hear an big difference, there was one, but hard to define. yo, i recorded a snare drum sound (from the netpd-patch bon-minidrm) into a table and made a comparison, while playing the sample at different speeds. i chose the snare, because it has lots of noise in the high frequencies and i assume, this will probably rather make any interpolation effects audible. when playing at 0.05x original speed, the differences between [tabread4~] and [tabread4c~] are not so subtle anymore. [tabread4~] sounds almost 'gameboyish' compared to [tabread4c~]. without any scientific approach and without any judgement about which of those two methods gives the result, that comes closer to the imaginary function of the original soundfile, it's becoming obvious, that cubic interpolation sounds more what one would expect from an audio interpolation algorithm (i.e. less audible artefacts). the difference is not only clearly visible, but also audible, especially when transposing very low downwards. i couldn't hear any difference, when transposing upwards, though. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of cyrille henry Sent: 10 June 2008 16:30 To: Charles Henry Cc: pd-list@iem.at Subject: Re: [PD] better tabread4~ Charles Henry a écrit : On Tue, Jun 10, 2008 at 4:43 AM, cyrille henry [EMAIL PROTECTED] wrote: i realized that the 4 points interpolation in tabread4~ (and tabosc4~) are not optimal. Please describe. I've analyze the interpolation formula too, and I think that it is a true cubic interpolation. Is the numerical accuracy bad? well, i think the tabread4~ interpolation is a lagrange interpolator (but i'm may be wrong). at least with tabread4~, the 1st derivative is not continuous, while it should be with a cubic interpolation. i program a cubic interpolation, and the shape of the waveform is really different. Are we talking about 4-point polynomial interpolation versus cubic spline interpolation? These are indeed different. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
ok, thanks for the answer. i understand what's in your book, but i found other references where cubic interpolation is used for a function that offer continuity of the 1st derivative. i can understand that tabread4~ minimise the error when the table is large (when you play it faster than the original speed). but with a small table, or when you play it slower, the first derivative discontinuity create lot's of high frequency. So, in this condition, the function i use offer a better quality. see in the svn externals/nusmuk/tab/tabosc4c~-help.pd for more. cyrille Miller Puckette a écrit : I believe lagrange interpolation just means polynomail. tabread4~ uses cubic interpolation... details are in http://crca.ucsd.edu/~msp/techniques/latest/book-html/node31.html It may be that there's a better way to do 4-point interpoation than Lagrange but the way to find out would be by doing careful distortion measurements. In particular, I know there are ways do do 4-point interpolation that don't give discontinuous first derivatives, but I think most measures of distortion would indicate using the Lagrance one instead. cheers Miller On Tue, Jun 10, 2008 at 05:29:49PM +0200, cyrille henry wrote: Charles Henry a ?crit : On Tue, Jun 10, 2008 at 4:43 AM, cyrille henry [EMAIL PROTECTED] wrote: i realized that the 4 points interpolation in tabread4~ (and tabosc4~) are not optimal. Please describe. I've analyze the interpolation formula too, and I think that it is a true cubic interpolation. Is the numerical accuracy bad? well, i think the tabread4~ interpolation is a lagrange interpolator (but i'm may be wrong). at least with tabread4~, the 1st derivative is not continuous, while it should be with a cubic interpolation. i program a cubic interpolation, and the shape of the waveform is really different. please compile the object and look at the help patch to see the difference. i can also send waveforme picture if needed. cyrille Chuck ___ 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 ___ 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
Re: [PD] better tabread4~
I'm really looking forward to giving this the 'ear test'. Maybe I'm growing old but differerences in interpolation methods are very subtle to my perception. What would be the hard case to test it? It would be when the signal is greatly transposed, right? Remember when I tested your stab at sinc interpolation Charles, I honestly couldn't hear an big difference, there was one, but hard to define. Andy -- Use the source ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
ok, if you don't wish to compile in order to test, here are 2 samples : http://www.chdh.free.fr/tab/tabosc4.wav http://www.chdh.free.fr/tab/tabosc4c.wav note that this is the worst case for tabread4~ : a very small table play at low frequency. for bigger table, the difference can be very small. here is a picture of the patch used to make this samples : http://www.chdh.free.fr/tab/patch.jpg cyrille Andy Farnell a écrit : I'm really looking forward to giving this the 'ear test'. Maybe I'm growing old but differerences in interpolation methods are very subtle to my perception. What would be the hard case to test it? It would be when the signal is greatly transposed, right? Remember when I tested your stab at sinc interpolation Charles, I honestly couldn't hear an big difference, there was one, but hard to define. Andy ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
On Wed, 2008-06-11 at 00:05 +0200, cyrille henry wrote: i can understand that tabread4~ minimise the error when the table is large (when you play it faster than the original speed). but with a small table, or when you play it slower, the first derivative discontinuity create lot's of high frequency. hm... several times i had the impression, i used [tabread~] instead of [tabread4~] because of the high frequencies, that are audible, even if the sample is played very slowly. i assume, those come from the discontinuites you mentioned. but when i compared to [tabread~], there was definitely a huge difference. however, just out of curiosity, i wonder, whether a different algorithm is optimal for playing faster than original than for playing slower. i am looking forward to check your classes. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
I'm interested in this too... I'm deep inside something else right now but will check this out when I can. cheers M On Wed, Jun 11, 2008 at 02:23:11PM +0200, cyrille henry wrote: ok, if you don't wish to compile in order to test, here are 2 samples : http://www.chdh.free.fr/tab/tabosc4.wav http://www.chdh.free.fr/tab/tabosc4c.wav note that this is the worst case for tabread4~ : a very small table play at low frequency. for bigger table, the difference can be very small. here is a picture of the patch used to make this samples : http://www.chdh.free.fr/tab/patch.jpg cyrille Andy Farnell a ?crit : I'm really looking forward to giving this the 'ear test'. Maybe I'm growing old but differerences in interpolation methods are very subtle to my perception. What would be the hard case to test it? It would be when the signal is greatly transposed, right? Remember when I tested your stab at sinc interpolation Charles, I honestly couldn't hear an big difference, there was one, but hard to define. Andy ___ 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
Re: [PD] better tabread4~
On Tue, Jun 10, 2008 at 4:43 AM, cyrille henry [EMAIL PROTECTED] wrote: i realized that the 4 points interpolation in tabread4~ (and tabosc4~) are not optimal. Please describe. I've analyze the interpolation formula too, and I think that it is a true cubic interpolation. Is the numerical accuracy bad? Chuck ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] better tabread4~
Charles Henry a écrit : On Tue, Jun 10, 2008 at 4:43 AM, cyrille henry [EMAIL PROTECTED] wrote: i realized that the 4 points interpolation in tabread4~ (and tabosc4~) are not optimal. Please describe. I've analyze the interpolation formula too, and I think that it is a true cubic interpolation. Is the numerical accuracy bad? well, i think the tabread4~ interpolation is a lagrange interpolator (but i'm may be wrong). at least with tabread4~, the 1st derivative is not continuous, while it should be with a cubic interpolation. i program a cubic interpolation, and the shape of the waveform is really different. please compile the object and look at the help patch to see the difference. i can also send waveforme picture if needed. cyrille Chuck ___ 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
Re: [PD] better tabread4~
I believe lagrange interpolation just means polynomail. tabread4~ uses cubic interpolation... details are in http://crca.ucsd.edu/~msp/techniques/latest/book-html/node31.html It may be that there's a better way to do 4-point interpoation than Lagrange but the way to find out would be by doing careful distortion measurements. In particular, I know there are ways do do 4-point interpolation that don't give discontinuous first derivatives, but I think most measures of distortion would indicate using the Lagrance one instead. cheers Miller On Tue, Jun 10, 2008 at 05:29:49PM +0200, cyrille henry wrote: Charles Henry a ?crit : On Tue, Jun 10, 2008 at 4:43 AM, cyrille henry [EMAIL PROTECTED] wrote: i realized that the 4 points interpolation in tabread4~ (and tabosc4~) are not optimal. Please describe. I've analyze the interpolation formula too, and I think that it is a true cubic interpolation. Is the numerical accuracy bad? well, i think the tabread4~ interpolation is a lagrange interpolator (but i'm may be wrong). at least with tabread4~, the 1st derivative is not continuous, while it should be with a cubic interpolation. i program a cubic interpolation, and the shape of the waveform is really different. please compile the object and look at the help patch to see the difference. i can also send waveforme picture if needed. cyrille Chuck ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
