SDK people:Question about digital ITB delays

Please remember the terms of your membership agreement.

Moderators: valis, garyb

Post Reply
User avatar
the19thbear
Posts: 1499
Joined: Thu Feb 20, 2003 4:00 pm
Location: Denmark
Contact:

SDK people:Question about digital ITB delays

Post by the19thbear »

Hey everyone.
From a programmer point of view, is there only one way to make a delay? I'm talking about a simple delay line here.. not about various additions like filters and modulation etc.

-I'm trying to find out if all digital ITB delays are made the same way, and therefore have the same sound.
If there are multiple ways of doing it, what are the different outcomes, soundwise?

Please explain stuff to me in a "down to earth" manner.. i'm by no means a programmer myself! - its a part of a bachelor paper i'm writing.
thanks alot:)
tgstgs
Posts: 526
Joined: Sun Jan 15, 2006 4:00 pm

Re: SDK people:Question about digital ITB delays

Post by tgstgs »

_

first a delay itself should never have any effect to the sound;

what you put in is what you get out_
_

talking about coding:

the difference is how you implement it;

basically you buffer the data;

thisfor you first need memory;
you can fix reserv an amount of bytes or you dynamicaly allocate it at runtime;

then you could make a FIFO first in first out or a FILO first in last out buffer;
a simple delayline would be a FIFO;
them both you may implement as shift or circle buffer;
and all of them you may address the data via index or pointeracrobatic;
---

there are a lot of ways to get the same result in sound;
the difference is the speed;
how much circles you need to perform
----

this is just a simplified short explanation;
there is a lot more like using recusive functions/multicorecoding/switch vs pointerfunction/
and so on . . .
it even makes a difference which types you use for your data;
if you use classes or not . . . . .

hope it helps
good vibes from vienna
User avatar
the19thbear
Posts: 1499
Joined: Thu Feb 20, 2003 4:00 pm
Location: Denmark
Contact:

Re: SDK people:Question about digital ITB delays

Post by the19thbear »

thanks alot! exactly what i thought. what comes in comes out.

Thanks for the explanation!
User avatar
the19thbear
Posts: 1499
Joined: Thu Feb 20, 2003 4:00 pm
Location: Denmark
Contact:

Re: SDK people:Question about digital ITB delays

Post by the19thbear »

So why do digital delays differ in sound?
the lexicon PCM 42 sounds different from ams delays that sounds different from xx--
I'm thinking that the quality of the converters/samplerate/bitrate of course will make a huge impact on the sound, but that is only after the DA. what about "inside" the digital realm? there are no things that change the sound of the delayed sound? (other than, as mentioned before, samplerate etc)

thanks!
tgstgs
Posts: 526
Joined: Sun Jan 15, 2006 4:00 pm

Re: SDK people:Question about digital ITB delays

Post by tgstgs »

you said without additions like filters and so!!

a delay is a delay is a delay____________
NO magic_

if you do not get out the SAME values as you put in there are additions built in__

thats it_

the most impact on sound for the people has the brand_
the second most its looking_

put in some white noise and measure the delays wet only output with an analyzer;
if its not white noise there are some filters in__

sorry but thats the truth_


good vibes
User avatar
erminardi
Posts: 1575
Joined: Fri Apr 30, 2004 4:00 pm

Re: SDK people:Question about digital ITB delays

Post by erminardi »

the main difference between hardware digital delays is the I/O DA/AD converter (if the path is EQ filters free).
for tape delays, obviously, the differences are pre/amp circuits and wich kind of tape/head are used.
4PC + Scope 5.0 + no more Xite + 2xScope Pro + 6xPulsarII + 2xLunaII + SDK + a lot of devices (Flexor III & Solaris 4.1 etc.) + Plugiator.
jksuperstar
Posts: 1638
Joined: Mon Nov 15, 2010 12:57 pm

Re: SDK people:Question about digital ITB delays

Post by jksuperstar »

There are different *TYPES* of delays though, and that will effect sound, just in the delay, not including filters or A/D/A.

The basic delay we think of runs on the same sample rate as the rest of the system. If you want a longer delay, you add more memory to the length of the delay. This is the "delay is a delay is a delay" (as long as the bit width is the same as your data; sometimes only 16bit memory is used with 24bit data and you loose some resolution (this happened in the Nord G2 delays)).

One other type is the Bucket Brigade Delay (BBD), which has a fixed length. If you want it to be longer in time, you slow the sample rate down. This introduces aliasing, since it's just like down-sampling. These are typically "analog" implementations, where 1 transistor stores an analog value, then passes that down to the next transistor, etc. But Sonic Core's Modular IV now has a BBD type delay in it. Not sure what the sample rate range is, but for know I just know it's there. They are used in analog modulars because it's so easy there to just modulate the clock/sample rate that is driving the BBD with a control voltage. Then you can drive it with a RAMP/SAW and get pitch shifting artifacts. Fun stuff.
User avatar
spacef
Posts: 3342
Joined: Sun Jun 17, 2001 4:00 pm
Contact:

Re: SDK people:Question about digital ITB delays

Post by spacef »

For hardware based digital delay, I'm with Erminardi. For various "TYPES" of delay jk is right (eventhough, in my view the process is the same: you always have a buffer where the sound is "stored" and sent back to the output with the delay that equals the buffersize: now is there many ways to change that buffer size? certainly)

But for hardware, all the components are important, even with the exact same sound source (the delay chip/circuit) (can answer "why all digital delays don't sound the same) .
Like in all hardware, the quality of every component is important... like a preamp, some of them use expensive or rare components that change the sound analogically, eventhough the source (the delayed /buffers) could be identical. some component change the sound a little bit like an equalizer (color), or gives more dynamic and clarity, or more dirtiness (look at all the digital models of famous preamps or delays... some of them get close to their models, eventhough i think it is not before we have computers that are at least (10/20/500) times more powerful than wowadays in all respect), fun and useful to have all this choice though, venthough an illusion to think you have the "same thing" because it is simply not te same thing....
It is the same process when you plug the same microphone into preamps of different quality, the sound can change in an unbeleivable way, the sound source is exactly the same.

A tape or an oilcan is a process inside those equipment. You cannot put tape of oil fluids in a computer software or inside a digital chip, it is not compatible in nature (obviously). You have to find another way, which is by using another component (codes/scripts/whetever).

It is much more than a question of algorythm and samplerate. Higher Samplerate better ??, in a sample per seconds point of view , yes obviously, but in the point of view of "better sound" this is still something to be proven, because when it comes to delays, a better sound can mean the exact opposite as a "transparent" sound. If it was not the case, noone would be speaking of the Roland Space Echo anymore, (which main features is in the way the sound degrades and delay is "wobbling", and certainly not because it is "transparent" or precise in any way. May be higher samplerates improve the bass frequncies of a computer based equalizations/filtering, that is true . But even more true, in 100% digital world (computers/dsps), you may have to model the sound of those different components.. but it is always a binary model, a replica made with other tools and workarounds, not a identical of what happens in such amp or transitor of such and such brand.

I haven't heard any "model" of Roland Space Echo or TelRays that can replace them 100%. It is all an illusion. All the technologies and programming code that would be needed are available and possible... In computers especially, eventhough the kind of programming on PC/MAC is also dependant on the CPU power or RAM (like samplerate/latency, etc) . i know some programmers that have done stuff that cannot be released now, because current CPU and RAM are simply not able to deal with the huge amount of codes needed to produce an output even @ 44.1 . They have to wait for a whole new generation of CPU to release those software (or simply, be able to finsih them). This can mean *never* as they don't have any control on what CPU makers do....

An idea for your paper: some professional manufacturers of preamps/compressors etc have hard time nowadays dealing with environmental laws and products that are forbidden to use due to potential environmental problems. That's an interesting aspect you could develop when talking about hardware (optical compressors for example: for some brands, it is not possible to build them with the same components as only 10 years ago, because those components are now illegal to make (or more exactly, forbidden to import in the EU or other countries with environmental laws that are actually enforced), as they contain specific banned chemicals, metals , or fluids, so manufacturers have to find another way, and sometimes it is not possible. result: a tiny component has changed, the sound has changed too... good or bad it is not the problem, it is simply not the same as the one 10 / 20 /30 years ago, eventhough the process or math has remained the same. i can give you an email if you PM me if you are interested about the effect of environmental laws on sound shaping, and if want to "interview" a famous preamp designer who had to deal with this problem... (i cannot guarantee any answer but he made articles about it so this is ready material, and possibly, valuable to talk a bit about it in your paper ;-)
Last edited by spacef on Thu May 19, 2011 3:24 pm, edited 10 times in total.
plug-ins for scope
SpaceF website
SC website
tgstgs
Posts: 526
Joined: Sun Jan 15, 2006 4:00 pm

Re: SDK people:Question about digital ITB delays

Post by tgstgs »

good luck with your work vibes
Warp69
Posts: 679
Joined: Sun Jun 17, 2001 4:00 pm
Location: Denmark
Contact:

Re: SDK people:Question about digital ITB delays

Post by Warp69 »

What do you mean by ITB and digital?

* ITB (In The Box) refers to the use of plugins inside a computer and you therefor can't compare with something like Lexicon PCM42 or AMS 1580.

* Regarding digital : Does that mean the signal is stored in a time discrete digital format or if it just time discrete? The BBD is actually not digital, since the signal is still stored as analogue, but it's time discrete so it has the Nyquist-Shannon limitations.

It's more or less impossible to answer your questions without knowing the definitions.
User avatar
the19thbear
Posts: 1499
Joined: Thu Feb 20, 2003 4:00 pm
Location: Denmark
Contact:

Re: SDK people:Question about digital ITB delays

Post by the19thbear »

I'm talking about digital itb. Plugin.
The PCM 42 has been modeled as a vst plugin :)
So I'm talking digitally stored. What does "time discrete" mean?
And I'm not talking about bbd. To me that is an analog delay controlled by a digital clock. (correct me if I'm wrong) feel free to explain more about the bbd chips though.
I know they can have up to 4000something steps - the more steps the more filtering/quality loss. And you can also delay the steps with the clocks. What is the differene? Sonically and technically.
(it's off topic I know:)

Thanks! :)
User avatar
the19thbear
Posts: 1499
Joined: Thu Feb 20, 2003 4:00 pm
Location: Denmark
Contact:

Re: SDK people:Question about digital ITB delays

Post by the19thbear »

@warp pmailed you
Warp69
Posts: 679
Joined: Sun Jun 17, 2001 4:00 pm
Location: Denmark
Contact:

Re: SDK people:Question about digital ITB delays

Post by Warp69 »

It's a difficult question, since I don't know the context.

The basic idea of a delay is to store a value in memory and load that exact same value from memory later on - this can be implemented in various ways, but the result will be the same.

Is that equal to every digital delay sounds the same? No.

It's like asking if every program on PC behave the same since they all use the exact same instruction set (x86).

I answered 'No' to the question above, but that doesn't mean that each delay plugin is different - I actually believe that most plugins (delays/eq's etc.) more or less sounds the same and the reason is not because it's all digital, but rather 'less experienced' dsp developers and/or 'time to market'.

In the plugin business it's more about quantity than quality. George Massenburg use multiple years to design a single digital compressor (not yet released) and Casey (Bricasti) use 3-4 years on a single reverb algorithm - this almost never happens in the plugin business even though it's very common in the hardware world. Most plugin developers feel they have used an incredible amount of developing time after just 1 month. The goal for the hardware designers of high-end gear is to create the new classic - for plugins developers : 'That doesn't look that hard, since I can download some sourcecode from the internet this weekend'.
User avatar
garyb
Moderator
Posts: 23380
Joined: Sun Apr 15, 2001 4:00 pm
Location: ghetto by the sea

