EchoLab - (closed) beta test - release candidate 1

Official support for: rs-met.com
RELATED
PRODUCTS

Post

Reflected wrote:It will be useful to remove the 10ms (and 0.0100 beats) limit.
so i guess, you are trying to use it for comb-filtering effects? for future developments, i actually have it on the agenda. the main reason for leaving it out was efficiency - i currently round the delay-time to the nearest integer number of samples - for delay-times that are somewhat large (large enough to make for seperately perceived sonic events for each delayed copy), the delaytime error does not really matter because the relative delaytime error will still be small in this case. but when we go down to delaytimes that are really small (entering the realm of comb-filtering), i would have to go with sub-sample precise delaytimes, which in turn calls for interpolated delaylines, making the whole process much more computationally expensive.

but at some stage, i probably want to include modulation capabilities anyway, so i'll have to implement interpolation anyway. i guess, i could make it optional per delayline, so we can still benefit from the efficient implementation when modulation (i.e. sub-sample precise delaytimes) is not really required. we'll see...
Last edited by Music Engineer on Sat Jul 24, 2010 9:28 am, edited 1 time in total.
My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post

Musical Gym wrote:I hope you feel better and heal well, Robin.
Jim
yes thanks. actually, i feel good but i must rest a bunch of days/weeks to let it all heal.

once completely recovered, i'll look into all that stuff....
My website: rs-met.com, My presences on: YouTube, GitHub, Facebook

Post

Robin from www.rs-met.com wrote:
Reflected wrote:It will be useful to remove the 10ms (and 0.0100 beats) limit.
so i guess, you are trying to use it for comb-filtering effects? for future developments, i actually have it on the agenda. the main reason for leaving it out was efficiency - i currently round the delay-time to the nearest integer number of samples - for delay-times that are somewhat large (large enough to make for seperately perceived sonic events for each delayed copy), the delaytime error does not really matter because the relative delaytime error will still be small in this case. but when we go down to delaytimes that are really small (entering the realm of comb-filtering), i would have to go with sub-sample precise delaytimes, which in turn calls for interpolated delaylines, making the whole process much more computationally expensive.

but at some stage, i probably want to include modulation capabilities anyway, so i'll have to implement interpolation anyway. i guess, i could make it optional per delayline, so we can still benefit from the efficient implementation when modulation (i.e. sub-sample precise delaytimes) is not really required. we'll see...
you got me :wink:

modulation will be awesome! :love:

is there a plan to make the parameters automation-able? (i guess since there are no tap limit, it could probably work like readelay/reaEQ, whenever you add new tap/band, new parameters will show up in the parameter list)

prefix "#:" = tap number

#: time
#: gain
#: feedback
#: pan
#: ping pong
#: mute
#: solo
#: F-input b#: BW
#: F-input b#: gain
#: F-input b#: freq
#: F-fb b#: BW
#: F-fb b#: gain
#: F-fb b#: freq
"treat others as you would like to be treated."

Post Reply

Return to “rs-met”