Here's an odd thing -- I'll post the code if anyone is curious, but at the
moment it's in a sketch I'm working on, and I've added some stuff that makes
the phenomenon harder to hear. Briefly, I created a step sequencer to play a
bunch of pitches (using table) in a continuously sounding instrument. Each
time a metro went to 1, a new value for the pitch was read. At the same
time, the speed of the metro was altered, using a value from another table.
In other words, this is a step sequencer with variable-length steps.

In order to articulate the sound, I created a simple attack/decay envelope
using reinit, timout, and rireturn. The value for the timout waiting time
was derived directly from the current speed of the metro, so that each time
a new pitch was chosen, a new envelope would also be initiated.

What I found was that after a couple of minutes, the envelope was starting
to drift out of sync. It was gradually falling behind the metro.

I solved the problem (or at least I seem to have solved it…) by subtracting
the value of ksmps/sr from timout's wait time. What seems to be happening is
that even though I would expect the reinit/timout loop to be executing
instantly, within the current k-cycle, it seems to occupy an entire k-cycle
by itself, in some manner or other, so that the metro gradually gets ahead
of it. Or something like that.

If this makes no sense, I'll strip the code down and post it. Of course,
you'll have to listen to a silly pitch sequence for several minutes before
the effect becomes audible….



--
View this message in context: http://csound.1045644.n5.nabble.com/reinit-metro-sync-tp5732443.html
Sent from the Csound - General mailing list archive at Nabble.com.

Sounds interesting (to figure out the problem too), so please do post some code.


2014-02-08 8:00 GMT+01:00 Jim Aikin :
> Here's an odd thing -- I'll post the code if anyone is curious, but at the
> moment it's in a sketch I'm working on, and I've added some stuff that makes
> the phenomenon harder to hear. Briefly, I created a step sequencer to play a
> bunch of pitches (using table) in a continuously sounding instrument. Each
> time a metro went to 1, a new value for the pitch was read. At the same
> time, the speed of the metro was altered, using a value from another table.
> In other words, this is a step sequencer with variable-length steps.
>
> In order to articulate the sound, I created a simple attack/decay envelope
> using reinit, timout, and rireturn. The value for the timout waiting time
> was derived directly from the current speed of the metro, so that each time
> a new pitch was chosen, a new envelope would also be initiated.
>
> What I found was that after a couple of minutes, the envelope was starting
> to drift out of sync. It was gradually falling behind the metro.
>
> I solved the problem (or at least I seem to have solved it...) by subtracting
> the value of ksmps/sr from timout's wait time. What seems to be happening is
> that even though I would expect the reinit/timout loop to be executing
> instantly, within the current k-cycle, it seems to occupy an entire k-cycle
> by itself, in some manner or other, so that the metro gradually gets ahead
> of it. Or something like that.
>
> If this makes no sense, I'll strip the code down and post it. Of course,
> you'll have to listen to a silly pitch sequence for several minutes before
> the effect becomes audible....
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/reinit-metro-sync-tp5732443.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>             https://sourceforge.net/p/csound/tickets/
> csound5:
>             https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

for me it would be interesting to read the code.
best -
	joachim


Am 08.02.2014 08:00, schrieb Jim Aikin:
> Here's an odd thing -- I'll post the code if anyone is curious, but at the
> moment it's in a sketch I'm working on, and I've added some stuff that makes
> the phenomenon harder to hear. Briefly, I created a step sequencer to play a
> bunch of pitches (using table) in a continuously sounding instrument. Each
> time a metro went to 1, a new value for the pitch was read. At the same
> time, the speed of the metro was altered, using a value from another table.
> In other words, this is a step sequencer with variable-length steps.
>
> In order to articulate the sound, I created a simple attack/decay envelope
> using reinit, timout, and rireturn. The value for the timout waiting time
> was derived directly from the current speed of the metro, so that each time
> a new pitch was chosen, a new envelope would also be initiated.
>
> What I found was that after a couple of minutes, the envelope was starting
> to drift out of sync. It was gradually falling behind the metro.
>
> I solved the problem (or at least I seem to have solved it…) by subtracting
> the value of ksmps/sr from timout's wait time. What seems to be happening is
> that even though I would expect the reinit/timout loop to be executing
> instantly, within the current k-cycle, it seems to occupy an entire k-cycle
> by itself, in some manner or other, so that the metro gradually gets ahead
> of it. Or something like that.
>
> If this makes no sense, I'll strip the code down and post it. Of course,
> you'll have to listen to a silly pitch sequence for several minutes before
> the effect becomes audible….
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/reinit-metro-sync-tp5732443.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>              https://sourceforge.net/p/csound/tickets/
> csound5:
>              https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>

> Sounds interesting (to figure out the problem too), so please do post some
code. 

Here's a simple test file that reveals the problem. If you render this to
disk (highly recommended, as you wouldn't want to listen to it) and inspect
it in an audio editor, what you'll find is that at the end of 5 minutes, the
envelope has lagged behind the metro by slightly more than 6,000 samples.
The pulses are occurring twice per second, which means 600 pulses in 5
minutes, so we're losing 10 samples (one k-cycle) per pulse, just as I
suspected.

If you set ksmps=1, the loss of sync at the end of 5 minutes is only 600
samples. And if you remove the semicolon, restoring the "- ksmps/sr" offset
for iwait, and go back to ksmps=10, the envelope at the end of five minutes
is actually about ten samples _ahead_ of the metro -- most likely a trivial
difference in any musical sense, but interesting.






sr = 44100
ksmps = 10
nchnls = 2
0dbfs = 1

instr 1

iRate = 2
kTrig		metro	iRate
aMetro	upsamp	kTrig

newenv:
	iwait	=	1/iRate ; - ksmps/sr
	timout	0, iwait, contin
	reinit	newenv
contin:
	aEnv	linseg	1, 0.005, 0, 1, 0
rireturn
		outs		aMetro, aEnv
endin



i 1 0 300






--
View this message in context: http://csound.1045644.n5.nabble.com/reinit-metro-sync-tp5732443p5732455.html
Sent from the Csound - General mailing list archive at Nabble.com.

yes, I think your diagnostic is right.  When the period in which reinit is scheduled to happen comes, the reinit takes place
and computation starts again in the next period. That means a k-period skip in relation to metro.
This is my impression without examining the source code.

Victor 


On 8 Feb 2014, at 17:18, Jim Aikin  wrote:

>> Sounds interesting (to figure out the problem too), so please do post some
> code. 
> 
> Here's a simple test file that reveals the problem. If you render this to
> disk (highly recommended, as you wouldn't want to listen to it) and inspect
> it in an audio editor, what you'll find is that at the end of 5 minutes, the
> envelope has lagged behind the metro by slightly more than 6,000 samples.
> The pulses are occurring twice per second, which means 600 pulses in 5
> minutes, so we're losing 10 samples (one k-cycle) per pulse, just as I
> suspected.
> 
> If you set ksmps=1, the loss of sync at the end of 5 minutes is only 600
> samples. And if you remove the semicolon, restoring the "- ksmps/sr" offset
> for iwait, and go back to ksmps=10, the envelope at the end of five minutes
> is actually about ten samples _ahead_ of the metro -- most likely a trivial
> difference in any musical sense, but interesting.
> 
> 
> 
> 
> 
> 
> sr = 44100
> ksmps = 10
> nchnls = 2
> 0dbfs = 1
> 
> instr 1
> 
> iRate = 2
> kTrig		metro	iRate
> aMetro	upsamp	kTrig
> 
> newenv:
> 	iwait	=	1/iRate ; - ksmps/sr
> 	timout	0, iwait, contin
> 	reinit	newenv
> contin:
> 	aEnv	linseg	1, 0.005, 0, 1, 0
> rireturn
> 		outs		aMetro, aEnv
> endin
> 
> 
> 
> i 1 0 300
> 
> 
> 
> 
> 
> 
> --
> View this message in context: http://csound.1045644.n5.nabble.com/reinit-metro-sync-tp5732443p5732455.html
> Sent from the Csound - General mailing list archive at Nabble.com.
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>            https://sourceforge.net/p/csound/tickets/
> csound5:
>            https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

That is an interesting detail to know about how things are processed.
Then, to keep things in sync without having to worry about it, why not
let the metro trigger the reinit?
Using two clocks (both a metro and a timout) for something that should
synchronize over a longish time spans feels uncomfortable (i.e.
unsafe-ish) to me. But it is nice to shed light on the issue, as it
sure looks as if it would sync.


2014-02-08 18:44 GMT+01:00 Victor Lazzarini :
> yes, I think your diagnostic is right.  When the period in which reinit is scheduled to happen comes, the reinit takes place
> and computation starts again in the next period. That means a k-period skip in relation to metro.
> This is my impression without examining the source code.
>
> Victor
>
>
> On 8 Feb 2014, at 17:18, Jim Aikin  wrote:
>
>>> Sounds interesting (to figure out the problem too), so please do post some
>> code.
>>
>> Here's a simple test file that reveals the problem. If you render this to
>> disk (highly recommended, as you wouldn't want to listen to it) and inspect
>> it in an audio editor, what you'll find is that at the end of 5 minutes, the
>> envelope has lagged behind the metro by slightly more than 6,000 samples.
>> The pulses are occurring twice per second, which means 600 pulses in 5
>> minutes, so we're losing 10 samples (one k-cycle) per pulse, just as I
>> suspected.
>>
>> If you set ksmps=1, the loss of sync at the end of 5 minutes is only 600
>> samples. And if you remove the semicolon, restoring the "- ksmps/sr" offset
>> for iwait, and go back to ksmps=10, the envelope at the end of five minutes
>> is actually about ten samples _ahead_ of the metro -- most likely a trivial
>> difference in any musical sense, but interesting.
>>
>> 
>> 
>> 
>> 
>>
>> sr = 44100
>> ksmps = 10
>> nchnls = 2
>> 0dbfs = 1
>>
>> instr 1
>>
>> iRate = 2
>> kTrig         metro   iRate
>> aMetro        upsamp  kTrig
>>
>> newenv:
>>       iwait   =       1/iRate ; - ksmps/sr
>>       timout  0, iwait, contin
>>       reinit  newenv
>> contin:
>>       aEnv    linseg  1, 0.005, 0, 1, 0
>> rireturn
>>               outs            aMetro, aEnv
>> endin
>>
>> 
>> 
>> i 1 0 300
>> 
>> 
>>
>>
>>
>>
>> --
>> View this message in context: http://csound.1045644.n5.nabble.com/reinit-metro-sync-tp5732443p5732455.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>> Send bugs reports to the Sourceforge bug trackers
>> csound6:
>>            https://sourceforge.net/p/csound/tickets/
>> csound5:
>>            https://sourceforge.net/p/csound/bugs/
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>             https://sourceforge.net/p/csound/tickets/
> csound5:
>             https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp