hello!
can someone help me understand why two metro signals will/won't stay in sync under different sr and ksmps?
for example:
```
;goes out of sync
sr = 48000
ksmps = 16
instr 1
kt1 = metro(4)
kt2 = metro(8)
if kt1+kt2 == 2 then
    printks("in sync at: %f\n", 0, timeinsts())
elseif kt1 == 1 then
    ;kt1 alone is high, kt2 is a bit off
    printks("out of sync at: %f\n", 0, timeinsts())
endif
endin
schedule(1, 0, 60)
```

and:
```
;stays in sync
sr = 65536
ksmps = 64
instr 2
kt1 = metro(4)
kt2 = metro(8)
;this however will go out of sync with kt1 at 1.4 and kt2 at 7
if kt1+kt2 == 2 then
    printks("in sync at: %f\n", 0, timeinsts())
elseif kt1 == 1 then
    printks("out of sync at: %f\n", 0, timeinsts())
endif
endin
schedule(2, 0, 60)
```

experimenting with different sr/ksmps values and different metro frquencies will give unexpected results sometimes. this is even worse when the metros switch frquencies over time (even though they're always multiples and should stay in sync) this can cause the signals to drift much further. (it makes one of my sequencers very unstable)

i suspect it has something to do with how the metro will increase its phase by cps/kr every cycle but i'm not sure of that

any ideas on how to avoid this? also any suggestions welcome
thanks!

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi,

I think it's because of floating-point representation. The number 
8/(48000/16)  added 375 times equals 1.0000000000000062; however, the 
number 4/(48000/16)  added 750 times equals 0.99999999999998967. On the 
other hand, the number 8/(65536/64) added 128 times equals 1, same as  
4/(65536/64) added 256 times.

Cheers.


On 29/7/22 00:27, amy universe wrote:
> hello!
> can someone help me understand why two metro signals will/won't stay in sync under different sr and ksmps?
> for example:
> ```
> ;goes out of sync
> sr = 48000
> ksmps = 16
> instr 1
> kt1 = metro(4)
> kt2 = metro(8)
> if kt1+kt2 == 2 then
>      printks("in sync at: %f\n", 0, timeinsts())
> elseif kt1 == 1 then
>      ;kt1 alone is high, kt2 is a bit off
>      printks("out of sync at: %f\n", 0, timeinsts())
> endif
> endin
> schedule(1, 0, 60)
> ```
>
> and:
> ```
> ;stays in sync
> sr = 65536
> ksmps = 64
> instr 2
> kt1 = metro(4)
> kt2 = metro(8)
> ;this however will go out of sync with kt1 at 1.4 and kt2 at 7
> if kt1+kt2 == 2 then
>      printks("in sync at: %f\n", 0, timeinsts())
> elseif kt1 == 1 then
>      printks("out of sync at: %f\n", 0, timeinsts())
> endif
> endin
> schedule(2, 0, 60)
> ```
>
> experimenting with different sr/ksmps values and different metro frquencies will give unexpected results sometimes. this is even worse when the metros switch frquencies over time (even though they're always multiples and should stay in sync) this can cause the signals to drift much further. (it makes one of my sequencers very unstable)
>
> i suspect it has something to do with how the metro will increase its phase by cps/kr every cycle but i'm not sure of that
>
> any ideas on how to avoid this? also any suggestions welcome
> thanks!
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>          https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

This is a bug in the metro implementation, where in each k-pass adds a 
phase, which adds errors over time. Instead it should use a counter and 
multiply the phase delta by this counter.

It probably could be changed without breaking backwards compatibility 
since metro is not behaving as it should.

On 29.07.22 05:27, amy universe wrote:
> hello!
> can someone help me understand why two metro signals will/won't stay in sync under different sr and ksmps?
> for example:
> ```
> ;goes out of sync
> sr = 48000
> ksmps = 16
> instr 1
> kt1 = metro(4)
> kt2 = metro(8)
> if kt1+kt2 == 2 then
>      printks("in sync at: %f\n", 0, timeinsts())
> elseif kt1 == 1 then
>      ;kt1 alone is high, kt2 is a bit off
>      printks("out of sync at: %f\n", 0, timeinsts())
> endif
> endin
> schedule(1, 0, 60)
> ```
>
> and:
> ```
> ;stays in sync
> sr = 65536
> ksmps = 64
> instr 2
> kt1 = metro(4)
> kt2 = metro(8)
> ;this however will go out of sync with kt1 at 1.4 and kt2 at 7
> if kt1+kt2 == 2 then
>      printks("in sync at: %f\n", 0, timeinsts())
> elseif kt1 == 1 then
>      printks("out of sync at: %f\n", 0, timeinsts())
> endif
> endin
> schedule(2, 0, 60)
> ```
>
> experimenting with different sr/ksmps values and different metro frquencies will give unexpected results sometimes. this is even worse when the metros switch frquencies over time (even though they're always multiples and should stay in sync) this can cause the signals to drift much further. (it makes one of my sequencers very unstable)
>
> i suspect it has something to do with how the metro will increase its phase by cps/kr every cycle but i'm not sure of that
>
> any ideas on how to avoid this? also any suggestions welcome
> thanks!
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>          https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Sounds like a bug that needs to be fixed, do you know what needs to be done in the code? Can you do a PR?

> On 29 Jul 2022, at 10:35, Eduardo Moguillansky  wrote:
> 
> *Warning*
> 
> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> 
> This is a bug in the metro implementation, where in each k-pass adds a
> phase, which adds errors over time. Instead it should use a counter and
> multiply the phase delta by this counter.
> 
> It probably could be changed without breaking backwards compatibility
> since metro is not behaving as it should.
> 
> On 29.07.22 05:27, amy universe wrote:
>> hello!
>> can someone help me understand why two metro signals will/won't stay in sync under different sr and ksmps?
>> for example:
>> ```
>> ;goes out of sync
>> sr = 48000
>> ksmps = 16
>> instr 1
>> kt1 = metro(4)
>> kt2 = metro(8)
>> if kt1+kt2 == 2 then
>>     printks("in sync at: %f\n", 0, timeinsts())
>> elseif kt1 == 1 then
>>     ;kt1 alone is high, kt2 is a bit off
>>     printks("out of sync at: %f\n", 0, timeinsts())
>> endif
>> endin
>> schedule(1, 0, 60)
>> ```
>> 
>> and:
>> ```
>> ;stays in sync
>> sr = 65536
>> ksmps = 64
>> instr 2
>> kt1 = metro(4)
>> kt2 = metro(8)
>> ;this however will go out of sync with kt1 at 1.4 and kt2 at 7
>> if kt1+kt2 == 2 then
>>     printks("in sync at: %f\n", 0, timeinsts())
>> elseif kt1 == 1 then
>>     printks("out of sync at: %f\n", 0, timeinsts())
>> endif
>> endin
>> schedule(2, 0, 60)
>> ```
>> 
>> experimenting with different sr/ksmps values and different metro frquencies will give unexpected results sometimes. this is even worse when the metros switch frquencies over time (even though they're always multiples and should stay in sync) this can cause the signals to drift much further. (it makes one of my sequencers very unstable)
>> 
>> i suspect it has something to do with how the metro will increase its phase by cps/kr every cycle but i'm not sure of that
>> 
>> any ideas on how to avoid this? also any suggestions welcome
>> thanks!
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C2d124c82b1af499ca49c08da7145e0b6%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637946842189404632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=flMqhEMGT1qV48YXYtmCEwQ2CIRCneGFpzQgOGXlma8%3D&reserved=0
>> Send bugs reports to
>>         https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C2d124c82b1af499ca49c08da7145e0b6%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637946842189404632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JFeIENQxcZbizkWl9z%2BZegzt8eNVL01J4MrA%2FLWEH1Q%3D&reserved=0
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C2d124c82b1af499ca49c08da7145e0b6%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637946842189404632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=flMqhEMGT1qV48YXYtmCEwQ2CIRCneGFpzQgOGXlma8%3D&reserved=0
> Send bugs reports to
>       https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C2d124c82b1af499ca49c08da7145e0b6%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637946842189404632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JFeIENQxcZbizkWl9z%2BZegzt8eNVL01J4MrA%2FLWEH1Q%3D&reserved=0
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Here is a reference implementation:

https://github.com/csound-plugins/csound-plugins/blob/d738ad985f996c3dea291c4bd331c806a6838aa4/src/else/src/else.c#L5480

On 29.07.22 13:29, Victor Lazzarini wrote:
> Sounds like a bug that needs to be fixed, do you know what needs to be done in the code? Can you do a PR?
>
>> On 29 Jul 2022, at 10:35, Eduardo Moguillansky  wrote:
>>
>> *Warning*
>>
>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>
>> This is a bug in the metro implementation, where in each k-pass adds a
>> phase, which adds errors over time. Instead it should use a counter and
>> multiply the phase delta by this counter.
>>
>> It probably could be changed without breaking backwards compatibility
>> since metro is not behaving as it should.
>>
>> On 29.07.22 05:27, amy universe wrote:
>>> hello!
>>> can someone help me understand why two metro signals will/won't stay in sync under different sr and ksmps?
>>> for example:
>>> ```
>>> ;goes out of sync
>>> sr = 48000
>>> ksmps = 16
>>> instr 1
>>> kt1 = metro(4)
>>> kt2 = metro(8)
>>> if kt1+kt2 == 2 then
>>>      printks("in sync at: %f\n", 0, timeinsts())
>>> elseif kt1 == 1 then
>>>      ;kt1 alone is high, kt2 is a bit off
>>>      printks("out of sync at: %f\n", 0, timeinsts())
>>> endif
>>> endin
>>> schedule(1, 0, 60)
>>> ```
>>>
>>> and:
>>> ```
>>> ;stays in sync
>>> sr = 65536
>>> ksmps = 64
>>> instr 2
>>> kt1 = metro(4)
>>> kt2 = metro(8)
>>> ;this however will go out of sync with kt1 at 1.4 and kt2 at 7
>>> if kt1+kt2 == 2 then
>>>      printks("in sync at: %f\n", 0, timeinsts())
>>> elseif kt1 == 1 then
>>>      printks("out of sync at: %f\n", 0, timeinsts())
>>> endif
>>> endin
>>> schedule(2, 0, 60)
>>> ```
>>>
>>> experimenting with different sr/ksmps values and different metro frquencies will give unexpected results sometimes. this is even worse when the metros switch frquencies over time (even though they're always multiples and should stay in sync) this can cause the signals to drift much further. (it makes one of my sequencers very unstable)
>>>
>>> i suspect it has something to do with how the metro will increase its phase by cps/kr every cycle but i'm not sure of that
>>>
>>> any ideas on how to avoid this? also any suggestions welcome
>>> thanks!
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C2d124c82b1af499ca49c08da7145e0b6%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637946842189404632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=flMqhEMGT1qV48YXYtmCEwQ2CIRCneGFpzQgOGXlma8%3D&reserved=0
>>> Send bugs reports to
>>>          https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C2d124c82b1af499ca49c08da7145e0b6%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637946842189404632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JFeIENQxcZbizkWl9z%2BZegzt8eNVL01J4MrA%2FLWEH1Q%3D&reserved=0
>>> Discussions of bugs and features can be posted here
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C2d124c82b1af499ca49c08da7145e0b6%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637946842189404632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=flMqhEMGT1qV48YXYtmCEwQ2CIRCneGFpzQgOGXlma8%3D&reserved=0
>> Send bugs reports to
>>        https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C2d124c82b1af499ca49c08da7145e0b6%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637946842189404632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JFeIENQxcZbizkWl9z%2BZegzt8eNVL01J4MrA%2FLWEH1Q%3D&reserved=0
>> Discussions of bugs and features can be posted here
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>          https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Another workaround in such cases would be to use just one metro as a "master clock" and derive further timings via counters.

Best,
Jana

i tried doing it your way with a udo, it's working nicely so far!

this is so cool! thank you!

```

opcode MyMetro, k, k

kcps xin

kcnt init kr

kflag = 0

kcnt += kcps

if kcnt >= kr then

    kflag = 1

    kcnt -= kr

endif

xout kflag

endop

```

On Fri, Jul 29, 2022, 11:36 Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote:

This is a bug in the metro implementation, where in each k-pass adds a
phase, which adds errors over time. Instead it should use a counter and
multiply the phase delta by this counter.

It probably could be changed without breaking backwards compatibility
since metro is not behaving as it should.

On 29.07.22 05:27, amy universe wrote:
> hello!
> can someone help me understand why two metro signals will/won't stay in sync under different sr and ksmps?
> for example:
> ```
> ;goes out of sync
> sr = 48000
> ksmps = 16
> instr 1
> kt1 = metro(4)
> kt2 = metro(8)
> if kt1+kt2 == 2 then
>      printks("in sync at: %f\n", 0, timeinsts())
> elseif kt1 == 1 then
>      ;kt1 alone is high, kt2 is a bit off
>      printks("out of sync at: %f\n", 0, timeinsts())
> endif
> endin
> schedule(1, 0, 60)
> ```
>
> and:
> ```
> ;stays in sync
> sr = 65536
> ksmps = 64
> instr 2
> kt1 = metro(4)
> kt2 = metro(8)
> ;this however will go out of sync with kt1 at 1.4 and kt2 at 7
> if kt1+kt2 == 2 then
>      printks("in sync at: %f\n", 0, timeinsts())
> elseif kt1 == 1 then
>      printks("out of sync at: %f\n", 0, timeinsts())
> endif
> endin
> schedule(2, 0, 60)
> ```
>
> experimenting with different sr/ksmps values and different metro frquencies will give unexpected results sometimes. this is even worse when the metros switch frquencies over time (even though they're always multiples and should stay in sync) this can cause the signals to drift much further. (it makes one of my sequencers very unstable)
>
> i suspect it has something to do with how the metro will increase its phase by cps/kr every cycle but i'm not sure of that
>
> any ideas on how to avoid this? also any suggestions welcome
> thanks!
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>          https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here