Advanced Clock Delay
Advanced Clock Delay
a tempo based delay.
no further explanation, the rest is in the manual sheet.
- Attachments
-
- ACD-1.zip
- (539.44 KiB) Downloaded 808 times
Last edited by hifiboom on Sun Feb 17, 2008 4:25 pm, edited 1 time in total.
to answer your questions:
I didn`t base this device on the db-audioware thing,
but I`m realiszing that the outcome is almost the same.
thats worth a think, I guess you want an exact copy of that db-audioware thingy?you know what would make it even better?
a pan pot for each of the 2 delay lines
I didn`t base this device on the db-audioware thing,
but I`m realiszing that the outcome is almost the same.
maybe a bit, but on the other hand its nice on your eyes because the knobs have great separation also.doesnt it occupy way to much screenspace considering the controls involved?
hifiboom wrote:to answer your questions:
thats worth a think, I guess you want an exact copy of that db-audioware thingy?you know what would make it even better?
a pan pot for each of the 2 delay lines
I didn`t base this device on the db-audioware thing,
but I`m realiszing that the outcome is almost the same.
maybe a bit, but on the other hand its nice on your eyes because the knobs have great separation also.doesnt it occupy way to much screenspace considering the controls involved?
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
-
- Posts: 1544
- Joined: Fri Apr 13, 2001 4:00 pm
- Location: the Netherlands
- Contact:
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.
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, 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.
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.
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 IMOAnd 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.
edit: re: cross feedback: not to emulate any specific device, just cos it's plain FUN!
more has been done with less
https://soundcloud.com/at0m-studio
https://soundcloud.com/at0m-studio
@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.
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.
-
- Posts: 1544
- Joined: Fri Apr 13, 2001 4:00 pm
- Location: the Netherlands
- Contact:
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
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
hehehe , the vibes would def. change... thats for sure.tgstgs wrote: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
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.
Last edited by hifiboom on Tue Feb 19, 2008 2:24 pm, edited 1 time in total.
I may add that pan pots in the future, its no big thing.King of Snake wrote: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.
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.
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.MCCY wrote: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
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.
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
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
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
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