[silly question] irregular delay

VST, AU, AAX, CLAP, etc. Plugin Virtual Effects Discussion
RELATED
PRODUCTS

Post

and let me know if you think of a good name :hihi:
you come and go, you come and go. amitabha neither a follower nor a leader be tagore "where roads are made i lose my way" where there is certainty, consideration is absent.

Post

Inspiration:
Echo loved Narcissus - although he didn't return the love. Pan loved Echo, but Echo didn't love Pan. It may be though that Pan and Echo did have a child called Lynx.

There must be a name in there somewhere.

Post

mixing boards look so innocent with the lights on :p
you come and go, you come and go. amitabha neither a follower nor a leader be tagore "where roads are made i lose my way" where there is certainty, consideration is absent.

Post

(unless i can devise a better name) amboea vst is going to have several modes.. parallel delay, serial delay, and a few algorithmic fading modes, eg. fading before and after the delay taps.

there are also half a dozen ways lfos can be applied, some will be omitted so it doesn't end up with a million possible operational modes. :)


a few questions:

to keep cpu low, i'm making some params block rate. it'd be 'awesome' if it did everything perfectly, but 16 filtered delay taps have a cpu overhead.. on my 1.6g processor i'm running ~1.9% for 8 stereo delay taps and ~2.6% with biquad filters, no algorithmic fade or lfo, which shouldn't be so much.

since this effect is intended as a mass of delay lines, i'm omitting 'adaptive processing,' which means that it won't do any extra work figuring how many taps are active..

i'm running delay time coeffs at block rate - this avoids interpolating (bicubic interpolation is 6 mults and 9 adds, times 16 delay lines per sample.. i may add a linear interp mode with lfo > time but it'll sound like a mess and use a bit more cpu..

filter cutoffs are also at block rate (again, maybe a mode for this will be included.. why not.. but it will have a cpu hit). i know you hadn't mentioned filters in the proposition. they do sound neat with my test source.

amp and gain are not at block rate.. panning is. again, there could be an lfo > panning mode.

my interpretation was that each stereo tap would be panned and filtered with static time and amp (or tap selection) faded algorithmically, and the feedback amounts would be modulated by lfo.

conceptually, one could imagine a bank of lfos being applied to panning, cutoff, amp, feedback, delay time, resonance simultaneously.. i'm going to limit it to one lfo mod target per mode :) it could be done with a modular environment..

if the above sounds like a travesty and you simply *must* have smooth panning modulation *and* cutoff modulation *and* the other stuff, you may need to mention it :) i like 2% as an effect load.. not much more.


other question: with resonant filters on delay paths (which i like) there is the issue of feedback gain. i'd prefer to avoid limiters bcs of colouration so the plan i'm going with now are 'overload lights' so you can identify which tap is feeding back (which would be a mess in schemes with 8 resonant filtered delay paths) - is this feasible for you, you'd prefer some coarse inline limiter?
you come and go, you come and go. amitabha neither a follower nor a leader be tagore "where roads are made i lose my way" where there is certainty, consideration is absent.

Post

of course, if you don't use resonance, there's no > unity gain, so it's not an automatic exploder dealie.
you come and go, you come and go. amitabha neither a follower nor a leader be tagore "where roads are made i lose my way" where there is certainty, consideration is absent.

Post

Amoeba sounds like it has a lot of pseudopodia... :shock: :)

Like how this seems to be shaping up... :D
Barry
If a billion people believe a stupid thing it is still a stupid thing

Post

Specs look good :-)

Will it have some sort of failsafe to prevent massive feedback ? I like how a lot of the Reaktor ensembles have randomizers, but never go completely nuts. The other extreme is Retro Delay which always seems on the edge of destroying either my monitors or my ears.

Post

short story, no. i prefer not to implement them unless i have to.. limiting either needs 2 IF statements, an IF and an abs(), or a nonlinearity, which involves a couple of multiplies at least.. and this would have to be performed on both channels for eight taps. and the cheaper the implementation, the crappier it will sound if it clips.

i like to think that in future incarnations, all coders are born as little imps that live inside computer chips and do all the sums manually, so if i'm making all this work on every sample that potentially never actually affects the signal, i'm in trouble :)


