DSP Robotics Support

Here is a little demonstrator of a pitch preserving delay (the pitch does not change when the delay time D is varied). It consists of two delay lines which are constantly crossfaded. Each of the delay lines has a constant delay, D1 and D2, respectively, for the duration of one crossfade cycle. The values for D1 and D2 are sampled and held in an alternating manner from the control signal D. This is somewhat inefficient when D does not change (then one of the delay lines could be switched off). The whole schematic is not optimized.

nice one Martin, thanks a lot!

when using all mono 4 channels i need just one delay so there is no cpu increase on the delay itself and the s&h with the sine + the mix module is nearly nothing when optimized.. just tested this and sounds good , but little clicks on timechanging... will play around with fadetimes and see what works best with the different cases,

worked out a solution to slide between the delays in green, and with using all 4 channels to need just one delay, this version is working smooth - no clicks happening on timejumps... and slide happens only after a delaytime change

i´m using a de-threader to block triggers while changing the delay time when finished and delaytime is not changing any more the new time value will be sent to delay 2(while the update trigger for delay 1 is delayed) , slide from delay 1 to delay 2 starts when finished it returns to delay 1...

this solution is not suitable for permanent modulated delays, but there are no artefacts when changing delaytimes manually, also the delays and the slide (using dezipper) are not finetuned..

Keep in mind, that greens will not work well when rendering via DAW. Some DAWs will simply block timer activity or slow it down.

tester wrote:Keep in mind, that greens will not work well when rendering via DAW. Some DAWs will simply block timer activity or slow it down.

you could do it also in ruby or in stream, but i`m using the same "true when active" methode with the de-threader in all of my knobs to receive midi data and never got any troubles with it also i never got any troubles with triggerdelays, anyway it also wouldnt be bad when triggers or timers are slown down because its only about to delay the new delay time and slide between the 2 delays, this has not to be sampleaccurate, but yes it is not done for automating delaytime so it cant be a problem when rendering, simply because its not used then.

Nubeat7, I just realized that an integer delay will do, no need to use an interpolated one (my fault). If you want to optimize further, get Trog's tools, there is a ready to use fast delay in there (among many, many other cool things).

thanks martin, yes i`ve got trogs toolz and his delays are working fine with it..