Author |
Message |
Tim Kleinert
Joined: Mar 12, 2004 Posts: 1148 Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236
|
Posted: Thu Jun 23, 2005 7:31 am Post subject:
Clocksynced delays drifting out of sync! |
|
|
I'm using clocksynced delaylines as a audio capturing loop machine that hooks up to the master clock....
...except that it doesn't work properly. The loops slowly drift out of phase after some time. I guess its a bug, but want to hear other opinions or experiences before I make my customary bugreport to Clavia.
Anyone? |
|
Back to top
|
|
|
cebec
Joined: Apr 19, 2004 Posts: 1098 Location: Virginia
Audio files: 3
G2 patch files: 31
|
|
Back to top
|
|
|
Unfed
Joined: May 11, 2004 Posts: 200 Location: Rochester, NY
Audio files: 4
G2 patch files: 11
|
Posted: Thu Jun 23, 2005 7:02 pm Post subject:
|
|
|
i'm guessing there's no external midi sync invloved? _________________ SoundCloud |
|
Back to top
|
|
|
Tim Kleinert
Joined: Mar 12, 2004 Posts: 1148 Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236
|
Posted: Fri Jun 24, 2005 12:10 am Post subject:
|
|
|
Thanks for the replies. But no, it hasn't got anything to do with external sync.
It's just that the delay line length in "Clk" mode seems to be a little bit off mark compared to the master clock, even if just a few samples. So when you use it as a clocksynced audio capture recirculator patch, the circling audio loop slowly drift out of phase with the rest of the clock-driven setup.
It's a phenomenon that takes a few minutes to be noticed. But still, it makes this kind of patch useless for live performance.
|
|
Back to top
|
|
|
deknow
Joined: Sep 15, 2004 Posts: 1307 Location: Leominster, MA (USA)
G2 patch files: 15
|
Posted: Sat Jun 25, 2005 10:36 am Post subject:
|
|
|
what is running off the "master clock" that is falling out of synch with the clocked delay?
deknow |
|
Back to top
|
|
|
Tim Kleinert
Joined: Mar 12, 2004 Posts: 1148 Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236
|
Posted: Sat Jun 25, 2005 4:53 pm Post subject:
|
|
|
No. It's simple. When you use the delaylines in "Clk" mode, the delayline length is computated relative to the master clock.
Now, if this computation isn't 100% precise, or the master clock BPM setting isn't an integer fractional of 96000 (the delayline sampling rate), that means that the delayline length is subtly, very subtly, out of whack.
This goes unnoticed in most applications.
But if you use the delayline as an audio recirculator, it results in the captured audio loop very slowly drifting out of phase with the clock after some time. |
|
Back to top
|
|
|
Afro88
Joined: Jun 20, 2004 Posts: 701 Location: Brisbane, Australia
Audio files: 12
G2 patch files: 79
|
Posted: Sat Jun 25, 2005 4:56 pm Post subject:
|
|
|
edit: sorry, long winded post
Have you tried testing the loop internally? Don't use external sync, and loop an internal G2 sequence and see if that drifts against the uncaptured internal sequence.
I think it might be that your external sequencer is drifting slightly, and because the audio is already captured it can't adjust to the slight changes in tempo... Even slightly modulating the delay time won't keep it in time because somewhere along the lines you'll get a glitch that puts it out of whack.
But I don't think that's the way the delay lines work anyway. I think if the clock changes less than a whole bpm value, the delay time won't change. It's only when the bpm changes more than a whole value that the G2 switches the delay times for the clock delay. I think this is to stop unwanted delay modulation effects with the delays. Last edited by Afro88 on Sat Jun 25, 2005 5:04 pm; edited 1 time in total |
|
Back to top
|
|
|
Tim Kleinert
Joined: Mar 12, 2004 Posts: 1148 Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236
|
Posted: Sat Jun 25, 2005 5:03 pm Post subject:
|
|
|
I'm not using any external clock signal. Everything is done internally.
I suspect the delayline length computation isn't perfect.
On the other hand, in a recirculator patch, the added modules also introduce delays, which add up over time. Maybe that is the real reason.
Don't know. Didn't Rob experiment with clocksynced audio capturing/looping? Maybe he knows what's going on. |
|
Back to top
|
|
|
Afro88
Joined: Jun 20, 2004 Posts: 701 Location: Brisbane, Australia
Audio files: 12
G2 patch files: 79
|
Posted: Sat Jun 25, 2005 5:07 pm Post subject:
|
|
|
Ahhh, sorry missed that post
That is really crap...
Maybe it is the other modules... In fact, the mixer acts as the 1 sample delay in a feedback loop patch. That would definitely add up over an extended period of time... |
|
Back to top
|
|
|
cebec
Joined: Apr 19, 2004 Posts: 1098 Location: Virginia
Audio files: 3
G2 patch files: 31
|
|
Back to top
|
|
|
Afro88
Joined: Jun 20, 2004 Posts: 701 Location: Brisbane, Australia
Audio files: 12
G2 patch files: 79
|
|
Back to top
|
|
|
mosc
Site Admin
Joined: Jan 31, 2003 Posts: 18198 Location: Durham, NC
Audio files: 213
G2 patch files: 60
|
Posted: Sun Jun 26, 2005 9:21 pm Post subject:
|
|
|
I've only been quickly skimming this topic. Should we move this topic in to the Bugs forum? _________________ --Howard
my music and other stuff |
|
Back to top
|
|
|
Tim Kleinert
Joined: Mar 12, 2004 Posts: 1148 Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236
|
Posted: Mon Jun 27, 2005 1:02 am Post subject:
|
|
|
mosc wrote: | I've only been quickly skimming this topic. Should we move this topic in to the Bugs forum? |
Well -I'm still hoping Rob will chime in with some revelatory information prooving us all wrong.
Anyway, maybe it's a bit unfair to call it a "bug". Making delaylines sync absolutely perfectly to an external time source is impossible without resetting the readout pointer, which would produce glitches in the audio. So, the digital calculation rounding errors -even if very small- will invariably add up over time, making it drift sooner or later. |
|
Back to top
|
|
|
Fozzie
Joined: Jun 04, 2004 Posts: 875 Location: Near Wageningen, the Netherlands
Audio files: 8
G2 patch files: 49
|
Posted: Fri Mar 17, 2006 2:40 pm Post subject:
|
|
|
With the current activity on muxing and longer delays at 48 and 24kHz, my interest in beatsynced looping in the G2 has been revived again. Sadly but unsurprisingly, the lack of 100% accurate tempo-sync is coming back up with this.
However, I noticed that on the tempi I checked (mostly in the 93-120 bpm range), the delayed signal is too fast (loop too short). So an extra delay module can compensate and provide better sync. Luckily, even when using a quad delay in 2.7s mode, a 5ms static delay can still be added.
I made a patch to check the sync. I noticed that the sync can be improved by manually setting the 5ms compensation delay, indicating that the beatsync programming of the delay modules is not optimized (Clavia, you listening?).
This version is with a regular (1x) delay, but can be applied to the 24kHz delay patches as well of course. Hope it's of value for more people.
Description: |
Test the synced delay settings for specific tempi, use in slot A. See patch comments for use. |
|
Download |
Filename: |
SyncCheck_slotA.pch2 |
Filesize: |
2.64 KB |
Downloaded: |
1127 Time(s) |
|
|
Back to top
|
|
|
selvmarcus
Joined: Feb 08, 2006 Posts: 121 Location: Berlin, Germany
G2 patch files: 39
|
Posted: Sat Mar 18, 2006 8:28 pm Post subject:
|
|
|
Tim:
No. It´s bug or bad implementation. It should always be possible to use an adaptive scheme, where you so
to say keep the remainder which would give you the imprecision now for the next clock event and then adjust
the delaytime (which means readout sampling rate in effect) accordingly.
To put it another way:
If you can delay it (actually perform the buffering etc.), you can also calculate at any point how long it actually
has been delayed, when you take into account all delay-time modulations that might have been occured.
I am thinking of a workaround:
I would like to stamp the beginning of the loop.
When it returns, I check, if it is early/late according to the
midi clock for the first bar.
In case, I turn down/up the delay time (use the next clock mode) for
a calculated (hopefully short) time span.
Next round, I check again.
Can you give a rough magnitude of the drift?
Like how many beats at what bpm in how many minutes?
For the stamp I would use one sample of maximum value 4*64, filter it out on ouput (or if re-recording), it´s not audible then,
like I did this in the inter-area multiplexer syncing (for more busses).
I did not play with the delays yet.
I want to use them for live-looping, too!
So I am well-motivated...
In case switching the delaytime/clockpartitioning on the fly is not feasible,
.... may be it would be possible to delay or advance the
incoming midiclock. Somehow.
Or doing the calculation all by hand, not going with delay in sync mode
Shouldn´t be too hard.
-----
Marcus
[/u] |
|
Back to top
|
|
|
Fozzie
Joined: Jun 04, 2004 Posts: 875 Location: Near Wageningen, the Netherlands
Audio files: 8
G2 patch files: 49
|
Posted: Sun Mar 19, 2006 6:22 am Post subject:
|
|
|
selvmarcus wrote: | I am thinking of a workaround:
I would like to stamp the beginning of the loop.
When it returns, I check, if it is early/late according to the
midi clock for the first bar.
In case, I turn down/up the delay time (use the next clock mode) for
a calculated (hopefully short) time span.
Next round, I check again.
Can you give a rough magnitude of the drift?
Like how many beats at what bpm in how many minutes?
For the stamp I would use one sample of maximum value 4*64, filter it out on ouput (or if re-recording), it´s not audible then,
like I did this in the inter-area multiplexer syncing (for more busses).
I did not play with the delays yet.
I want to use them for live-looping, too!
So I am well-motivated...
In case switching the delaytime/clockpartitioning on the fly is not feasible,
.... may be it would be possible to delay or advance the
incoming midiclock. Somehow.
Or doing the calculation all by hand, not going with delay in sync mode
Shouldn´t be too hard.
-----
Marcus
[/u] |
Regarding the workaround: possibly in a different way from what you are thinking of, but the patch posted above your post does exactly that. It measures the time difference between a looped delay (synced according to clavia) and 'live' master-clock timed loop, using a logic high signal as the timing signal.
In the ranges I checked, the loops need 0.1-1 ms extra delay depending on the specific tempo as well as (obviously) whether it is a lower-frequency delay (4x longer loop).
Or do I misunderstand your post in some way?
Edit: wait a minute, you mean some auto-adjusting scheme of doing the correct syncing business? Cool idea, but will it be implementable?
Edit2 (sorry): calculation by hand is probably not a good idea, since the delay times cannot be set very accurately, and BPM's can only be whole numbers |
|
Back to top
|
|
|
3phase
Joined: Jul 27, 2004 Posts: 1183 Location: Berlin
Audio files: 13
G2 patch files: 141
|
Posted: Sun Mar 19, 2006 3:06 pm Post subject:
|
|
|
mosc wrote: | I've only been quickly skimming this topic. Should we move this topic in to the Bugs forum? |
I think its a better place for a workaround discussion here...
But it might be good to report the bug additional to the bug forum..and Clavia..
The last update was a pure implementation of the mutator... I think the next one will be a bugfix..or they go straight for the version 2...maybe more likely...
Just marketingwise and for the economic aspect of programers resources its probably better for them to go for a big update and fix the little issues
by the side... I however dont expect a G2 update within the next weeks or month...
So if there is a work around for now i would enjoy it. Last edited by 3phase on Sun Mar 19, 2006 4:49 pm; edited 1 time in total |
|
Back to top
|
|
|
selvmarcus
Joined: Feb 08, 2006 Posts: 121 Location: Berlin, Germany
G2 patch files: 39
|
Posted: Sun Mar 19, 2006 4:00 pm Post subject:
|
|
|
I think I will post a workaround tomorrow.
Stamping the loop beginning (at MIDI clock of 1st bar) with a MAXVAL.
Next round:
Checking with MIDI clock.
Switching some 1ms extra delay/silence in, in case we are late
(either silence or from crossfading there if nessecary).
It wouldn´t be audible.
Cutting extra delay/audio out again, if we are early/not late next cycle/next 1st bar.
Adaptive scheme.
--------
Marcus |
|
Back to top
|
|
|
selvmarcus
Joined: Feb 08, 2006 Posts: 121 Location: Berlin, Germany
G2 patch files: 39
|
Posted: Mon Mar 20, 2006 2:28 pm Post subject:
|
|
|
Not yet.
My stamp might get eaten by the sync logic!
I also figured the delays are not resampling, like it would be the correct
solution. That would give fractional delay times, fine modulation
and no lost samples. So in this simple implementation they are skipping samples
when ext. clock is speeding up, probably by advancing the read pointer
(ouput), reading some more and throwing away.
When clock is later then expected, they will introduce some silence,
or something, maybe repeat last sample, probably at input of delay
(write pointer).
Modulating the delay with contents sounds really nasty on G2 compared
to analog delay or hardware digital, where the coarse delay time is determined by
numbers of sample in queue, but the fine by the sampling rate.
(You often had a switch for the range, and another pot for timex1-timex2,
which would lower the rate to a half).
I guess I wil put my stamp some amount away from the clock-tick, or analyze with my scope tool what is going on.
Luckily, here I only have to care for "almost" constant delay time.
----------
Marcus |
|
Back to top
|
|
|
dasz
Joined: Oct 16, 2004 Posts: 1644 Location: victoria, canada
Audio files: 29
G2 patch files: 56
|
Posted: Mon Mar 20, 2006 3:58 pm Post subject:
|
|
|
Yikes, with this level of implementation needed for the workaround,
this is definitely a BUG not a bad implement .
it is not a "new"; I got too many of those ...
/Dasz
ps.: I like simple workarounds, as they are easy to learn and use.
And they do not clutter the screen with multiple rows and cols
of modules just to fix a little thing. That makes the patch hard to read ... |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Mon Mar 20, 2006 4:29 pm Post subject:
|
|
|
Possible solution;
The compiler detects feedback loops anyway in it's optimisation so it KNOWS which delays are inside of a feedback loop. The length of (one of) the delays in such a loop could be reduced by one sample. Might result in issues with nested loops.
This thing is not a bug; as far as I can tell a delay told to have length of four beats will have a length of four beats. Processing one sample will take the duration of one sample; no more no less; it's a realtime system. All of this is perfectly correct and propper.
I think this is something that's a lot like a soft muting thing. The G2 is a very simple system to work with with it's graphical interface. There is a price for that in that at times you simply lack detailed controll. That's a good trade for many people.
You can have your cake and you can eat it but you can't have a home-baked one on a moment's notice without efford. _________________ Kassen |
|
Back to top
|
|
|
selvmarcus
Joined: Feb 08, 2006 Posts: 121 Location: Berlin, Germany
G2 patch files: 39
|
Posted: Mon Mar 20, 2006 7:31 pm Post subject:
|
|
|
Kassen wrote:
Quote: | This thing is not a bug; as far as I can tell a delay told to have length of four beats will have a length of four beats. Processing one sample will take the duration of one sample; no more no less; it's a realtime system. All of this is perfectly correct and propper.
|
One sample of delay would be 1/96k or about 0.01 ms.
Hm, that would add up, yes.
After 100 bars you would get 1ms.
After 500 bars you would maybe notice.
At 120 bpm this would be like 1000 seconds or roughly 20 minutes.
Hm, this would be too long for my patience anyways!
Uh, 20 minutes with the same loop? Only joking.
But I think we are dealing with a magnitude higher, like 0.1 or even 1 ms. Check out the patch by Fozzie for measuring this, above.
In my experiment it showed like 0.2ms difference for2 bars sync. I put in the proposed compensating delay with
setting of 0.18ms or 0.22ms, and it almost kept the measured difference (total) constant, which shows the delay-delay time
computer in the patch works. So it is actually too short, not too long.
I think this is a bug.
Another issue is that 4 beats cannnot be defined in exact number of samples, because it is supposed to
sync to external clock, too.
So without resampling for output (fractional delay-time), which is much more expensive DSP-wise, there will be
gaps sometimes, or missing samples.
And these glitches will add up, too. It´s inevitable when the loop is not saved once for all, like in a sampler, but all the time re-recorded
from the delay, like here.
This should not happen with the internal clock, though.
-------
Marcus |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Tue Mar 21, 2006 4:29 am Post subject:
|
|
|
Ah, ok, I thought it was the typical thing with the processing itself also taking a sample. That's a well known phenomenon that affects lots of systems.
Could also be a rounding error in the syncing pulses? perhaps the timing of those pulse always gets rounded to the next sample "click" no matter which one it's closest to? That would add up as well, especailly if we are talking about controll rate pulses. That shouldn't increase the average time between two pulses though. _________________ Kassen |
|
Back to top
|
|
|
jksuperstar
Joined: Aug 20, 2004 Posts: 2503 Location: Denver
Audio files: 1
G2 patch files: 18
|
Posted: Sun Apr 02, 2006 2:54 am Post subject:
|
|
|
Yes, I think it is a rounding issue during pre-calculation. The BPM is translated into a delay time, and must be rounded off somehow (to accomodate whole samples). That error however could be accumulated, so that with each calculation clock, that rounding error is summed, until it rolls into significant digits, at which point it's added to the delay length, and starts accumulating all over again. So for a static BPM, the delay would change a couple samples +/-, but over time would average out and always be in sync.
So, you either get exact loop points every time, or slightly varying dealy lengths. It's a compromise, so you loose something no matter which way it's done. I'd guess in "delay length" or "time" mode, it should keep the exact loop length. But should accumulate errors and change it's length for BPM mode, since the point of that mode is to sync to something else, not have a static delay length. |
|
Back to top
|
|
|
Fozzie
Joined: Jun 04, 2004 Posts: 875 Location: Near Wageningen, the Netherlands
Audio files: 8
G2 patch files: 49
|
Posted: Sun Apr 02, 2006 3:53 am Post subject:
|
|
|
jksuperstar wrote: | Yes, I think it is a rounding issue during pre-calculation. The BPM is translated into a delay time, and must be rounded off somehow (to accomodate whole samples). That error however could be accumulated, so that with each calculation clock, that rounding error is summed, until it rolls into significant digits, at which point it's added to the delay length, and starts accumulating all over again. So for a static BPM, the delay would change a couple samples +/-, but over time would average out and always be in sync.
So, you either get exact loop points every time, or slightly varying dealy lengths. It's a compromise, so you loose something no matter which way it's done. I'd guess in "delay length" or "time" mode, it should keep the exact loop length. But should accumulate errors and change it's length for BPM mode, since the point of that mode is to sync to something else, not have a static delay length. |
The situation can be made better by manually adding a static delay module (in 5ms mode will do fine), therefore there is more going on than just sample rounding. The syncing scheme is not as optimal as could be; possibly in making the internal table or whatever is used there are rounding errors too early upstream that make this happen. |
|
Back to top
|
|
|
|