this is why i figured the lowest computational expense would be manual 'clipping' lights.. if it were a single band i'd use a limiter, but with eight bands, it's a hefty cpu increase. the graphic indicators only check the signal once every buffer window so there's only a few 10ths of a % of cpu expense. once per buffer checking would not be a good scheme for applying even 'preventative' clipping :)


without filter resonance, you'd have to feed it loud signals that reinforced on each echo.. it's only once filter res comes in that it goes loud in a couple of repeats. i could easily add an extra 'safety' mode where increasing resonance balances (lowers) the amplitude. i wouldn't make it default behaviour at all, but it could be an option for less predictable source material. or, the limiter of your choice could be used after the effect. or, there could be a gourmet cpu mode with limiting (in this case i'd use softlimiting between 1 and 2.f).

??
you come and go, you come and go. amitabha neither a follower nor a leader be tagore "where roads are made i lose my way" where there is certainty, consideration is absent.

Post

How about something like an automated panic button ? At a set level it would cut the sound - perhaps even gracefully degrade the volume ?

... Or as you suggest, I'll always just put a limiter in the chain :-)

Post

I usually just put a limiter in the chain..makes more sense, I think. :)
Barry
If a billion people believe a stupid thing it is still a stupid thing

Post

not that kind of limiter, and not that kind of chain :x

:hihi: actually, at about the time i wrote "??" i realised that the once-per-buffer check could switch with another process that had limiting in it.. which makes me lazy, and gives me a load more work to do, since conceivably, with refinement, it should be able to.. well, not graceful, but perhaps ambulatory recovery..
you come and go, you come and go. amitabha neither a follower nor a leader be tagore "where roads are made i lose my way" where there is certainty, consideration is absent.

Post

http://www.xoxos.net/temp/amboea1.mp3

if you like early severed heads, there's music in there somewhere.. (around the 2 min mark)

this is not the algorithmic part.. this is testing the 8 stereo multitaps algorithm with one tap selectable to route back to the input and occasionally editing the length of one delay during use, which looks like it has potential to generate interesting polyrhythmic music.

i added a limiting algo adding ~0.5% constantly which takes about 2 seconds to fade levels between limited and unlimited. it allows feedback, contours of sustained feedback are generally between -1 and +1.
you come and go, you come and go. amitabha neither a follower nor a leader be tagore "where roads are made i lose my way" where there is certainty, consideration is absent.

Post

Very interesting. It's exciting to see things moving so fast :-)

Post

xoxos wrote:
other question: with resonant filters on delay paths (which i like) there is the issue of feedback gain. i'd prefer to avoid limiters bcs of colouration so the plan i'm going with now are 'overload lights' so you can identify which tap is feeding back (which would be a mess in schemes with 8 resonant filtered delay paths) - is this feasible for you, you'd prefer some coarse inline limiter?
I also like resonant filters on delay paths (and bitcrushers/downsamplers btw :)) and I'm always put off by delays which can't do proper feedbacks buildups as I want them because restricted by a limiter.

Personally I'm fine without a limiter (wouldn't even need the overload lights), but if you put a limiter in, please make it possible to bypass.

@spirit:

That's exactly the reason I love Retro delay. Massive buildups possible :D
You have to be careful of course, but I can live with that.

Post

done.. i reached the point where an extra IF statement isn't going to make much difference to the cpu, the limiter is selectable.

with everything on, filters, limiting, the algorithmic fading, feedback modulation it uses about 100mHz of my 1.6gHz processor, which is more than i like to go. the lfo uses a 'random' contour (a smoothed 'noise' wavetable) with separate phase for each delay, phase positions determined by seed, so feedback for each tap varies independently but at the same 'rate'.

a few more algorithms to go, since the cpu is already high (it's still low for more elementary choices) i'll add a cheesy windowing pitch shifting mode.. that will probably go to 9-10% of my 1.6g processor :( but reverse playback is as cheap as forward. i'm intrigued by the fading on multitap delay, which should produce ~ 12 5 78, 2 4 67, 1 3 56 et c..
you come and go, you come and go. amitabha neither a follower nor a leader be tagore "where roads are made i lose my way" where there is certainty, consideration is absent.

Post Reply

Return to “Effects”