dan b

I've been writing a few extensions of Peter Blasser's Bound and Bounce triangle synthesis method for Max. Currently I'm trying to apply EPTR to it, based on this paper:

http://home.mit.bme.hu/~bank/publist/smc13.pdf

https://github.com/DanBennettDev/db.bounce-/tree/PTR_Rewrite

[note - I'm wrong in paragraph below - if you're looking for an EPTR implementation to crib keep the "transition region" conditionals but ditch my "transition" conditionals. Or better still just follow the paper above directly]

I started out more or less following the code at the bottom of the paper exactly, but I think there's an error in there - just in terms of drawing the triangle wave. the code in the paper causes the naive triangle to change direction before it reaches its limit, which seems to cause pitch distortions, and by applying the triangle-fold calculation before the cursor has reached the limit the cursor is "wrapped" beyond the limit (considerably at some settings). Eg. at upper limit of 1, where a = 2 (symmetrical triangle), when the cursor reaches 0.999, the "wrap" calculation "wraps" the cursor to 1.001. I can't see how this is correct but given that this is in a published paper I'd guess that there's a good chance it's me who's wrong(?). 

In any case following reasoning above, I separated out the transition region from the actual transition like this, and that removed the pitch distortions and much of the noisiness:

    //cursor movement calcs
        if(*dir == 1){ //rising
            *p = (*p + (2 * a * t));
            if(*p > hi - a*t){ // TRANSITION REGION
                *out = (t_float) ptr_correctmax(*p, a, b, t, lo, hi);
                    if(*p > hi ){ // TRANSITION
                        *p = (hi + (*p - hi)*(b/a));
                        *dir = -1;
                        if(v < x->voice_count - 2){
                            *(dir+1) = 1;
                        }
                    }
            } else { // linear
                *out = (t_float) *p;
            }        
        } else { // counting down
            *p = *p + (2 * b * t);
            if(*p < lo - b*t){ // TRANSITION REGION
                *out = (t_float)ptr_correctmin(*p, a, b, t, lo, hi);
                if(*p < lo) { // TRANSITION
                    *p = (lo + (*p - lo)*(a/b));
                    *dir = 1;
                    if(v > 0){
                        *(dir-1) = -1;
                    }
                }
            } else { // linear
                *out = (t_float)*p;
            }
        }

// Correction functions for Polynomial Transition Region
t_double ptr_correctmax(t_double p, t_double a, t_double b, t_double t, t_double pmin, t_double pmax)
{
    t_double denom, atpmax, a2, a1, a0, out;

    denom = 2*t*a*a;
    atpmax = a*t-pmax;
    a2 = (b-a) /(2*denom);
    a1 = (a*t*(a+b)+(pmax*(a-b)))/ denom;
    a0 = (b-a)*(atpmax*atpmax)/ (2*denom);
    out = a2*p*p + a1*p + a0;

    //// very noisy unless limited. Why?!?
    //if (out > pmax){
    //    return pmax;    
    //} else if (out < pmin){
    //    return pmin;
    //} else {
    //    return out;
    //}
}

t_double ptr_correctmin(t_double p, t_double a, t_double b, t_double t, t_double pmin, t_double pmax)
{
    t_double denom, btpmin, b2, b1, b0, out;
    denom = 2*t*b*b;
    btpmin = b*t-pmin;
    b2 = (a-b) /(2*denom);
    b1 = (b*t*(a+b)+(pmin*(b-a)))/ denom;
    b0 = (a-b)*(btpmin*btpmin)/ (2*denom);    
    out = b2*p*p + b1*p + b0;

    //// very noisy unless limited. Why?!?
    //if (out > pmax){
    //    return pmax;    
    //} else if (out < pmin){
    //    return pmin;
    //} else {
    //    return out;
    //}

}

However, the PTR version of my calcs is still noisier than the naive triangle version. Any suggestions? I've gone over the code loads of times, but I just can't see the issue. I'm hoping a second set of eyes might see something I've missed - or that someone can explain why the "error" I describe above isn't actually an error because it all comes out in the calculations...?

You can see that I've got commented out code to limit the corrected values to within the range - uncommenting that reduces the noisiness further! So I'm sure my corrections are... incorrect. I just can't see how.

Note - these issues arise when I run with just 1 voice with upper and lower bounds set to (-1...1)- at that point this should be straightforward/"classical" EPTR. And if I switch off PTR the naive triangle works pretty sensibly.

I've been writing a few extensions of Peter Blasser's Bound and Bounce triangle synthesis method for Max. Currently I'm trying to apply EPTR to it, based on this paper:
http://home.mit.bme.hu/~bank/publist/smc13.pdf

My code is here:
https://github.com/DanBennettDev/db.bounce-/tree/PTR_Rewrite

