hello all!

i would like to create a delay effect on my incoming signal (from my microphone) that, depending on the incoming signal's amplitude, the delay time would change (that is, if the volume is louder, the delay time will be longer, and if the volume is softer, the delay time will be shorter).

i scan my incoming signal (adc~) using fiddle~, a tool which i found using the search option in this forum. my problem is, that i dont know how to make the numeric amplitude information i get from fiddle~ useful for my plan. i use a delwrite~ and a vd~ to try and create this effect, but sometimes i get crackling sounds, and sometimes it just doesnt do what i want.

also, i would like the signal to delay only once, not many times in decreasing volume...

thanks so much for your help
ofer from israel

wow, using fiddle~ for this is like using a sledge-hammer to crack a nut.
you should take a look at the [env~] object, which outputs a db value following the inlet signal. you can convert this to a rms value between 0 and 1 with [dbtorms].

edit: but i think you will get problems when you try modulating the delaytime: if you smooth the time changes this will result in pitch shifting effects and if you don't, you will get crackling artefacts.

many thanks toxonic
but my main problem is not connected to gathering the db info of the signal. my main problem concerns the delay effect im trying to acheive. so even if i convert the db to rms using [env~] & [dbtorms] , i still have issues with the crackling of the delay, not to mention that i dont know how to delay the signal only once.

any help? or am i wrong, and using the [env~] would solve everything i mentioned above?

thanks alot
ofer

sorry, i posted an edit before i read your last post.
the only way i know to avoid the crackling is to smooth the delaytime changes via vline~ with a e.g. 20 ms time. but this will result in a pitch shifting effect.
to get only one repetition of the original should be simple:

[inlet~]
|
[s~ inlet]

[r~ inlet]
|
[delwrite~ whatever 2000]

[nbx\ <----delaytime numberbox
|
[vd~ whatever] [r~ inlet]
| |
[ +~ ]
|
[dac~]

great! thanks toxonic, the one time repeat works excellent

i am still frustrated with the fact that pd is kind of limited in this sense of crackling and pitch shifting when dealing with the delay time... here is a line in Supercollider that does the exact thing im looking for, but without any crackling or pitch shifting:

{ DelayN.ar(SoundIn.ar(0), 3, (Amplitude.ar(SoundIn.ar(0), 0.01,5)*8).poll )+SoundIn.ar(0).dup }.play;

why is it so simple in supercollider and so difficult to achieve in pd?

thanks
ofer

my bad, there IS pitch shifting in Supercollider when running that line...

but anyhow, that line has a MUCH smoother result than pd... why?

changing the delaytime smoothly will result in pitch shifting in every program i know. if you think about it, you will see, that there is no other way to read dynamic buffer and slide to another position in this buffer.
did you try to smooth out the delaytime with vline~?
something like:

[nbx\ <---delaytime
|
[$1 20( <--- transition time. play with it, to achieve other results
|
[vline~]
........

The reason why you're getting the crackling is because you are changing the delay time at message rate, which is not fast enough. The amount of time between messages results in sudden jumps that are heard as clicks. This is why toxonic is suggesting [vline~], and [line~] might work just fine as well. These objects output at audio rate, much faster than message objects, and can be used to make smooth ramps. It's not a limit in Pd.

And you'll notice in your Supercollider example that all of the objects end in .ar, meaning they, too, are running at audio rate.

thanks alot guys, i appreciate very much your help

i understand much more now about all this

i tried what you offered toxonic, and it worked very well (i also played with the transition time and tweaked with it until i found what i was looking for)

here is another issue:

when i do an [env~] to my signal, i get a very rapid read of dB. one of my mic inputs is between 20-25 when its "idle", that is, when a mic is connected and everything is on, but there is no sound going into the mic; and another mic input is around 54 during the same situation.
my question is, if i want to control the delay time in milliseconds, using this information, and i want the delay time to be dependent on the amplitude (dB) of the signal, what would you recommend to be the better mathematical process on it?

right now i am doing something that is not quite what im searching for... it more or less stays at the same delay time...

thanks for your help!
ofer

first you should convert it to rms with [dbtorms], since db is a logarithmic unit and this way useless for some applications. while 24 db is equal to an amplitude of ~0.0001778 and 54 db is also not much (something about ~0.004 rms) the most interesting for our ears happens in a range between 80 and 100 db (0.1 - 1 rms). with dbtorms you can convert this unit to rms scale.

@toxonic said:

...with dbtorms you can convert this unit to rms scale.

Maybe I'm being a bit nitpicky here, but it's probably good to understand that [dbtorms] is a bit of a misnomer, as it actually converts the logarithmic dB values to linear amplitude values. RMS values, which are sort of "averaged" perceived levels, are actually what [env~] outputs.

As for your delay times, shpeck, I think you should probably just consider what you want the minimum and maximum delays to be and scale those to roughly the range of your noise floor (those idle ranges from your mics) and the highest level coming in. Try it with both dB and linear (dbtorms) values and see which one you like. You could even make some curves in an array and map the levels to the indices. Experiment!

i did not know it in fact, although i thought something like this, since rms (root mean square) is a mean-value (somehow).... nevertheless, i could imagine, it might be more effective to use a linear scale.