the metro opcode supposedly accepts k-rate values for the frequency
argument, but it seems to be unable to properly process a k-rate argument.
in the orchestra below metro produces trigger bangs at a fixed frequency,
although kfreq varies randomly. 





sr	=	44100
ksmps	=	32
0dbfs	=	1

instr 1

kfreq	random	5, 10
ktrig	metro	kfreq
	out	a(ktrig)*.5

endin



i 1 0 10




metro only reacts if kfreq varies at a slow rate, for example using
something like this in the instrument above:

kfreq	randomi	5, 10, 20

btw, all the examples in the manual and floss manual use metro with a
fixed frequency. is this a known issue with metro? should something about
this be mentioned in the manual?

best,


lj

thanks for the code, iain. i did not know about trandom although it is 
so useful!
best -
	joachim


Am 16.09.2013 09:02, schrieb Iain McCurdy:
> It's not really an issue and metro is accepting k-rate value its just
> the the apparent frequency (experienced by hearing the time gap between
> clicks) will be the reciprocal of the average of all kfreq value between
> clicks. The average kfreq will be around 7.5 so the average time gap
> will be around 0.13333. The variation of your code below will show this:
>
> 
> 
>
> sr    =    44100
> ksmps    =    32
> 0dbfs    =    1
>
> instr 1
> kfreq    random    5, 10
> ktrig    metro    kfreq
>      out    a(ktrig)*.5
>
> kcount  init    0
> kcount  =       kcount+1
> if      ktrig==1 then
>   printk 0,kcount/kr
>   kcount =       0
> endif
> endin
> 
> 
>
> i 1 0 1000
>
> 
> 
>
>
> If you want a stuttering metronome with a beat period between 1/5 and
> 1/10 then you need to hold the kfreq value for the entire beat period.
> You could do this as below:
>
> 
> 
>
> sr    =    44100
> ksmps    =    32
> 0dbfs    =    1
>
> instr 1
> ktrig   init    1
> kfreq    trandom    ktrig, 5, 10
> ktrig    metro    kfreq
>      out    a(ktrig)*.5
> endin
> 
> 
>
> i 1 0 1000
>
> 
> 
>
>
> Hope this helps,
> Iain
>
>
>
>
>  > Date: Mon, 16 Sep 2013 00:42:30 -0300
>  > From: ljc@internet.com.uy
>  > To: csound@lists.bath.ac.uk
>  > Subject: [Csnd] metro issues
>  >
>  >
>  > the metro opcode supposedly accepts k-rate values for the frequency
>  > argument, but it seems to be unable to properly process a k-rate
> argument.
>  > in the orchestra below metro produces trigger bangs at a fixed frequency,
>  > although kfreq varies randomly.
>  >
>  >
>  > 
>  > 
>  >
>  > sr = 44100
>  > ksmps = 32
>  > 0dbfs = 1
>  >
>  > instr 1
>  >
>  > kfreq random 5, 10
>  > ktrig metro kfreq
>  > out a(ktrig)*.5
>  >
>  > endin
>  > 
>  > 
>  >
>  > i 1 0 10
>  >
>  > 
>  > 
>  >
>  > metro only reacts if kfreq varies at a slow rate, for example using
>  > something like this in the instrument above:
>  >
>  > kfreq randomi 5, 10, 20
>  >
>  > btw, all the examples in the manual and floss manual use metro with a
>  > fixed frequency. is this a known issue with metro? should something about
>  > this be mentioned in the manual?
>  >
>  > best,
>  >
>  >
>  > lj
>  >
>  >
>  > 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"
>  >
>  >

Nor I, but I expect it will quickly become part of my essential opcodes!


On 16 September 2013 12:28, joachim heintz  wrote:
> thanks for the code, iain. i did not know about trandom although it is so
> useful!
> best -
>         joachim
>
>
> Am 16.09.2013 09:02, schrieb Iain McCurdy:
>>
>> It's not really an issue and metro is accepting k-rate value its just
>> the the apparent frequency (experienced by hearing the time gap between
>> clicks) will be the reciprocal of the average of all kfreq value between
>> clicks. The average kfreq will be around 7.5 so the average time gap
>> will be around 0.13333. The variation of your code below will show this:
>>
>> 
>> 
>>
>> sr    =    44100
>> ksmps    =    32
>> 0dbfs    =    1
>>
>> instr 1
>> kfreq    random    5, 10
>> ktrig    metro    kfreq
>>      out    a(ktrig)*.5
>>
>> kcount  init    0
>> kcount  =       kcount+1
>> if      ktrig==1 then
>>   printk 0,kcount/kr
>>   kcount =       0
>> endif
>> endin
>> 
>> 
>>
>> i 1 0 1000
>>
>> 
>> 
>>
>>
>> If you want a stuttering metronome with a beat period between 1/5 and
>> 1/10 then you need to hold the kfreq value for the entire beat period.
>> You could do this as below:
>>
>> 
>> 
>>
>> sr    =    44100
>> ksmps    =    32
>> 0dbfs    =    1
>>
>> instr 1
>> ktrig   init    1
>> kfreq    trandom    ktrig, 5, 10
>> ktrig    metro    kfreq
>>      out    a(ktrig)*.5
>> endin
>> 
>> 
>>
>> i 1 0 1000
>>
>> 
>> 
>>
>>
>> Hope this helps,
>> Iain
>>
>>
>>
>>
>>  > Date: Mon, 16 Sep 2013 00:42:30 -0300
>>  > From: ljc@internet.com.uy
>>  > To: csound@lists.bath.ac.uk
>>  > Subject: [Csnd] metro issues
>>  >
>>  >
>>  > the metro opcode supposedly accepts k-rate values for the frequency
>>  > argument, but it seems to be unable to properly process a k-rate
>> argument.
>>  > in the orchestra below metro produces trigger bangs at a fixed
>> frequency,
>>  > although kfreq varies randomly.
>>  >
>>  >
>>  > 
>>  > 
>>  >
>>  > sr = 44100
>>  > ksmps = 32
>>  > 0dbfs = 1
>>  >
>>  > instr 1
>>  >
>>  > kfreq random 5, 10
>>  > ktrig metro kfreq
>>  > out a(ktrig)*.5
>>  >
>>  > endin
>>  > 
>>  > 
>>  >
>>  > i 1 0 10
>>  >
>>  > 
>>  > 
>>  >
>>  > metro only reacts if kfreq varies at a slow rate, for example using
>>  > something like this in the instrument above:
>>  >
>>  > kfreq randomi 5, 10, 20
>>  >
>>  > btw, all the examples in the manual and floss manual use metro with a
>>  > fixed frequency. is this a known issue with metro? should something
>> about
>>  > this be mentioned in the manual?
>>  >
>>  > best,
>>  >
>>  >
>>  > lj
>>  >
>>  >
>>  > 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"
>
>

on 2013-09-16 at 07:02 Iain McCurdy wrote:

> the apparent frequency (experienced by hearing the time gap between
> clicks) will be the reciprocal of the average of all kfreq value between
> clicks.

aha! now i get why metro seemed to respond only to slow rate kfreqs. i
didn't know about the averaging, i guess i pictured that with each bang
the metro opcode took the instantaneous value of kfreq at the moment, or
something like that.


> kfreq    trandom    ktrig, 5, 10

neat! i wasn't even aware of the trandom opcode... the perfect and
definite solution to all my triggering troubles!

thanks iain!