Re: SDK people:Question about digital ITB delays

Post by garyb »

i am going to quote that.
Last edited by garyb on Thu May 26, 2011 11:57 pm, edited 1 time in total.
dawman
Posts: 14368
Joined: Sun Jul 24, 2005 4:00 pm
Location: PROJECT WINDOW

Re: SDK people:Question about digital ITB delays

Post by dawman »

BTW Martin,
I hate to keep reminding you as I haven't spoke to you for a while, but I have demo'd all of the Native stuff that forumites seem to get excited over, and still as far as a plug in Reverb, that is meant to recreate space, the Ambience Reverb you made is still the King of the block.

I use the PCM70 not because it is really accurate but the sound inside of the XITE-1 is my favorite coming out of powered midfield cabinets.
But that sound doesn't work as well as the Ambience-X when trying to emulate the sound of a Grand Piano being reflected by a large wooden stage.
Ambience is excellent as I have control over the damping of the sound, and perhaps its the additional damping control over the decay that really nails it. Whatever the reason, Ambience is the finest reverb I have used for this, even outdoing hardware I have used.

Peace.
User avatar
astroman
Posts: 8455
Joined: Fri Feb 08, 2002 4:00 pm
Location: Germany

Re: SDK people:Question about digital ITB delays

Post by astroman »

yeah, it IS pretty damn good, but I have to admit that recreating scenes from dry/wet snippets of Eventide 2016 samples was almost impossible for me (referring to the A100), the 2016 was slightly ahead in clearity while still retaining that 'warm' sound.
BUT... even though it may be the wrong location here....
it's native implementation in CSR is also pretty damn good :D
To be honest I like to throw that in for post processing quite often...

cheers, Tom
jksuperstar
Posts: 1638
Joined: Mon Nov 15, 2010 12:57 pm

Re: SDK people:Question about digital ITB delays

Post by jksuperstar »

the19thbear wrote:I'm talking about digital itb. Plugin.
The PCM 42 has been modeled as a vst plugin :)
So I'm talking digitally stored. What does "time discrete" mean?
And I'm not talking about bbd. To me that is an analog delay controlled by a digital clock. (correct me if I'm wrong) feel free to explain more about the bbd chips though.
I know they can have up to 4000something steps - the more steps the more filtering/quality loss. And you can also delay the steps with the clocks. What is the differene? Sonically and technically.
(it's off topic I know:)

Thanks! :)
Classic BBD delay is analog. However, it can be implemented ITB, giving its own color and effect during use. Instead of transistors passing voltage levels along, it's binary numbers getting passed along. So there won't be the signal loss like there is in analog. The buffer size does not change ever. Only the clock that drives how fast the samples get pushed through. With a slower clock, the quality of the delay (ability to recreate the input sound) diminishes as the delay time gets longer. This means more aliasing of the audio signal, since the time between each sample is increased. Quality gets better with shorter delay times (faster clock), and the sample rate goes up. This delay is subject to Shannon/Nyquist sample theories, and that is exactly why the quality changes with each delay time setting. For a digital implementation of a BBD, that is placed in a system that has a fixed sample rate such as 44.1 or 96, the BBD often has a rate adaptor on the input and output of the BBD. If the delay was very short, it's possible the sample rate of the BBD would be much higher than that of the system. Likewise, it could be much less than the system when the delay is very long. Because the fixed size, there is a minimum delay time also.

The analog versions where also some of the first examples of discrete time-domain (yet maintain analog voltage levels), so for a paper, I would think it is a very good example of the first implementations of nyquist's sampling theory applied before other things are considered, like quantization, truncation, and SNR/ENOB (effective number of bits) come into play.
Post Reply