I started out more or less following the code at the bottom of the paper exactly, but I think there's an error in there - just in terms of drawing the triangle wave. the code in the paper causes the naive triangle to change direction before it reaches its limit, which seems to cause pitch distortions, and by applying the triangle-fold calculation before the cursor has reached the limit the cursor is "wrapped" beyond the limit (considerably at some settings). Eg. at upper limit of 1, where a = 2 (symmetrical triangle), when the cursor reaches 0.999, the "wrap" calculation "wraps" the cursor to 1.001. I can't see how this is correct but given that this is in a published paper I'd guess that there's a good chance it's me who's wrong(?). [editors note - it is me who's wrong]

	//cursor movement calcs
		if(*dir == 1){ //rising
			*p = (*p + (2 * a * t));
			if(*p > hi - a*t){ // TRANSITION REGION
				*out = (t_float) ptr_correctmax(*p, a, b, t, lo, hi);
					if(*p > hi ){ // TRANSITION
						*p = (hi + (*p - hi)*(b/a));
						*dir = -1;
						if(v < x->voice_count - 2){
							*(dir+1) = 1;
						}
					}
			} else { // linear
				*out = (t_float) *p;
			}		
		} else { // counting down
			*p = *p + (2 * b * t);
			if(*p < lo - b*t){ // TRANSITION REGION
				*out = (t_float)ptr_correctmin(*p, a, b, t, lo, hi);
				if(*p < lo) { // TRANSITION
					*p = (lo + (*p - lo)*(a/b));
					*dir = 1;
					if(v > 0){
						*(dir-1) = -1;
					}
				}
			} else { // linear
				*out = (t_float)*p;
			}
		}

// Correction functions for Polynomial Transition Region
t_double ptr_correctmax(t_double p, t_double a, t_double b, t_double t, t_double pmin, t_double pmax)
{
	t_double denom, atpmax, a2, a1, a0, out;

	denom = 2*t*a*a;
	atpmax = a*t-pmax;
	a2 = (b-a) /(2*denom);
	a1 = (a*t*(a+b)+(pmax*(a-b)))/ denom;
	a0 = (b-a)*(atpmax*atpmax)/ (2*denom);
	out = a2*p*p + a1*p + a0;

	//// very noisy unless limited. Why?!?
	//if (out > pmax){
	//	return pmax;	
	//} else if (out < pmin){
	//	return pmin;
	//} else {
	//	return out;
	//}
}

t_double ptr_correctmin(t_double p, t_double a, t_double b, t_double t, t_double pmin, t_double pmax)
{
	t_double denom, btpmin, b2, b1, b0, out;
	denom = 2*t*b*b;
	btpmin = b*t-pmin;
	b2 = (a-b) /(2*denom);
	b1 = (b*t*(a+b)+(pmin*(b-a)))/ denom;
	b0 = (a-b)*(btpmin*btpmin)/ (2*denom);	
	out = b2*p*p + b1*p + b0;

	//// very noisy unless limited. Why?!?
	//if (out > pmax){
	//	return pmax;	
	//} else if (out < pmin){
	//	return pmin;
	//} else {
	//	return out;
	//}

}

help-my-eptr-implementation-is-noisier-than-a-naive-triangle

sorry Dan , i cant check it on my own at the moment (also it has to be updated for 64bit in order to let me open it in max).

From what i see ,the first implementation should give desired results . What i would change in calculation would be just a type 

 as a first guess . u are truncating data from 

sorry Dan , i cant check it on my own at the moment (also it has to be updated for 64bit in order to let me open it in max).
From what i see ,the first implementation should give desired results . What i would change in calculation would be just a type t_float to double as a first guess . u are truncating data from correction methods and at the output .


All calcs are already in t_double - I only truncate to float when I send back as audio signal (*out is a pointer to the signal out vector) since I'm working in 32 bit max at the mo'.

And the main issue seems to be that the corrections are considerably outside of the -1...1 region - far more than truncation error distances. My PTR seems to be actually sharpening the transitions rather than softening them - change in gradient over the transition is actually quite a bit higher with (my) ptr switched on!

Hence why hard limiting actually reduces the noisiness...

64bit - yeah bit of a PITA. I only have Max 5 at the mo (starting a course in oct, skint and waiting for the student discount before upgrading to 7), so I'm developing in 32 bit and then converting to 64 once I've got all working. It just makes it easier to keep track of issues only having 1 perform method etc.

Thanks for the quick response.
All calcs are already in t_double - I only truncate to float when I send back as audio signal (*out is a pointer to the signal out vector) since I'm working in 32 bit max at the mo'.
And the main issue seems to be that the corrections are considerably outside of the -1...1 region - far more than truncation error distances. My PTR seems to be actually sharpening the transitions rather than softening them - change in gradient over the transition is actually quite a bit higher with (my) ptr switched on!
Hence why hard limiting actually reduces the noisiness...

64bit - yeah bit of a PITA. I only have Max 5 at the mo (starting a course in oct, skint and waiting for the student discount before upgrading to 7), so I'm developing in 32 bit and then converting to 64 once I've got all working. It just makes it easier to keep track of issues only having 1 perform method etc.


So through the fiddling and fixing, I'd ended up commenting out the code in the correction functions that returns a value. So they're returning nonsense every transition. Hence being noisy.

ahem.
So through the fiddling and fixing, I'd ended up commenting out the code in the correction functions that returns a value. So they're returning nonsense every transition. Hence being noisy.

hah :) cheers both - I'm not beating myself up about it, just my sense of humour I guess.

Raja - cheers. EPTR is good and that paper does a very thorough job of explaining it. Once I actually read the paper through and started remembering bits of the calculus I've not thought about for however many years it slotted into place without too much pain (leaving aside the confusions above!). Works pretty well with this method too, so thanks for the tip off.

CLOSED - Help! My EPTR implementation is noisier than a naive triangle