Advanced Clock Delay

[hifiboom]

a tempo based delay.

no further explanation, the rest is in the manual sheet.

[hifiboom]

to answer your questions:

you know what would make it even better?

a pan pot for each of the 2 delay lines

thats worth a think, I guess you want an exact copy of that db-audioware thingy?

I didn`t base this device on the db-audioware thing,
but I`m realiszing that the outcome is almost the same.

doesnt it occupy way to much screenspace considering the controls involved?

maybe a bit, but on the other hand its nice on your eyes because the knobs have great separation also.

[next to nothing]

love it.

[jdieks]

to answer your questions:

you know what would make it even better?

a pan pot for each of the 2 delay lines

thats worth a think, I guess you want an exact copy of that db-audioware thingy?

I didn`t base this device on the db-audioware thing,
but I`m realiszing that the outcome is almost the same.

doesnt it occupy way to much screenspace considering the controls involved?

maybe a bit, but on the other hand its nice on your eyes because the knobs have great separation also.

nah.. you don't have to make an exact copy... a few extra are good also

thanks for the device man... really what i needed

[King of Snake]

interface looks nice
In what way does this differ from something like say the stock creamware dual delay though?

[hifiboom]

to be precise:

i really like all cw stock devices, and especially the delay, as it is one of the greatest and most used fx.

(1) you have to know I work at the lowest ulli setting and I realized that the cw long delay (Delay LS) didn`t have a perfect timing at the lowest ulli setting. On the other hand it works fine at the highest ulli setting.
I guess its a lttle bug, they have overseen, as all other delays work fine at all ulli settings.
I have to say that I have forgot to check out the dual delay. Maybe it does not suffer from this problem.

that was the main purpose why i build it.

(2) it does allow you to dial in stuff like 3/4 or 5/3 etc.

(3) finally: most cw delays seem to start eqing the wet delay feedback after the first reflection. At least thats what my ears tell me.
Meaning DRY, 1 reflection -> 2 reflection (EQed) -> 3 ..... -> and so on....
My delays filter also the first reflection delay, which results in a slightly more layed back effect. so the first slapback doesn`t stand out that much in a mix.


Thats it, roughly.

But the biggest point for me to build this one was an exact bpm tempo timing at different ullis.
But maybe this problem also is system based. So I will be glad to get some feedback from you if you have tight bpm syncing at your different setups.

[hubird]

it will be my 'stock' delay!
thanks, in particular for the extended time values, tho number three is also smart and recognisable for me
good thinking!

[hifiboom]

hubird, thats fine.

btw as the manual says, the ulli and sample rate settings are not saved via presets.

I thought it would be pretty annoying if you switch through the presets and always have to setup the ulli and SR again. So you set it once after loading and then you are fine.

For sure the ULLI and SR will save within a complete project.

I even tried to read out the system handler for ULLI and SR, but failed because I did not find working atoms for proper access. That would need the help of soniccore.
And for sure this would be the ultimate solution, as changing the SR and ulli on a project wouldn`t affect the timing of the delay. Thats how its done with all cw delay stuff.
These little things are where I come to the limits of my free sdk license.

But this isn`t a show stopper at all, because we all know that most people here work at 44,1 and I`m pretty sure nobody is switching his ULLI setting on a per-day-basis.

[tgstgs]

'These little things are where I come to the limits of my free sdk license'

NO limit of license for this task!
where would be the fun of developing if all is given with a ready to use atom?

good vibes

[at0m]

And for sure this would be the ultimate solution, as changing the SR and ulli on a project wouldn`t affect the timing of the delay. Thats how its done with all cw delay stuff.

For Adern stuff, red_muze puts a user-setting on the module/device, I'm sure you've encountered it, it's a workaround for the ULLI detection mechanism. This latency is subtracted from the set delay time, to make the user delay time setting equal to real delay time of the module. That option's pretty easy to embed IMO

edit: re: cross feedback: not to emulate any specific device, just cos it's plain FUN!

[hifiboom]

@atom:
don`t know what you are talking about, but the Flexor stuff does not read out ulli via global system setting from what I know. You have to set it up manually also via text fader.
I guess the same approach like in my device.

@tgstgs, enlighten me brother and don`t speak in crypts...

you know I`m far away from being an atom recycle hore.

[King of Snake]

btw as mentioned earlier, pan pots for each delay line would be cool (maybe with a little lfo to get some really swirling stuff )
And the interface could be a bit smaller.

[tgstgs]

would one periode of a 1kHz good vibes sending have the same number of samples at all SRs?

------
in fact there are a lot of ways for realize_.
. . think simple for low dspusuage!
-------

i like the gui btw.

good vibes from vienna

[MCCY]

B.T.W. Hifiboom, thanks for reforcing my energy to the ULLI - topic with your brilliant implementation of ULLI adjustment. Under the PlanetZ surface there was some discussion going on, but I was too lazy to go further in it. Infact until some weeks ago I never used other ULLI than 25, so there was no need for me to go into it.

Have you experimented with syncing via midi? Maybe my fine-tuning page on LOOPlay gives an idea how I worked around that jumping-values-problematic, but it's not a pro-solution at all so far.

Interpolating Tempo adjustment would be another cool idea, so you could have realtime tempo moves...

Thanks for your great devcices!

Martin

[hifiboom]

would one periode of a 1kHz good vibes sending have the same number of samples at all SRs?

------
in fact there are a lot of ways for realize_.
. . think simple for low dspusuage!
-------

i like the gui btw.

good vibes from vienna

hehehe , the vibes would def. change... thats for sure.

But that does adress the SR. not the ulli, and apart from that its not the best way to get the system variables by "measuring" them. Think about dsp load.

[hifiboom]

btw as mentioned earlier, pan pots for each delay line would be cool (maybe with a little lfo to get some really swirling stuff )
And the interface could be a bit smaller.

I may add that pan pots in the future, its no big thing.

But don`t expect a surface redesign, I spend almost too much time on that area and to bring it too the point, I`m happy with the look.

[hifiboom]

B.T.W. Hifiboom, thanks for reforcing my energy to the ULLI - topic with your brilliant implementation of ULLI adjustment. Under the PlanetZ surface there was some discussion going on, but I was too lazy to go further in it. Infact until some weeks ago I never used other ULLI than 25, so there was no need for me to go into it.

Have you experimented with syncing via midi? Maybe my fine-tuning page on LOOPlay gives an idea how I worked around that jumping-values-problematic, but it's not a pro-solution at all so far.

Interpolating Tempo adjustment would be another cool idea, so you could have realtime tempo moves...

Thanks for your great devcices!

Martin

Martin, you can read out the midi bpm via an midi-input, but I didn`t want to blow this tool up with too much stuff.

I tought about this feature, but I`m a workflow guy, who doesn`t like too much clicks.(which means I am lazy under normal situations)
To use the midi you would have needed to load the ACD-1-device in the routing window and not inside an insert slot.(because midi in doesn`t connect inside a stm mixer). Thats at least 8 more clicks to use it(connecting 2 x audio ins and outs). I found it to be easier to setup the midi tempo manually.

-----
Apart from that you need to round up the midi bpm a bit else it will run all the time between up and down->leads to unperfect timings.
Afraid of also blowing up dsp consumption, I let this feature out and kept my tool clean.

In a earlier version, I even had some sort of swicthable phasing effect inside the feedback chain, which sounded nice in some situations but not in all. So I decided to take it out. (btw thats why the surface is a bit "empty", there was extra control at first)

I have my own idea what a device has to look like:
My design rules for a device are:
(1) It should have as less controls as possible to do what is espected for.
(2) it should have as much control to give enough flexibility
(3) the clicks to reach a "musical goal" should be reduced to a minimum
(4) all controls should be ranged in that way, that they never lead to unpleasing results.
(5) DSP consumption should be minimized without affecting the other paradigmas

why?
as an enduser I don`t want to search for a good sounding combination of too many knobs. This is where the dsp-developer should put his brain-power. Which elements should be linked under surface and which should be available via front end gui?

to answer your question: my device is not meant to be used on tracks where the bpms change through the track - btw I hardly needed such a feature ever.

hope this clear thigs up a bit.

[tgstgs]

well

should i steel you all the fun for my fun of talkin

--------
i send you good vibes through lets see WHEN you recive it;

edit for your edit:
the only way to be sure in whatever task is to do your own measurement;
want to belive -> go to church
want to develope -> measure
---
.

[hifiboom]

I disagree here tgstgs,
a variable like the ulli settings is a technical thing, that cannot be faked, its stored somewhere inside the sfp and sdk environment. Its a global parameter and it makes absolutly no sense to "measure" it at cost of dsp power.

the rest is simple maths and you cannot fake the system bus nor a system buffer setting.

but I`ll send you
good vibes back

[tgstgs]

so you belive, go to church and cry for support course your limited. .
may sc bless you . . .
-------
if such global parameters were so unfakeable i wouldnt earn a lot of money in my mainjob;
this is measurable too -> in spending a lot of it;

and you never find the ones who set these variables wrong btw.
it must be THE bad byte bug bitin out the bits . .
often seen in fullmoon dark nights;

scary vibes from vienna