TTDelay upgrades

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

TTDelay upgrades

Nathan Wolek-2
Tim (& anyone else who has an opinion on delays):

I started today by trying to make sure that TTDelay was using the methods from TTInterpolate (something I had made a note about). I then discovered some issues with clipping negative values, which was the same thing I observed in TTMatrix boundary testing.  This sort of snowballed into upgrading setLengthInSamples to support floats.  

BUT in the process of all that I discovered that interpolation REQUIRES a one sample delay in order to work properly.  When you get inside of one sample, the looking ahead that the ReadPointer does actually crosses the WritePointer.  

Should we prevent this?
Should I simply set the min on the TTClip to be one sample?
Right now, there are no errors when you are outside the range.  It just ignores the input.  Should it stay that way?

After you are done with your turkey day, I would appreciate you giving this a bit of thought.  Happy Thanksgiving!!!

--Nathan
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTDelay upgrades

Nathan Wolek-2
So here's an update on my TTDelay work last night and today:

1) I have solved the less than one sample issue, so fractional sample delays can now go all the way to near zero.  Before they were actually reading from the backside of the buffer because the read and write heads crossed.

2) After upgrading the delayInSamples to accept floats, the inspector in Max for the jcom.delay~ object does not update properly. If anybody has input on how to fix, I'd like some help.

3) In the process of fixing #1, I noticed that the linear and cosine interpolation modes output bad values.  Built several new tests and everything works as it should now.

4) I went to replace the cubic interpolation algorithm with the one from TTInterpolate and they seem to be completely different algorithms, but BOTH are simply called cubic.  Switching between them shows that they do vary in their results.  A web search shows a variety of techniques labelled as cubic.  We basically just need to decide: which one do we use?

So if anybody has work based on this object, it would be good to rebuild.  My tests showed that the old interpolation methods were off by a sample. Not much, but enough in some cases to make a difference.  

I am wondering if a sweep through similar processing units is in order (all pass, comb, etc)?

--Nathan


On Nov 22, 2012, at 3:38 PM, Nathan Wolek <[hidden email]> wrote:

> Tim (& anyone else who has an opinion on delays):
>
> I started today by trying to make sure that TTDelay was using the methods from TTInterpolate (something I had made a note about). I then discovered some issues with clipping negative values, which was the same thing I observed in TTMatrix boundary testing.  This sort of snowballed into upgrading setLengthInSamples to support floats.  
>
> BUT in the process of all that I discovered that interpolation REQUIRES a one sample delay in order to work properly.  When you get inside of one sample, the looking ahead that the ReadPointer does actually crosses the WritePointer.  
>
> Should we prevent this?
> Should I simply set the min on the TTClip to be one sample?
> Right now, there are no errors when you are outside the range.  It just ignores the input.  Should it stay that way?
>
> After you are done with your turkey day, I would appreciate you giving this a bit of thought.  Happy Thanksgiving!!!
>
> --Nathan

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTDelay upgrades

Nils Peters
Hi Nathan,

great work! thanks a lot for digging into the delay code!

On 2012-11-23 12:54 PM, Nathan Wolek wrote:
> 2) After upgrading the delayInSamples to accept floats, the inspector in Max for the jcom.delay~ object does not update properly. If anybody has input on how to fix, I'd like some help.

My guess it that you also have to change line 23 in TTDelay.h from

TTUInt64 mDelayInSamples;

to

TTFloat64 mDelayInSamples;

hope that helps.

cheers,

nils

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTDelay upgrades

Nathan Wolek-2
Thanks, Nils!

On Nov 23, 2012, at 11:11 PM, Nils Peters <[hidden email]> wrote:

My guess it that you also have to change line 23 in TTDelay.h from

TTUInt64 mDelayInSamples;

to

TTFloat64 mDelayInSamples;

This fixed the display issue for delayInSamples, but the inspector does not seem to keep both it and mDelay updating together.  I have made redmine issue #1252 with steps to reproduce.

Also did not see an answer to the cubic interpolation question.  That is now redmine task #1253.

--Nathan

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTDelay upgrades

Timothy Place-2
Ja.  Sorry to be slow...  I'm buried here for a few more days and this question requires me to actually think!

best,
  Tim


On Tue, Nov 27, 2012 at 6:36 AM, Nathan Wolek <[hidden email]> wrote:
Thanks, Nils!

On Nov 23, 2012, at 11:11 PM, Nils Peters <[hidden email]> wrote:

My guess it that you also have to change line 23 in TTDelay.h from

TTUInt64 mDelayInSamples;

to

TTFloat64 mDelayInSamples;

This fixed the display issue for delayInSamples, but the inspector does not seem to keep both it and mDelay updating together.  I have made redmine issue #1252 with steps to reproduce.

Also did not see an answer to the cubic interpolation question.  That is now redmine task #1253.

--Nathan

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel



------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTDelay upgrades

Nathan Wolek-2
On Nov 27, 2012, at 2:08 PM, Timothy Place <[hidden email]> wrote:
Ja.  Sorry to be slow...  I'm buried here for a few more days and this question requires me to actually think!

No worries.  I believe I tracked down your source…


So it's Miller Puckette v MusiGenesis.  Who will you choose?

Best.
--NW

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTDelay upgrades

Trond Lossius
Administrator
In reply to this post by Nathan Wolek-2
Hi,

On Nov 23, 2012, at 9:54 PM, Nathan Wolek <[hidden email]> wrote:

> 4) I went to replace the cubic interpolation algorithm with the one from TTInterpolate and they seem to be completely different algorithms, but BOTH are simply called cubic.  Switching between them shows that they do vary in their results.  A web search shows a variety of techniques labelled as cubic.  We basically just need to decide: which one do we use?

I have spent most of today investigating the code of the two cubic interpolation algorithms. In the process I've made a few unit tests for TTInterpolate in Foundation library. The tests have been added to master (and the tl-spatlib branch).

The two interpolation algorithms do indeed differ. The one in DSP Library seems fine, while I question the one provided in Foundation. Either it is intended to do something else, or there's a problem with it (e.g. an erroneous sign somewhere).

Cheers,
Trond
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTDelay upgrades

Trond Lossius
Administrator
Hi Nathan,

I believe I've now thoroughly investigated and solved this issue. I've added a detailed comment on it at Redmine:

http://redmine.jamoma.org/issues/1253

The interpolation algorithm in Foundation is still different from the one in DSP. It would probably be good to move the one that is currently in DSP tp TTInterpolate.h in Foundatio as an alternative cubic interpolator, but for the purpose of audio interpolation I would now expect the one in Foundation to sound the best.

Cheers,
Trond

On Nov 28, 2012, at 11:32 PM, Trond Lossius <[hidden email]> wrote:

> Hi,
>
> On Nov 23, 2012, at 9:54 PM, Nathan Wolek <[hidden email]> wrote:
>
>> 4) I went to replace the cubic interpolation algorithm with the one from TTInterpolate and they seem to be completely different algorithms, but BOTH are simply called cubic.  Switching between them shows that they do vary in their results.  A web search shows a variety of techniques labelled as cubic.  We basically just need to decide: which one do we use?
>
> I have spent most of today investigating the code of the two cubic interpolation algorithms. In the process I've made a few unit tests for TTInterpolate in Foundation library. The tests have been added to master (and the tl-spatlib branch).
>
> The two interpolation algorithms do indeed differ. The one in DSP Library seems fine, while I question the one provided in Foundation. Either it is intended to do something else, or there's a problem with it (e.g. an erroneous sign somewhere).
>
> Cheers,
> Trond
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> _______________________________________________
> Jamoma-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net/
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel