electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » Clavia Nord Modular » Nord Modular G2 Discussion
Clocksynced delays drifting out of sync!
Post new topic   Reply to topic Moderators: Nord Modular Editors
Page 1 of 1 [25 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
Tim Kleinert



Joined: Mar 12, 2004
Posts: 1148
Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236

PostPosted: Thu Jun 23, 2005 7:31 am    Post subject: Clocksynced delays drifting out of sync! Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
cebec



Joined: Apr 19, 2004
Posts: 1098
Location: Virginia
Audio files: 3
G2 patch files: 31

PostPosted: Thu Jun 23, 2005 7:40 am    Post subject: Reply with quote  Mark this post and the followings unread

Hi Tim,

Does this help?

http://electro-music.com/forum/topic-6262.html&highlight=clock+sync+drift

some good tips in there
Back to top
View user's profile Send private message
Unfed



Joined: May 11, 2004
Posts: 200
Location: Rochester, NY
Audio files: 4
G2 patch files: 11

PostPosted: Thu Jun 23, 2005 7:02 pm    Post subject: Reply with quote  Mark this post and the followings unread

i'm guessing there's no external midi sync invloved?
_________________
SoundCloud
Back to top
View user's profile Send private message
Tim Kleinert



Joined: Mar 12, 2004
Posts: 1148
Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236

PostPosted: Fri Jun 24, 2005 12:10 am    Post subject: Reply with quote  Mark this post and the followings unread

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.

Sad
Back to top
View user's profile Send private message
deknow



Joined: Sep 15, 2004
Posts: 1307
Location: Leominster, MA (USA)
G2 patch files: 15

PostPosted: Sat Jun 25, 2005 10:36 am    Post subject: Reply with quote  Mark this post and the followings unread

what is running off the "master clock" that is falling out of synch with the clocked delay?

deknow
Back to top
View user's profile Send private message Send e-mail
Tim Kleinert



Joined: Mar 12, 2004
Posts: 1148
Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236

PostPosted: Sat Jun 25, 2005 4:53 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
Afro88



Joined: Jun 20, 2004
Posts: 701
Location: Brisbane, Australia
Audio files: 12
G2 patch files: 79

PostPosted: Sat Jun 25, 2005 4:56 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
Tim Kleinert



Joined: Mar 12, 2004
Posts: 1148
Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236

PostPosted: Sat Jun 25, 2005 5:03 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
Afro88



Joined: Jun 20, 2004
Posts: 701
Location: Brisbane, Australia
Audio files: 12
G2 patch files: 79

PostPosted: Sat Jun 25, 2005 5:07 pm    Post subject: Reply with quote  Mark this post and the followings unread

Ahhh, sorry missed that post Embarassed

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
View user's profile Send private message Visit poster's website
cebec



Joined: Apr 19, 2004
Posts: 1098
Location: Virginia
Audio files: 3
G2 patch files: 31

PostPosted: Sun Jun 26, 2005 10:29 am    Post subject: Reply with quote  Mark this post and the followings unread

yeah, here's a link to rob's workshop on recirculators... in case some have not seen it or are interested.

http://www.xs4all.nl/~rhordijk/G2Pages/Loopers.htm
Back to top
View user's profile Send private message
Afro88



Joined: Jun 20, 2004
Posts: 701
Location: Brisbane, Australia
Audio files: 12
G2 patch files: 79

PostPosted: Sun Jun 26, 2005 7:13 pm    Post subject: Reply with quote  Mark this post and the followings unread

Afro88 wrote:
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...


Embarassed Sorry, I didn't get much sleep the other night, that statement is incorrect. The 1 sample delay is to ensure that for each sample rate clock tick only 1 sample passes through the delay line. So in theory it shouldn't delay the audio incorrectly at all. However, in practice it may be incorrectly delaying the audio...

I put together the most simple audio looping patch possible. The feedback path consists of only a mixer 1-1A, and only using the chain input. The looped audio still drifted out of sync with the master clock...

I also tested with 2 looping delays side by side capturing the same audio, but they remained locked in sync with each other (but as expected still drifted out of sync with the master clock).

I've included the 1st patch here so other people can see/hear for themselves. Simply hold down the capture button for a bar and then listen as the delay loop slowly drifts out of sync with the master clock every loop. Because the phase doesn't change during the loop, it must be an issue with the delay line module or the mixer module, not the master clock itself as I originally thought.


loop bug.pch2
 Description:
Example of the delay line looping bug Tim discovered

Download
 Filename:  loop bug.pch2
 Filesize:  1.49 KB
 Downloaded:  1256 Time(s)

Back to top
View user's profile Send private message Visit poster's website
mosc
Site Admin


Joined: Jan 31, 2003
Posts: 18197
Location: Durham, NC
Audio files: 212
G2 patch files: 60

PostPosted: Sun Jun 26, 2005 9:21 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail Visit poster's website AIM Address
Tim Kleinert



Joined: Mar 12, 2004
Posts: 1148
Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236

PostPosted: Mon Jun 27, 2005 1:02 am    Post subject: Reply with quote  Mark this post and the followings unread

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. Smile

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
View user's profile Send private message
Fozzie



Joined: Jun 04, 2004
Posts: 875
Location: Near Wageningen, the Netherlands
Audio files: 8
G2 patch files: 49

PostPosted: Fri Mar 17, 2006 2:40 pm    Post subject: Reply with quote  Mark this post and the followings unread

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.


SyncCheck_slotA.pch2
 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:  1125 Time(s)

Back to top
View user's profile Send private message
selvmarcus



Joined: Feb 08, 2006
Posts: 121
Location: Berlin, Germany
G2 patch files: 39

PostPosted: Sat Mar 18, 2006 8:28 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
Fozzie



Joined: Jun 04, 2004
Posts: 875
Location: Near Wageningen, the Netherlands
Audio files: 8
G2 patch files: 49

PostPosted: Sun Mar 19, 2006 6:22 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
3phase



Joined: Jul 27, 2004
Posts: 1183
Location: Berlin
Audio files: 13
G2 patch files: 141

PostPosted: Sun Mar 19, 2006 3:06 pm    Post subject: Reply with quote  Mark this post and the followings unread

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. Wink

Last edited by 3phase on Sun Mar 19, 2006 4:49 pm; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail Visit poster's website
selvmarcus



Joined: Feb 08, 2006
Posts: 121
Location: Berlin, Germany
G2 patch files: 39

PostPosted: Sun Mar 19, 2006 4:00 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
selvmarcus



Joined: Feb 08, 2006
Posts: 121
Location: Berlin, Germany
G2 patch files: 39

PostPosted: Mon Mar 20, 2006 2:28 pm    Post subject: Reply with quote  Mark this post and the followings unread

Not yet. Rolling Eyes

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
View user's profile Send private message Visit poster's website
dasz



Joined: Oct 16, 2004
Posts: 1644
Location: victoria, canada
Audio files: 29
G2 patch files: 56

PostPosted: Mon Mar 20, 2006 3:58 pm    Post subject:   Reply with quote  Mark this post and the followings unread

Exclamation Yikes, with this level of implementation needed for the workaround,
this is definitely a BUG not a bad implement Rolling Eyes.

it is not a "new"; I got too many of those Wink ...
/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 Confused ...
Back to top
View user's profile Send private message
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Mon Mar 20, 2006 4:29 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail Visit poster's website
selvmarcus



Joined: Feb 08, 2006
Posts: 121
Location: Berlin, Germany
G2 patch files: 39

PostPosted: Mon Mar 20, 2006 7:31 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Tue Mar 21, 2006 4:29 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail Visit poster's website
jksuperstar



Joined: Aug 20, 2004
Posts: 2503
Location: Denver
Audio files: 1
G2 patch files: 18

PostPosted: Sun Apr 02, 2006 2:54 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
Fozzie



Joined: Jun 04, 2004
Posts: 875
Location: Near Wageningen, the Netherlands
Audio files: 8
G2 patch files: 49

PostPosted: Sun Apr 02, 2006 3:53 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Moderators: Nord Modular Editors
Page 1 of 1 [25 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » Clavia Nord Modular » Nord Modular G2 Discussion
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use