Combining the delay/read interp and delay/write sdram!

[jaffasplaffa]

Hello

I have been experimenting with making a delay object, where I would like to combine the delay/read interp with the delay/write sdram. I managed to do it in 2 different ways, the patch goes live and it works... BUT........ The sound that comes out of the object sounds really bad. Sounds a bit the same way as if you feed an interpeted signal into a non interpeted table. Doesnt sound nice. So I am thinking it might be related to the interpetation going on. One object is interpeted(delay/read interp) and the other(delay/write sdram) is not interpeted..... and when combined it doesnt work well.

Would anyone know a solution for this issue? How to make the interpetation internally in the object?

Thanks!

Here is a patch with a couple of test versions:
Custom Delay FOR COMMUNITY 1.axp (13.1 KB)

@SirSickSik
In your repeater object I see you use the same approach with the delay/read X and the delay/write in the same object. I am wondering if you are using the non interp or the interp version on the delay? I cant figure that out. Thanks

[SirSickSik]

there are a couple of things you have to take care off:
-is the bitsize the same? both 16 or 32 bit?
-in the interpolated read you need to get rid of the buffertime being added to the writeposition (I think that's the one that's causing problems)
-remove all notions of attr_delayname and just let the names refer to names in the same object.

[jaffasplaffa]

-is the bitsize the same? both 16 or 32 bit?

Not sure.

-in the interpolated read you need to get rid of the buffertime being added to the writeposition (I think that's the one that's causing problems)

YES this was it. I removed the buffer part from the code and now it works. Thanks

-remove all notions of attr_delayname and just let the names refer to names in the same object.

Yes the first version on the picture I have removed the attr_delayname and call the name with writepos directly in the object...

Anyway, thank again @SirSickSik

[SirSickSik]

about the bitsize:
bitsize is set by the table.
For 16bit tables, the input needs to be shifted down in bits-> >>16
When reading out the table, you need to shift it up again by the same bits-> <<16
(though note that in the 16bit delay, the signal only gets shifted up/down by 14 as most of the signals are using only 28bit range, leaving you 2 bits of overhead.)

[jaffasplaffa]

For 16bit tables, the input needs to be shifted down in bits-> >>16
When reading out the table, you need to shift it up again by the same bits-> <<16
(though note that in the 16bit delay, the signal only gets shifted up/down by 14 as most of the signals are using only 28bit range, leaving you 2 bits of overhead.)

Thanks man. Well I am basically building a delay that I have all ready as a subpatch so I have something to compare to as I go along. And after I fixed the buffer issue it sounded as it was supposed to. So I am not sure there is anything to fix there. Still need to learn more about this bitshifting.

[SirSickSik]

<<1 is the same as multiplying by 2^1
<<2 is the same as multiplying by 2^2

those pointy thingies the other way with 1 is the same as dividing by 2^1
those pointy thingies the other way with 2 is the same as dividing by 2^2
(can't use these symbols in here it seems)

note though, that when shifting <<2, the largest two bits will be "lost" and the smallest two bits will be zero. When shifting the other way 3, the smallest three bits will be "lost" and the biggest three bits will be zero. This comes in useful every once in a while.