Interpolated delay

Discuss suspected defects before submitting a bug report

Moderator: electrogear

Interpolated delay

Postby Mo on Sun Jan 08, 2012 11:46 am

Aloha,

Compared to the toolbox delay, the toolbox interpolated delay seems not to be right.

I managed to fix it introducing stage3. I think the code should be:
Code: Select all
streamin in;
streamout out;
streamin delay;

float index;
float intdelay,frac;
float temp1,temp2;
float out1;

float mem[44100];
float MAXDELAY=44100;

stage(2)
{
   index=index+1;
   index=(index<MAXDELAY)&index;
}
stage(3)
{
   mem[index]=in;
   
   intdelay = delay - 0.499999;
   intdelay = rndint(intdelay);
   frac = delay - intdelay;

   temp1 = index - intdelay;
   temp2 = temp1 - 1;
   
   temp1 = temp1 + (temp1 < 0)&MAXDELAY;
   temp1 = mem[temp1];

   temp2 = temp2 + (temp2 < 0)&MAXDELAY;
   temp2 = mem[temp2];

   frac = (1 - frac)/(1 + frac);
   out =  temp2 + frac * (temp1 - out1);
   out1 = out;
}
User avatar
Mo
essemilian
 
Posts: 439
Joined: Thu Jan 24, 2008 2:00 pm
Location: Copenhagen

Re: Interpolated delay

Postby oddson on Sun Jan 08, 2012 6:06 pm

Doesn't it cause a problem with the delay length if you increment the index before it's used?

Is there a specific problem with the stock code? I wonder if it's related to the problem referenced in this thread:
viewtopic.php?f=12&t=9921
oddson
wiki guru
 
Posts: 3889
Joined: Sun Jul 03, 2005 6:44 pm

Re: Interpolated delay

Postby Mo on Sun Jan 08, 2012 7:12 pm

oddson wrote:Doesn't it cause a problem with the delay length if you increment the index before it's used?

That was the only way i could make it sound right. It seems not to cause problems. I was analyzing the delays in a bypass filter and found the stock interpolated delay sounding different compared to the normal stock delay. Same with optimized delays posted elsewhere on forum. I think it's not related to the other thread, but a missing stage 3.
User avatar
Mo
essemilian
 
Posts: 439
Joined: Thu Jan 24, 2008 2:00 pm
Location: Copenhagen

Re: Interpolated delay

Postby infuzion on Mon Jan 09, 2012 3:27 am

Shouldn't a interpolated delay sound difference, since it is um... interpolated?
IIRC, the new stage segments should have delays working in Stage(2) & (4), while most other DSP work in (3)?
I think we need to see your OSMs so we can also a/b. I know you're smart with DSP, but perhaps someone else has a different testing angle.
Need help? First search the forum & WiKi, then post in the help forum with a clear topic, request, & OSM. Then please WiKi the correct solution. If you want my personal assistance, I charge by the hour or for an exchange of services.
infuzion
smstar
smstar
 
Posts: 6169
Joined: Wed May 04, 2005 8:02 pm
Location: Earth, USA, CO, Denver

Re: Interpolated delay

Postby Mo on Mon Jan 09, 2012 9:22 am

infuzion wrote:Shouldn't a interpolated delay sound difference, since it is um... interpolated?

No, when no delay time modulation.

infuzion wrote:IIRC, the new stage segments should have delays working in Stage(2) & (4), while most other DSP work in (3)?

Stage(2) is default and not necessary. I think there's no stage(4).
Here's my test example. It's the bypass filter from freeverb with different delays; 1. Normal stock delay, 2. Fixed interpolated delay (sounds the same as 1.) and 3. stock interpolated delay (here the sound is wrong when listening closely to highhats in a drumloop for example, there's a ringing sound to it).
DelayTest.osm
(330.87 KiB) Downloaded 214 times
User avatar
Mo
essemilian
 
Posts: 439
Joined: Thu Jan 24, 2008 2:00 pm
Location: Copenhagen

Re: Interpolated delay

Postby aliasant on Mon Jan 09, 2012 11:03 am

Mo wrote:(here the sound is wrong when listening closely to highhats in a drumloop for example, there's a ringing sound to it).



I think your right.
At least yours sounds cleaner.
If this is confirmed perhaps we should fix all the different optimized versions out there?
It's never to late to be late.....
http://martinrodensjo.smugmug.com/
User avatar
aliasant
smunatic
 
Posts: 2388
Joined: Sat Dec 30, 2006 5:49 pm
Location: Sweden

Re: Interpolated delay

Postby Mo on Mon Jan 09, 2012 12:13 pm

aliasant wrote:If this is confirmed perhaps we should fix all the different optimized versions out there?

Indeed, all delays seems to need stage(3) outside the index increment.

Here's another way to do the same:
Code: Select all
streamin in;
streamout out;
streamin delay;
float index;
float intdelay,frac;
float temp1,temp2;
float out1;
float mem[44100];
float MAXDELAY=44100;

stage(2)
{
   mem[index]=in;
}
stage(3)
{
   intdelay = delay - 0.499999;
   intdelay = rndint(intdelay);
   frac = delay - intdelay;

   temp1 = index - intdelay;
   temp2 = temp1 - 1;
   
   temp1 = temp1 + (temp1 < 0)&MAXDELAY;
   temp1 = mem[temp1];

   temp2 = temp2 + (temp2 < 0)&MAXDELAY;
   temp2 = mem[temp2];

   frac = (1 - frac)/(1 + frac);
   out =  temp2 + frac * (temp1 - out1);
   out1 = out;
   
   index=index+1;
   index=(index<MAXDELAY)&index;
}
User avatar
Mo
essemilian
 
Posts: 439
Joined: Thu Jan 24, 2008 2:00 pm
Location: Copenhagen

Re: Interpolated delay

Postby stw on Mon Jan 09, 2012 10:53 pm

Ouch that's a big one! Good finding Mo!
It seems the wrong stage introduces aliasing. What scares me a is that even the asm versions without stage ordering are blured (as you already found out). I tested it with an optimized version from MyCo (which i unfortunately use in my current project) xP
To make it a bit more obvious for us naturalagedhicutfilterowners i mocked up another test osm.
The ringing can be heard best with a noise input. And it becomes visual obvious when feeded with a saw.

DelayTest2.osm
(621.89 KiB) Downloaded 188 times
stw
smanatic
 
Posts: 641
Joined: Mon Jun 30, 2008 2:55 pm

Re: Interpolated delay

Postby cyto on Tue Jan 10, 2012 3:27 am

This is only an issue when the delays are getting fed back into themselves (as in the AP architecture). The problem stems from the fact that the outputs are not getting updated before the inputs expect them, so an extra "unit delay" is introduced. If you were to use the interpolated delay straight (without any feedback), there wouldn't be as noticeable an effect. I think the "correct" way to deal with this is to update the outputs in stage 1, do all the "math" in stage 2, then update the inputs in stage 3...

Code: Select all
streamin in;
streamout out;
streamin delay;

float index;
float intdelay,frac;
float temp1,temp2;
float out1;

float mem[44100];
float MAXDELAY=44100;

stage(1)
{
   out =  temp2 + frac * (temp1 - out1);
   out1 = out;
}

stage(2)
{
   intdelay = delay - 0.499999;
   intdelay = rndint(intdelay);
   frac = delay - intdelay;

   temp1 = index - intdelay;
   temp2 = temp1 - 1;
   
   temp1 = temp1 + (temp1 < 0)&MAXDELAY;
   temp1 = mem[temp1];

   temp2 = temp2 + (temp2 < 0)&MAXDELAY;
   temp2 = mem[temp2];

   frac = (1 - frac)/(1 + frac);
   
   index=index+1;
   index=(index<MAXDELAY)&index;
}

stage(3)
{
   mem[index]=in;
}


-cyto
User avatar
cyto
essemilian
 
Posts: 317
Joined: Sun Nov 28, 2010 4:36 am
Location: CIN | OH | USA

Re: Interpolated delay

Postby stw on Wed Jan 11, 2012 3:28 pm

cyto wrote:This is only an issue when the delays are getting fed back into themselves (as in the AP architecture). The problem stems from the fact that the outputs are not getting updated before the inputs expect them, so an extra "unit delay" is introduced. If you were to use the interpolated delay straight (without any feedback), there wouldn't be as noticeable an effect. I think the "correct" way to deal with this is to update the outputs in stage 1, do all the "math" in stage 2, then update the inputs in stage 3...

-cyto

Although this sounds reasonable (theoretically) i'm still confused how to handle processing order with that. I just ran into trouble when optimizing my current project which includes some allpasses too. After hours of trial and error and just one moment before getting the phonebook to search for some local psychiatrist i found out that my code wasn't wrong at all.
I attached an example osm which contains an allpass with a fixed delay code. I marked the place where the signals are summed for feedback and output.
Just changing the link order of the group module (which simply adds the signals) by clicking on it let the feedback go out of control. So blewed up every attempt of me putting all calculations into one asm box.
I'm not sure if it's the order of stages or something else what corrupts the process. But I still couldn't find a workaround for that. I really would like to understand what's going on here...
Maybe someone can help?

DelayTest3osm.osm
(104.31 KiB) Downloaded 183 times
stw
smanatic
 
Posts: 641
Joined: Mon Jun 30, 2008 2:55 pm

Re: Interpolated delay

Postby cyto on Wed Jan 11, 2012 4:19 pm

stw wrote:I'm not sure if it's the order of stages or something else what corrupts the process. But I still couldn't find a workaround for that.

It appears that the real culprit here is the little "node" module. When you remove it and just connect directly to the subsequent points, the problem seems to go away (at least in my limited tests)...

nodeRem.png
nodeRem.png (30.52 KiB) Viewed 3315 times

I tried every combination of link order in the above scenario, and none of them cause that crazy ringing. I have no idea why this is the case, though. I suspect it has something to do with the way SM "tracks back" through the schematic, but I'm really not sure. :S

-cyto
User avatar
cyto
essemilian
 
Posts: 317
Joined: Sun Nov 28, 2010 4:36 am
Location: CIN | OH | USA

Re: Interpolated delay

Postby stw on Wed Jan 11, 2012 6:48 pm

cyto wrote:
stw wrote:I'm not sure if it's the order of stages or something else what corrupts the process. But I still couldn't find a workaround for that.

It appears that the real culprit here is the little "node" module.

Exactly! The summed connection seems to force another processing order than providing two (mathematical) equal outputs. And that's what happens if all is done in one coder block.
This is really disgusting because there's absolutely no way to predict that behaviour.

cyto wrote:I suspect it has something to do with the way SM "tracks back" through the schematic, but I'm really not sure. :S
-cyto

If so... why? Is it a bug or a feature?
stw
smanatic
 
Posts: 641
Joined: Mon Jun 30, 2008 2:55 pm

Re: Interpolated delay

Postby Tzarls on Wed Jan 11, 2012 7:20 pm

We had a topic about this same thing (processing order) here:

http://synthmaker.co.uk/forum/viewtopic.php?f=9&t=10547
Tzarls
smanatic
 
Posts: 770
Joined: Tue Nov 11, 2008 5:43 am
Location: Peru

Re: Interpolated delay

Postby cyto on Thu Jan 12, 2012 7:06 am

stw wrote:...and just one moment before getting the phonebook to search for some local psychiatrist

You're not kidding! I just spent the good part of the evening trying to get a "one code block" version of this thing going, and no matter what I tried, I couldn't make it work. Something is definitely screwy here :S Just as I was ready to throw in the towel, I decided to throw together a quick asm version, just to see if I ran into the same problems, and lo and behold it seems to work!!! So at least we have that option.

DelayTest4.osm
(161.51 KiB) Downloaded 232 times

stw wrote:If so... why? Is it a bug or a feature?

I think it is a little of both. Considering the sheer complexity of compiling the complex schematics that SM can, there are surely going to be oddities in the behavior. I worked with Synthedit years ago and I seem to remember that it only processed data in chunks of 4 (or was it 8?) samples at a time. One of the reasons I originally checked out SM was its ability to process sample by sample. That must be no easy feat. It seems like the staging system is supposed to be able to deal with these little oddities, but I am now convinced that it is not 100% there.

-cyto
User avatar
cyto
essemilian
 
Posts: 317
Joined: Sun Nov 28, 2010 4:36 am
Location: CIN | OH | USA

Re: Interpolated delay

Postby stw on Thu Jan 12, 2012 7:35 am

cyto wrote:Just as I was ready to throw in the towel, I decided to throw together a quick asm version, just to see if I ran into the same problems, and lo and behold it seems to work!!! So at least we have that option.


Great!! And a good code reduction too. Thanks for giving it a try!
I guess i failed and your code works because i had the packing in an extra asm block. But i can't verify that atm.
I'll try to put that solution into the interpolated version.
However when Tzarls posted the link to the other thread i remembered that. I never had a deeper look into that before but the discussion there makes perfectly sense.
At least that teaches me to give some extra caution and testing on these feedback things.
stw
smanatic
 
Posts: 641
Joined: Mon Jun 30, 2008 2:55 pm

Next

Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest