John, you are probably thinking the reinit is a kpass. It is actually an 
additional ipass and takes no ktime. This would explain why you think it 
is one kpass off. Try it again imagining that the reinit pass takes *no 
time* and tell us how it works.

Iain

John Mayrose wrote:
> I have been having a problem with timing on the reinit opcode especially 
> when using it with other instruments (I have a midi pulsing marimba in 
> conjunction with other instruments that are pulsing).  It appears that 
> it runs a fraction slower, which over time is disasterous.  I can't 
> figure out for the life of me how to compensate for it, or what exactly 
> causes it.  I imagine it has something to do with skipping a couple of 
> samples or differences between the sr and kr.  I created a dummy file to 
> test it with two "identical instruments" - one running regularly, the 
> other using reinit, and did find a difference between the two of roughly 
> 10 samples per second (difference between kr and sr, but setting them to 
> the same value doesn't seem to help).   Compensating for it reverses the 
> issue .  Has anyone else dealt with this issue?  Any ideas?  The .orc 
> and .sco for the test file is below.  
> 
> Thanks,
> 
> John
> 
> 
> ;reinit test .orc
> 
> sr = 44100
> kr = 4410
> ksmps = 10
> nchnls = 2
> 
> instr 1
> aindex phasor 1
> a1 table aindex * 44100, 10
> aL = a1 * 32000 
> aR = 0
> outs aL, aR
> endin
> 
> instr 2
> ipulse = 1
> reset:
> timout 0, 1/ipulse, continue
> reinit reset
> continue:
> aindex phasor 1
> asound table aindex * 44100, 10
> aL = 0
> aR = asound * 32000 
> outs aL, aR
> endin
> 
> instr 3
> ipulse = 1 + 10/44100
> reset:
> timout 0, 1/ipulse, continue 
> reinit reset
> continue:
> aindex phasor 1
> asound table aindex * 44100, 10
> aR = asound * 32000 
> aL = 0
> outs aL, aR
> endin
> 
> ;end .orc
> 
> ;reinit test score
> 
> f1 0 8192 10 1
> f10 0 65536 2 1  0
> 
> 
> i1 0 200
> i2 0 200
> ;i3 0 200
> 
> e

I would try using krate counters and event instead of timout. That way 
you know they can't get out of sync with each other as a kpass is always 
the same in any instrument. It is also easier to debug that kind of 
thing by printing where you are in time based on your krate counter 
variables.

Iain

John Mayrose wrote:
> Thanks Iain and Aidan,
> 
> I am still have the same problems.  The effect is really cool, but not 
> what I am after.
> 
> The project I am working on is too large to deal with here, but I have 
> pulsing additive synthesis with pulsing wave guide modelers (which need 
> to be reinitialized to sound) with random pitches.  The sound is really 
> great, but the two instruments get out of phase pretty quickly.  I am 
> not completely unhappy with the effect, but I am frustrated that I can't 
> get it in sync.
> 
> I had been thinking of reinit as an ipass that takes no time, but lags 
> behind.  Is there something else about the timout/reinit combination 
> that I am missing?  Could it be my machine?  My version of Csound?  I am 
> on a mac with the latest MacCsound.  It happens on earlier versions, too.   
> 
> With a pulse at 8 beats per second, it takes around 93 seconds for the 
> two to line up again.
> I keep making these test .orcs hoping to have some solution.  I think I 
> am losing my mind, but it might be from hearing sine tones go in and out 
> of phase.
> 
> Here is my latest simple version:
> 
> ;orc
> 
> nchnls = 2
> 
> instr 1
> 
> iamp = 20000
> ipulse = 4
> 
> icps = cpspch (8.00)
> 
> kenvindex phasor ipulse
> kenv tablei kenvindex * ftlen (20), 20
> 
> a1 oscili iamp * kenv, icps, 1
> 
> aL = a1
> aR = 0
> 
> outs aL, aR
> 
> endin
> 
> instr 2
> 
> iamp = 20000
> ipulse = 4
> icps = cpspch (8.00)
> 
> reset:
> 
> timout 0, 1/ipulse, continue
> reinit reset
> 
> continue:
> 
> kenvindex phasor ipulse
> kenv tablei kenvindex * ftlen (20), 20
> 
> a2 pluck iamp, icps, icps, 0, 1
> a1 oscili iamp * kenv, icps, 1
> 
> aL = 0
> aR = a1 ;  * .5 + a2 * .5
> 
> outs aL, aR
> 
> endin
> 
> 
> ;sco
> 
> f1 0 8192 10 1
> f20 0 2048 7 0 46 1 400 0
> 
> i1 0 300
> i2 0 300
> 
> 
> 
> On Nov 17, 2005, at 11:25 PM, Iain Duncan wrote:
> 
>> John, you are probably thinking the reinit is a kpass. It is actually 
>> an additional ipass and takes no ktime. This would explain why you 
>> think it is one kpass off. Try it again imagining that the reinit pass 
>> takes *no time* and tell us how it works.
>>
>> Iain
>>
>> John Mayrose wrote:
>>
>>> I have been having a problem with timing on the reinit opcode 
>>> especially when using it with other instruments (I have a midi 
>>> pulsing marimba in conjunction with other instruments that are 
>>> pulsing).  It appears that it runs a fraction slower, which over time 
>>> is disasterous.  I can't figure out for the life of me how to 
>>> compensate for it, or what exactly causes it.  I imagine it has 
>>> something to do with skipping a couple of samples or differences 
>>> between the sr and kr.  I created a dummy file to test it with two 
>>> "identical instruments" - one running regularly, the other using 
>>> reinit, and did find a difference between the two of roughly 10 
>>> samples per second (difference between kr and sr, but setting them to 
>>> the same value doesn't seem to help).   Compensating for it reverses 
>>> the issue .  Has anyone else dealt with this issue?  Any ideas?  The 
>>> .orc and .sco for the test file is below.  Thanks,
>>> John
>>> ;reinit test .orc
>>> sr = 44100
>>> kr = 4410
>>> ksmps = 10
>>> nchnls = 2
>>> instr 1
>>> aindex phasor 1
>>> a1 table aindex * 44100, 10
>>> aL = a1 * 32000 aR = 0
>>> outs aL, aR
>>> endin
>>> instr 2
>>> ipulse = 1
>>> reset:
>>> timout 0, 1/ipulse, continue
>>> reinit reset
>>> continue:
>>> aindex phasor 1
>>> asound table aindex * 44100, 10
>>> aL = 0
>>> aR = asound * 32000 outs aL, aR
>>> endin
>>> instr 3
>>> ipulse = 1 + 10/44100
>>> reset:
>>> timout 0, 1/ipulse, continue reinit reset
>>> continue:
>>> aindex phasor 1
>>> asound table aindex * 44100, 10
>>> aR = asound * 32000 aL = 0
>>> outs aL, aR
>>> endin
>>> ;end .orc
>>> ;reinit test score
>>> f1 0 8192 10 1
>>> f10 0 65536 2 1  0
>>> i1 0 200
>>> i2 0 200
>>> ;i3 0 200
>>> e
>>
>> -- 
>> Send bugs reports to this list.
>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk 
>> 
> 
> 

Fantastic!  Thanks so much.

That works wonderfully and opens up new doors for possibilities!

John


On Nov 18, 2005, at 2:59 AM, Iain Duncan wrote:

> I would try using krate counters and event instead of timout. That  
> way you know they can't get out of sync with each other as a kpass  
> is always the same in any instrument. It is also easier to debug  
> that kind of thing by printing where you are in time based on your  
> krate counter variables.
>
> Iain
>
> John Mayrose wrote:
>> Thanks Iain and Aidan,
>> I am still have the same problems.  The effect is really cool, but  
>> not what I am after.
>> The project I am working on is too large to deal with here, but I  
>> have pulsing additive synthesis with pulsing wave guide modelers  
>> (which need to be reinitialized to sound) with random pitches.   
>> The sound is really great, but the two instruments get out of  
>> phase pretty quickly.  I am not completely unhappy with the  
>> effect, but I am frustrated that I can't get it in sync.
>> I had been thinking of reinit as an ipass that takes no time, but  
>> lags behind.  Is there something else about the timout/reinit  
>> combination that I am missing?  Could it be my machine?  My  
>> version of Csound?  I am on a mac with the latest MacCsound.  It  
>> happens on earlier versions, too.   With a pulse at 8 beats per  
>> second, it takes around 93 seconds for the two to line up again.
>> I keep making these test .orcs hoping to have some solution.  I  
>> think I am losing my mind, but it might be from hearing sine tones  
>> go in and out of phase.
>> Here is my latest simple version:
>> ;orc
>> nchnls = 2
>> instr 1
>> iamp = 20000
>> ipulse = 4
>> icps = cpspch (8.00)
>> kenvindex phasor ipulse
>> kenv tablei kenvindex * ftlen (20), 20
>> a1 oscili iamp * kenv, icps, 1
>> aL = a1
>> aR = 0
>> outs aL, aR
>> endin
>> instr 2
>> iamp = 20000
>> ipulse = 4
>> icps = cpspch (8.00)
>> reset:
>> timout 0, 1/ipulse, continue
>> reinit reset
>> continue:
>> kenvindex phasor ipulse
>> kenv tablei kenvindex * ftlen (20), 20
>> a2 pluck iamp, icps, icps, 0, 1
>> a1 oscili iamp * kenv, icps, 1
>> aL = 0
>> aR = a1 ;  * .5 + a2 * .5
>> outs aL, aR
>> endin
>> ;sco
>> f1 0 8192 10 1
>> f20 0 2048 7 0 46 1 400 0
>> i1 0 300
>> i2 0 300
>> On Nov 17, 2005, at 11:25 PM, Iain Duncan wrote:
>>> John, you are probably thinking the reinit is a kpass. It is  
>>> actually an additional ipass and takes no ktime. This would  
>>> explain why you think it is one kpass off. Try it again imagining  
>>> that the reinit pass takes *no time* and tell us how it works.
>>>
>>> Iain
>>>
>>> John Mayrose wrote:
>>>
>>>> I have been having a problem with timing on the reinit opcode  
>>>> especially when using it with other instruments (I have a midi  
>>>> pulsing marimba in conjunction with other instruments that are  
>>>> pulsing).  It appears that it runs a fraction slower, which over  
>>>> time is disasterous.  I can't figure out for the life of me how  
>>>> to compensate for it, or what exactly causes it.  I imagine it  
>>>> has something to do with skipping a couple of samples or  
>>>> differences between the sr and kr.  I created a dummy file to  
>>>> test it with two "identical instruments" - one running  
>>>> regularly, the other using reinit, and did find a difference  
>>>> between the two of roughly 10 samples per second (difference  
>>>> between kr and sr, but setting them to the same value doesn't  
>>>> seem to help).   Compensating for it reverses the issue .  Has  
>>>> anyone else dealt with this issue?  Any ideas?  The .orc  
>>>> and .sco for the test file is below.  Thanks,
>>>> John
>>>> ;reinit test .orc
>>>> sr = 44100
>>>> kr = 4410
>>>> ksmps = 10
>>>> nchnls = 2
>>>> instr 1
>>>> aindex phasor 1
>>>> a1 table aindex * 44100, 10
>>>> aL = a1 * 32000 aR = 0
>>>> outs aL, aR
>>>> endin
>>>> instr 2
>>>> ipulse = 1
>>>> reset:
>>>> timout 0, 1/ipulse, continue
>>>> reinit reset
>>>> continue:
>>>> aindex phasor 1
>>>> asound table aindex * 44100, 10
>>>> aL = 0
>>>> aR = asound * 32000 outs aL, aR
>>>> endin
>>>> instr 3
>>>> ipulse = 1 + 10/44100
>>>> reset:
>>>> timout 0, 1/ipulse, continue reinit reset
>>>> continue:
>>>> aindex phasor 1
>>>> asound table aindex * 44100, 10
>>>> aR = asound * 32000 aL = 0
>>>> outs aL, aR
>>>> endin
>>>> ;end .orc
>>>> ;reinit test score
>>>> f1 0 8192 10 1
>>>> f10 0 65536 2 1  0
>>>> i1 0 200
>>>> i2 0 200
>>>> ;i3 0 200
>>>> e
>>>
>>> -- 
>>> Send bugs reports to this list.
>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk  
>>> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk