Hi,

I guess that reading from channels should be fast in Csound.
Maybe it is sprintfk that takes time? Can you try to fill an array of string once with the channel names and use the channel names from the array by index?

Or can you use gk arrray instead of channels?

Tamo

On first glance it seems like the code should work.  What is happening
when you say it doesn't work?  Is it that only one value in the array
is set, or none are, or all are to the same value, or...?


On Thu, Dec 31, 2015 at 10:19 AM, Rory Walsh  wrote:
> Actually, that's not quite my point. What I'm trying to do is save myself
> from writing 100s of lines of code like this:
>
> k1 chnget "foo1"
> k2 chnget "foo2"
> k3 chnget "foo3"
> k4 chnget "foo4"
> k5 chnget "foo5"
> k6 chnget "foo6"
> k7 chnget "foo7"
> etc...
>
> I am looking for a way to do this in a loop. I can get it to work if I check
> only one channel on each k-cycle, but not if I want to check them all on
> each k-cycle.
>
> On 31 December 2015 at 15:04, Tarmo Johannes
>  wrote:
>>
>> Hi,
>>
>> I guess that reading from channels should be fast in Csound.
>> Maybe it is sprintfk that takes time? Can you try to fill an array of
>> string once with the channel names and use the channel names from the array
>> by index?
>>
>> Or can you use gk arrray instead of channels?
>>
>> Tamo
>>
>> 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh" :
>>>
>>> Has anyone any suggestions on how best to check the values stored on a
>>> large numbers of channels on each k-cycle? I've been thwarted in my attempts
>>> to efficiently do this. I have an instrument that has 100 channels, named
>>> "step1" up to "step100".  I would like to run a loop on each k-cycle from
>>> another instrument, and fill an array with the values of each of the
>>> channels but I can't seem to get it to work. Surely there is a quick and
>>> efficient way to do this? My latest attempt to do this is shown below, but
>>> doesn't work as I had hoped.
>>>
>>> kIndex=0
>>> kSteps[] init 100
>>>
>>> GET_VALUES:
>>> SChannel sprintfk "step%d", kIndex+1
>>> kSteps[kIndex] chnget SChannel
>>> kIndex = kIndex+1
>>> cggoto kIndex<100, GET_VALUES
>>>
>>>
>>>
>>>
>>>
>>> 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

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

Try printk2. I seem to remember printk only printing once per k-cycle, and thus being problematic in loops.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 31 Dec 2015, at 15:34, Rory Walsh  wrote:
> 
> Perhaps this instrument better explains what I'm talking about! I create 100 channels in instr1 and set their value to 0. instr3 is attempting to read the values of each of the channels on each k-cycle. instr2 is called after some time to change the value of channel "step1", but as you can see, a value of 1 is never printed, leading me to believe that instr3 is not doing it's job right :(
> 
> 
> 
> -+rtaudio=jack -odac -b4096
> 
> 
> 
> instr 1; set all channels to 0 
>     iCnt init 0
>     until iCnt > 100 do
>         S1 sprintf "step%d", iCnt+1
>         chnset 0, S1
>         iCnt=iCnt+1
>     enduntil
> endin
> 
> instr 2; change value of channel 'step1'
>     chnset 1, "step1" 
> endin
> 
> instr 3; pass values from channels into array
>     kIndex = 0
>     kSteps[] init 100
> 
>     GET_STATES:
>     kSteps[kIndex] chnget sprintfk("step%d", kIndex+1)
>     kIndex = kIndex+1
>     cggoto kIndex<100, GET_STATES
> 
>     printk 1, kSteps[0];
> endin
> 
> 
> 
> i1 0 1
> i3 1 30
> i2 4 .1
> 
> 
> 
> On 31 December 2015 at 15:19, Rory Walsh  wrote:
> Actually, that's not quite my point. What I'm trying to do is save myself from writing 100s of lines of code like this:
> 
> k1 chnget "foo1"
> k2 chnget "foo2"
> k3 chnget "foo3"
> k4 chnget "foo4"
> k5 chnget "foo5"
> k6 chnget "foo6"
> k7 chnget "foo7"
> etc...
> 
> I am looking for a way to do this in a loop. I can get it to work if I check only one channel on each k-cycle, but not if I want to check them all on each k-cycle. 
> 
> On 31 December 2015 at 15:04, Tarmo Johannes  wrote:
> Hi,
> 
> I guess that reading from channels should be fast in Csound.
> Maybe it is sprintfk that takes time? Can you try to fill an array of string once with the channel names and use the channel names from the array by index?
> 
> Or can you use gk arrray instead of channels?
> 
> Tamo
> 
> 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh" :
> Has anyone any suggestions on how best to check the values stored on a large numbers of channels on each k-cycle? I've been thwarted in my attempts to efficiently do this. I have an instrument that has 100 channels, named "step1" up to "step100".  I would like to run a loop on each k-cycle from another instrument, and fill an array with the values of each of the channels but I can't seem to get it to work. Surely there is a quick and efficient way to do this? My latest attempt to do this is shown below, but doesn't work as I had hoped. 
> 
> kIndex=0
> kSteps[] init 100
> 
> GET_VALUES:
> SChannel sprintfk "step%d", kIndex+1
> kSteps[kIndex] chnget SChannel
> kIndex = kIndex+1
> cggoto kIndex<100, GET_VALUES
> 
> 
> 
> 
> 
> 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

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

Silly thought; why nit 100 instances of i3 each with a different index?
No loop just the nrmal csound dispatch; could paralise aswell

On Thu, 31 Dec 2015, Rory Walsh wrote:

> Still no joy, but printk2 chnget:k("step1") does work. I've checked the
> channel names that are constructed and they are fine.
> 
> instr 1; set all channels to 0
>     iCnt init 0
>     until iCnt > 100 do
>         S1 sprintf "step%d", iCnt+1
>         chnset 0, S1
>         iCnt=iCnt+1
>     enduntil
> endin
> 
> instr 2; change value of channel 'step1'
>     chnset 1, "step1"
> endin
> 
> instr 3
>     kIndex = 0
>     kSteps[] init 10
> 
>     GET_STATES:
>     SChannel sprintfk "step%d", kIndex+1
>     kSteps[kIndex] chnget SChannel
>     kIndex = kIndex+1
>     cggoto kIndex<10, GET_STATES
> 
>     printk2 kSteps[0];
>     ;printk 1, chnget:k("step1");works..
> endin
> 
> On 31 December 2015 at 15:39, Victor Lazzarini 
> wrote:
>       Try printk2. I seem to remember printk only printing once per
>       k-cycle, and thus being problematic in loops.
>       ========================
>       Dr Victor Lazzarini
>       Dean of Arts, Celtic Studies and Philosophy,
>       Maynooth University,
>       Maynooth, Co Kildare, Ireland
>       Tel: 00 353 7086936
>       Fax: 00 353 1 7086952
>
>       > On 31 Dec 2015, at 15:34, Rory Walsh  wrote:
>       >
>       > Perhaps this instrument better explains what I'm talking about!
>       I create 100 channels in instr1 and set their value to 0. instr3
>       is attempting to read the values of each of the channels on each
>       k-cycle. instr2 is called after some time to change the value of
>       channel "step1", but as you can see, a value of 1 is never
>       printed, leading me to believe that instr3 is not doing it's job
>       right :(
>       >
>       > 
>       > 
>       > -+rtaudio=jack -odac -b4096
>       > 
>       > 
>       >
>       > instr 1; set all channels to 0
>       >     iCnt init 0
>       >     until iCnt > 100 do
>       >         S1 sprintf "step%d", iCnt+1
>       >         chnset 0, S1
>       >         iCnt=iCnt+1
>       >     enduntil
>       > endin
>       >
>       > instr 2; change value of channel 'step1'
>       >     chnset 1, "step1"
>       > endin
>       >
>       > instr 3; pass values from channels into array
>       >     kIndex = 0
>       >     kSteps[] init 100
>       >
>       >     GET_STATES:
>       >     kSteps[kIndex] chnget sprintfk("step%d", kIndex+1)
>       >     kIndex = kIndex+1
>       >     cggoto kIndex<100, GET_STATES
>       >
>       >     printk 1, kSteps[0];
>       > endin
>       >
>       > 
>       > 
>       > i1 0 1
>       > i3 1 30
>       > i2 4 .1
>       > 
>       > 
>       >
>       > On 31 December 2015 at 15:19, Rory Walsh 
>       wrote:
>       > Actually, that's not quite my point. What I'm trying to do is
>       save myself from writing 100s of lines of code like this:
>       >
>       > k1 chnget "foo1"
>       > k2 chnget "foo2"
>       > k3 chnget "foo3"
>       > k4 chnget "foo4"
>       > k5 chnget "foo5"
>       > k6 chnget "foo6"
>       > k7 chnget "foo7"
>       > etc...
>       >
>       > I am looking for a way to do this in a loop. I can get it to
>       work if I check only one channel on each k-cycle, but not if I
>       want to check them all on each k-cycle.
>       >
>       > On 31 December 2015 at 15:04, Tarmo Johannes
>        wrote:
>       > Hi,
>       >
>       > I guess that reading from channels should be fast in Csound.
>       > Maybe it is sprintfk that takes time? Can you try to fill an
>       array of string once with the channel names and use the channel
>       names from the array by index?
>       >
>       > Or can you use gk arrray instead of channels?
>       >
>       > Tamo
>       >
>       > 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh"
>       :
>       > Has anyone any suggestions on how best to check the values
>       stored on a large numbers of channels on each k-cycle? I've been
>       thwarted in my attempts to efficiently do this. I have an
>       instrument that has 100 channels, named "step1" up to "step100". 
>       I would like to run a loop on each k-cycle from another
>       instrument, and fill an array with the values of each of the
>       channels but I can't seem to get it to work. Surely there is a
>       quick and efficient way to do this? My latest attempt to do this
>       is shown below, but doesn't work as I had hoped.
>       >
>       > kIndex=0
>       > kSteps[] init 100
>       >
>       > GET_VALUES:
>       > SChannel sprintfk "step%d", kIndex+1
>       > kSteps[kIndex] chnget SChannel
>       > kIndex = kIndex+1
>       > cggoto kIndex<100, GET_VALUES
>       >
>       >
>       >
>       >
>       >
>       > 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
>
>       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

Hi Steven. You can see in the full example I posted that instrument 3 is not picking up the change to channel 'step1'.

The reason is that chnget takes its channel name at init time, and then reads from 
it at k-time. If you change the channel name at k-time, it will not look into a different channel.

Not quite sure whether it is a appropriate to change this behaviour, but it’s easy to do.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 31 Dec 2015, at 16:47, Rory Walsh  wrote:
> 
> Hi Steven. You can see in the full example I posted that instrument 3 is not picking up the change to channel 'step1'.
> 
> On 31 Dec 2015 15:37, "Steven Yi"  wrote:
> On first glance it seems like the code should work.  What is happening
> when you say it doesn't work?  Is it that only one value in the array
> is set, or none are, or all are to the same value, or...?
> 
> 
> On Thu, Dec 31, 2015 at 10:19 AM, Rory Walsh  wrote:
> > Actually, that's not quite my point. What I'm trying to do is save myself
> > from writing 100s of lines of code like this:
> >
> > k1 chnget "foo1"
> > k2 chnget "foo2"
> > k3 chnget "foo3"
> > k4 chnget "foo4"
> > k5 chnget "foo5"
> > k6 chnget "foo6"
> > k7 chnget "foo7"
> > etc...
> >
> > I am looking for a way to do this in a loop. I can get it to work if I check
> > only one channel on each k-cycle, but not if I want to check them all on
> > each k-cycle.
> >
> > On 31 December 2015 at 15:04, Tarmo Johannes
> >  wrote:
> >>
> >> Hi,
> >>
> >> I guess that reading from channels should be fast in Csound.
> >> Maybe it is sprintfk that takes time? Can you try to fill an array of
> >> string once with the channel names and use the channel names from the array
> >> by index?
> >>
> >> Or can you use gk arrray instead of channels?
> >>
> >> Tamo
> >>
> >> 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh" :
> >>>
> >>> Has anyone any suggestions on how best to check the values stored on a
> >>> large numbers of channels on each k-cycle? I've been thwarted in my attempts
> >>> to efficiently do this. I have an instrument that has 100 channels, named
> >>> "step1" up to "step100".  I would like to run a loop on each k-cycle from
> >>> another instrument, and fill an array with the values of each of the
> >>> channels but I can't seem to get it to work. Surely there is a quick and
> >>> efficient way to do this? My latest attempt to do this is shown below, but
> >>> doesn't work as I had hoped.
> >>>
> >>> kIndex=0
> >>> kSteps[] init 100
> >>>
> >>> GET_VALUES:
> >>> SChannel sprintfk "step%d", kIndex+1
> >>> kSteps[kIndex] chnget SChannel
> >>> kIndex = kIndex+1
> >>> cggoto kIndex<100, GET_VALUES
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 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
> 
> 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

That makes a lot of sense.  If we do a lookup on each pass of the
channel name, that might make chnget more expensive, but it should be
backwards-compatible.  I imagine the way Rory was using it would be
the expected behavior, but I'm hesitant about the performance impact.

Sidenote: This is a situation where having an i/k corollary for other
types might be useful, or adding a type modifier like "const S" might
clarify the intention of opcodes.


On Thu, Dec 31, 2015 at 12:33 PM, Victor Lazzarini
 wrote:
> The reason is that chnget takes its channel name at init time, and then reads from
> it at k-time. If you change the channel name at k-time, it will not look into a different channel.
>
> Not quite sure whether it is a appropriate to change this behaviour, but it’s easy to do.
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 31 Dec 2015, at 16:47, Rory Walsh  wrote:
>>
>> Hi Steven. You can see in the full example I posted that instrument 3 is not picking up the change to channel 'step1'.
>>
>> On 31 Dec 2015 15:37, "Steven Yi"  wrote:
>> On first glance it seems like the code should work.  What is happening
>> when you say it doesn't work?  Is it that only one value in the array
>> is set, or none are, or all are to the same value, or...?
>>
>>
>> On Thu, Dec 31, 2015 at 10:19 AM, Rory Walsh  wrote:
>> > Actually, that's not quite my point. What I'm trying to do is save myself
>> > from writing 100s of lines of code like this:
>> >
>> > k1 chnget "foo1"
>> > k2 chnget "foo2"
>> > k3 chnget "foo3"
>> > k4 chnget "foo4"
>> > k5 chnget "foo5"
>> > k6 chnget "foo6"
>> > k7 chnget "foo7"
>> > etc...
>> >
>> > I am looking for a way to do this in a loop. I can get it to work if I check
>> > only one channel on each k-cycle, but not if I want to check them all on
>> > each k-cycle.
>> >
>> > On 31 December 2015 at 15:04, Tarmo Johannes
>> >  wrote:
>> >>
>> >> Hi,
>> >>
>> >> I guess that reading from channels should be fast in Csound.
>> >> Maybe it is sprintfk that takes time? Can you try to fill an array of
>> >> string once with the channel names and use the channel names from the array
>> >> by index?
>> >>
>> >> Or can you use gk arrray instead of channels?
>> >>
>> >> Tamo
>> >>
>> >> 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh" :
>> >>>
>> >>> Has anyone any suggestions on how best to check the values stored on a
>> >>> large numbers of channels on each k-cycle? I've been thwarted in my attempts
>> >>> to efficiently do this. I have an instrument that has 100 channels, named
>> >>> "step1" up to "step100".  I would like to run a loop on each k-cycle from
>> >>> another instrument, and fill an array with the values of each of the
>> >>> channels but I can't seem to get it to work. Surely there is a quick and
>> >>> efficient way to do this? My latest attempt to do this is shown below, but
>> >>> doesn't work as I had hoped.
>> >>>
>> >>> kIndex=0
>> >>> kSteps[] init 100
>> >>>
>> >>> GET_VALUES:
>> >>> SChannel sprintfk "step%d", kIndex+1
>> >>> kSteps[kIndex] chnget SChannel
>> >>> kIndex = kIndex+1
>> >>> cggoto kIndex<100, GET_VALUES
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> 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
>>
>> 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

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

Ok, I’ve modified chnget:k to check for a change of channel names and in this case, to get the
new channel pointer and the data. On normal operation the overhead is just an if() check.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 31 Dec 2015, at 17:41, Steven Yi  wrote:
> 
> That makes a lot of sense.  If we do a lookup on each pass of the
> channel name, that might make chnget more expensive, but it should be
> backwards-compatible.  I imagine the way Rory was using it would be
> the expected behavior, but I'm hesitant about the performance impact.
> 
> Sidenote: This is a situation where having an i/k corollary for other
> types might be useful, or adding a type modifier like "const S" might
> clarify the intention of opcodes.
> 
> 
> On Thu, Dec 31, 2015 at 12:33 PM, Victor Lazzarini
>  wrote:
>> The reason is that chnget takes its channel name at init time, and then reads from
>> it at k-time. If you change the channel name at k-time, it will not look into a different channel.
>> 
>> Not quite sure whether it is a appropriate to change this behaviour, but it’s easy to do.
>> ========================
>> Dr Victor Lazzarini
>> Dean of Arts, Celtic Studies and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>>> On 31 Dec 2015, at 16:47, Rory Walsh  wrote:
>>> 
>>> Hi Steven. You can see in the full example I posted that instrument 3 is not picking up the change to channel 'step1'.
>>> 
>>> On 31 Dec 2015 15:37, "Steven Yi"  wrote:
>>> On first glance it seems like the code should work.  What is happening
>>> when you say it doesn't work?  Is it that only one value in the array
>>> is set, or none are, or all are to the same value, or...?
>>> 
>>> 
>>> On Thu, Dec 31, 2015 at 10:19 AM, Rory Walsh  wrote:
>>>> Actually, that's not quite my point. What I'm trying to do is save myself
>>>> from writing 100s of lines of code like this:
>>>> 
>>>> k1 chnget "foo1"
>>>> k2 chnget "foo2"
>>>> k3 chnget "foo3"
>>>> k4 chnget "foo4"
>>>> k5 chnget "foo5"
>>>> k6 chnget "foo6"
>>>> k7 chnget "foo7"
>>>> etc...
>>>> 
>>>> I am looking for a way to do this in a loop. I can get it to work if I check
>>>> only one channel on each k-cycle, but not if I want to check them all on
>>>> each k-cycle.
>>>> 
>>>> On 31 December 2015 at 15:04, Tarmo Johannes
>>>>  wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I guess that reading from channels should be fast in Csound.
>>>>> Maybe it is sprintfk that takes time? Can you try to fill an array of
>>>>> string once with the channel names and use the channel names from the array
>>>>> by index?
>>>>> 
>>>>> Or can you use gk arrray instead of channels?
>>>>> 
>>>>> Tamo
>>>>> 
>>>>> 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh" :
>>>>>> 
>>>>>> Has anyone any suggestions on how best to check the values stored on a
>>>>>> large numbers of channels on each k-cycle? I've been thwarted in my attempts
>>>>>> to efficiently do this. I have an instrument that has 100 channels, named
>>>>>> "step1" up to "step100".  I would like to run a loop on each k-cycle from
>>>>>> another instrument, and fill an array with the values of each of the
>>>>>> channels but I can't seem to get it to work. Surely there is a quick and
>>>>>> efficient way to do this? My latest attempt to do this is shown below, but
>>>>>> doesn't work as I had hoped.
>>>>>> 
>>>>>> kIndex=0
>>>>>> kSteps[] init 100
>>>>>> 
>>>>>> GET_VALUES:
>>>>>> SChannel sprintfk "step%d", kIndex+1
>>>>>> kSteps[kIndex] chnget SChannel
>>>>>> kIndex = kIndex+1
>>>>>> cggoto kIndex<100, GET_VALUES
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 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
>>> 
>>> 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
> 
> 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

i think this is because you set kRow=0 at the beginning. once a second 
kColumn becomes zero, too, and in this second, it will always trigger 
instr 1000.

cheers -
	j


On 01/01/16 21:20, Rory Walsh wrote:
> So now I've hit the next hurdle! I would like to check the sate of each
> channel, and if it is a 1, trigger an instrument. I've pasted the full
> instrument code below. kRow is incrementing 10 times within each k
> cycle, and kSteps[kRow+kColumn]==1 will only ever be true for a fraction
> of a cycle every ten seconds. I was expecting to have only one instance
> of instr1000 triggered, every ten second, as only one of the 100
> channels ever gets set to 1? Any ideas?
>
> 
> 
> -+rtaudio=jack -odac -b4096
> 
> 
> sr = 44100
> ksmps = 64
> nchnls = 2
> 0dbfs=1
>
> ;============= set all 100 channels to 0 =======
> instr 1;
>      iCnt init 0
>      until iCnt > 100 do
>          S1 sprintf "step%d", iCnt+1
>          chnset 0, S1
>          iCnt=iCnt+1
>      enduntil
> endin
>
> ;============= constantly check channel states and trigger instr1000
> accordingly =======
> instr 2
> kSteps[] init 100
> kIndex = 0
> kColumn init 0
> kRow = 0
>
> ;increment columns
> if metro(1)==1 then
>      kColumn = kColumn<9 ? kColumn+1 : 0
>      ;when column is 5 change the value stored on channel "step1" to 1
>      if kColumn==5 then
>          event "i", 3, 0, .1, 1
>      endif
> endif
>
> GET_STATES:
>      kSteps[kIndex] chnget sprintfk("step%d", kIndex+1)
>      kIndex = kIndex+1
>      cggoto kIndex<100, GET_STATES
>
> TRIGGER_NOTES:
>          if kSteps[kRow+kColumn]==1 then
>              event "i", 1000, 0, .01,  100
>              ;printks sprintfk("Column:%d, Row:%d", kColumn, kRow), 0
>          endif
>      kRow = kRow+10
>      cggoto kRow<100, TRIGGER_NOTES
>
> endin
>
> ;============= triggered instrument =======
> instr 1000
>      print p4
> endin
>
>
> ;============= change state of channel ======
> instr 3; change value of channel 'step1'
>      SChannel sprintf "step%d", int(abs(p4))
>      chnset 1, SChannel
> endin
>
> 
> 
> i1 0 1
> i2 1 1000
> 
> 
>
> On 1 January 2016 at 19:38, Rory Walsh  > wrote:
>
>     Thanks Victor. Seems to be working here Victor. It would still be
>     nice to have chnget work with arrays but this fix will do me fine!
>
>     On 1 January 2016 at 19:16, Victor Lazzarini
>     > wrote:
>
>         Ok, I’ve modified chnget:k to check for a change of channel
>         names and in this case, to get the
>         new channel pointer and the data. On normal operation the
>         overhead is just an if() check.
>         ========================
>         Dr Victor Lazzarini
>         Dean of Arts, Celtic Studies and Philosophy,
>         Maynooth University,
>         Maynooth, Co Kildare, Ireland
>         Tel: 00 353 7086936
>         Fax: 00 353 1 7086952
>
>          > On 31 Dec 2015, at 17:41, Steven Yi          > wrote:
>          >
>          > That makes a lot of sense.  If we do a lookup on each pass of the
>          > channel name, that might make chnget more expensive, but it
>         should be
>          > backwards-compatible.  I imagine the way Rory was using it
>         would be
>          > the expected behavior, but I'm hesitant about the performance
>         impact.
>          >
>          > Sidenote: This is a situation where having an i/k corollary
>         for other
>          > types might be useful, or adding a type modifier like "const
>         S" might
>          > clarify the intention of opcodes.
>          >
>          >
>          > On Thu, Dec 31, 2015 at 12:33 PM, Victor Lazzarini
>          > >
>         wrote:
>          >> The reason is that chnget takes its channel name at init
>         time, and then reads from
>          >> it at k-time. If you change the channel name at k-time, it
>         will not look into a different channel.
>          >>
>          >> Not quite sure whether it is a appropriate to change this
>         behaviour, but it’s easy to do.
>          >> ========================
>          >> Dr Victor Lazzarini
>          >> Dean of Arts, Celtic Studies and Philosophy,
>          >> Maynooth University,
>          >> Maynooth, Co Kildare, Ireland
>          >> Tel: 00 353 7086936
>          >> Fax: 00 353 1 7086952
>          >>
>          >>> On 31 Dec 2015, at 16:47, Rory Walsh          > wrote:
>          >>>
>          >>> Hi Steven. You can see in the full example I posted that
>         instrument 3 is not picking up the change to channel 'step1'.
>          >>>
>          >>> On 31 Dec 2015 15:37, "Steven Yi"          > wrote:
>          >>> On first glance it seems like the code should work.  What
>         is happening
>          >>> when you say it doesn't work?  Is it that only one value in
>         the array
>          >>> is set, or none are, or all are to the same value, or...?
>          >>>
>          >>>
>          >>> On Thu, Dec 31, 2015 at 10:19 AM, Rory Walsh
>         > wrote:
>          >>>> Actually, that's not quite my point. What I'm trying to do
>         is save myself
>          >>>> from writing 100s of lines of code like this:
>          >>>>
>          >>>> k1 chnget "foo1"
>          >>>> k2 chnget "foo2"
>          >>>> k3 chnget "foo3"
>          >>>> k4 chnget "foo4"
>          >>>> k5 chnget "foo5"
>          >>>> k6 chnget "foo6"
>          >>>> k7 chnget "foo7"
>          >>>> etc...
>          >>>>
>          >>>> I am looking for a way to do this in a loop. I can get it
>         to work if I check
>          >>>> only one channel on each k-cycle, but not if I want to
>         check them all on
>          >>>> each k-cycle.
>          >>>>
>          >>>> On 31 December 2015 at 15:04, Tarmo Johannes
>          >>>>          > wrote:
>          >>>>>
>          >>>>> Hi,
>          >>>>>
>          >>>>> I guess that reading from channels should be fast in Csound.
>          >>>>> Maybe it is sprintfk that takes time? Can you try to fill
>         an array of
>          >>>>> string once with the channel names and use the channel
>         names from the array
>          >>>>> by index?
>          >>>>>
>          >>>>> Or can you use gk arrray instead of channels?
>          >>>>>
>          >>>>> Tamo
>          >>>>>
>          >>>>> 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh"
>         >:
>          >>>>>>
>          >>>>>> Has anyone any suggestions on how best to check the
>         values stored on a
>          >>>>>> large numbers of channels on each k-cycle? I've been
>         thwarted in my attempts
>          >>>>>> to efficiently do this. I have an instrument that has
>         100 channels, named
>          >>>>>> "step1" up to "step100".  I would like to run a loop on
>         each k-cycle from
>          >>>>>> another instrument, and fill an array with the values of
>         each of the
>          >>>>>> channels but I can't seem to get it to work. Surely
>         there is a quick and
>          >>>>>> efficient way to do this? My latest attempt to do this
>         is shown below, but
>          >>>>>> doesn't work as I had hoped.
>          >>>>>>
>          >>>>>> kIndex=0
>          >>>>>> kSteps[] init 100
>          >>>>>>
>          >>>>>> GET_VALUES:
>          >>>>>> SChannel sprintfk "step%d", kIndex+1
>          >>>>>> kSteps[kIndex] chnget SChannel
>          >>>>>> kIndex = kIndex+1
>          >>>>>> cggoto kIndex<100, GET_VALUES
>          >>>>>>
>          >>>>>>
>          >>>>>>
>          >>>>>>
>          >>>>>>
>          >>>>>> 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
>          >>>
>          >>> 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
>          >
>          > 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

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

yes, you will keep re-triggering for one whole second on every k-cycle.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 1 Jan 2016, at 20:50, joachim heintz  wrote:
> 
> i think this is because you set kRow=0 at the beginning. once a second kColumn becomes zero, too, and in this second, it will always trigger instr 1000.
> 
> cheers -
> 	j
> 
> 
> On 01/01/16 21:20, Rory Walsh wrote:
>> So now I've hit the next hurdle! I would like to check the sate of each
>> channel, and if it is a 1, trigger an instrument. I've pasted the full
>> instrument code below. kRow is incrementing 10 times within each k
>> cycle, and kSteps[kRow+kColumn]==1 will only ever be true for a fraction
>> of a cycle every ten seconds. I was expecting to have only one instance
>> of instr1000 triggered, every ten second, as only one of the 100
>> channels ever gets set to 1? Any ideas?
>> 
>> 
>> 
>> -+rtaudio=jack -odac -b4096
>> 
>> 
>> sr = 44100
>> ksmps = 64
>> nchnls = 2
>> 0dbfs=1
>> 
>> ;============= set all 100 channels to 0 =======
>> instr 1;
>>     iCnt init 0
>>     until iCnt > 100 do
>>         S1 sprintf "step%d", iCnt+1
>>         chnset 0, S1
>>         iCnt=iCnt+1
>>     enduntil
>> endin
>> 
>> ;============= constantly check channel states and trigger instr1000
>> accordingly =======
>> instr 2
>> kSteps[] init 100
>> kIndex = 0
>> kColumn init 0
>> kRow = 0
>> 
>> ;increment columns
>> if metro(1)==1 then
>>     kColumn = kColumn<9 ? kColumn+1 : 0
>>     ;when column is 5 change the value stored on channel "step1" to 1
>>     if kColumn==5 then
>>         event "i", 3, 0, .1, 1
>>     endif
>> endif
>> 
>> GET_STATES:
>>     kSteps[kIndex] chnget sprintfk("step%d", kIndex+1)
>>     kIndex = kIndex+1
>>     cggoto kIndex<100, GET_STATES
>> 
>> TRIGGER_NOTES:
>>         if kSteps[kRow+kColumn]==1 then
>>             event "i", 1000, 0, .01,  100
>>             ;printks sprintfk("Column:%d, Row:%d", kColumn, kRow), 0
>>         endif
>>     kRow = kRow+10
>>     cggoto kRow<100, TRIGGER_NOTES
>> 
>> endin
>> 
>> ;============= triggered instrument =======
>> instr 1000
>>     print p4
>> endin
>> 
>> 
>> ;============= change state of channel ======
>> instr 3; change value of channel 'step1'
>>     SChannel sprintf "step%d", int(abs(p4))
>>     chnset 1, SChannel
>> endin
>> 
>> 
>> 
>> i1 0 1
>> i2 1 1000
>> 
>> 
>> 
>> On 1 January 2016 at 19:38, Rory Walsh > > wrote:
>> 
>>    Thanks Victor. Seems to be working here Victor. It would still be
>>    nice to have chnget work with arrays but this fix will do me fine!
>> 
>>    On 1 January 2016 at 19:16, Victor Lazzarini
>>    > wrote:
>> 
>>        Ok, I’ve modified chnget:k to check for a change of channel
>>        names and in this case, to get the
>>        new channel pointer and the data. On normal operation the
>>        overhead is just an if() check.
>>        ========================
>>        Dr Victor Lazzarini
>>        Dean of Arts, Celtic Studies and Philosophy,
>>        Maynooth University,
>>        Maynooth, Co Kildare, Ireland
>>        Tel: 00 353 7086936
>>        Fax: 00 353 1 7086952
>> 
>>         > On 31 Dec 2015, at 17:41, Steven Yi >        > wrote:
>>         >
>>         > That makes a lot of sense.  If we do a lookup on each pass of the
>>         > channel name, that might make chnget more expensive, but it
>>        should be
>>         > backwards-compatible.  I imagine the way Rory was using it
>>        would be
>>         > the expected behavior, but I'm hesitant about the performance
>>        impact.
>>         >
>>         > Sidenote: This is a situation where having an i/k corollary
>>        for other
>>         > types might be useful, or adding a type modifier like "const
>>        S" might
>>         > clarify the intention of opcodes.
>>         >
>>         >
>>         > On Thu, Dec 31, 2015 at 12:33 PM, Victor Lazzarini
>>         > >
>>        wrote:
>>         >> The reason is that chnget takes its channel name at init
>>        time, and then reads from
>>         >> it at k-time. If you change the channel name at k-time, it
>>        will not look into a different channel.
>>         >>
>>         >> Not quite sure whether it is a appropriate to change this
>>        behaviour, but it’s easy to do.
>>         >> ========================
>>         >> Dr Victor Lazzarini
>>         >> Dean of Arts, Celtic Studies and Philosophy,
>>         >> Maynooth University,
>>         >> Maynooth, Co Kildare, Ireland
>>         >> Tel: 00 353 7086936
>>         >> Fax: 00 353 1 7086952
>>         >>
>>         >>> On 31 Dec 2015, at 16:47, Rory Walsh >        > wrote:
>>         >>>
>>         >>> Hi Steven. You can see in the full example I posted that
>>        instrument 3 is not picking up the change to channel 'step1'.
>>         >>>
>>         >>> On 31 Dec 2015 15:37, "Steven Yi" >        > wrote:
>>         >>> On first glance it seems like the code should work.  What
>>        is happening
>>         >>> when you say it doesn't work?  Is it that only one value in
>>        the array
>>         >>> is set, or none are, or all are to the same value, or...?
>>         >>>
>>         >>>
>>         >>> On Thu, Dec 31, 2015 at 10:19 AM, Rory Walsh
>>        > wrote:
>>         >>>> Actually, that's not quite my point. What I'm trying to do
>>        is save myself
>>         >>>> from writing 100s of lines of code like this:
>>         >>>>
>>         >>>> k1 chnget "foo1"
>>         >>>> k2 chnget "foo2"
>>         >>>> k3 chnget "foo3"
>>         >>>> k4 chnget "foo4"
>>         >>>> k5 chnget "foo5"
>>         >>>> k6 chnget "foo6"
>>         >>>> k7 chnget "foo7"
>>         >>>> etc...
>>         >>>>
>>         >>>> I am looking for a way to do this in a loop. I can get it
>>        to work if I check
>>         >>>> only one channel on each k-cycle, but not if I want to
>>        check them all on
>>         >>>> each k-cycle.
>>         >>>>
>>         >>>> On 31 December 2015 at 15:04, Tarmo Johannes
>>         >>>> >        > wrote:
>>         >>>>>
>>         >>>>> Hi,
>>         >>>>>
>>         >>>>> I guess that reading from channels should be fast in Csound.
>>         >>>>> Maybe it is sprintfk that takes time? Can you try to fill
>>        an array of
>>         >>>>> string once with the channel names and use the channel
>>        names from the array
>>         >>>>> by index?
>>         >>>>>
>>         >>>>> Or can you use gk arrray instead of channels?
>>         >>>>>
>>         >>>>> Tamo
>>         >>>>>
>>         >>>>> 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh"
>>        >:
>>         >>>>>>
>>         >>>>>> Has anyone any suggestions on how best to check the
>>        values stored on a
>>         >>>>>> large numbers of channels on each k-cycle? I've been
>>        thwarted in my attempts
>>         >>>>>> to efficiently do this. I have an instrument that has
>>        100 channels, named
>>         >>>>>> "step1" up to "step100".  I would like to run a loop on
>>        each k-cycle from
>>         >>>>>> another instrument, and fill an array with the values of
>>        each of the
>>         >>>>>> channels but I can't seem to get it to work. Surely
>>        there is a quick and
>>         >>>>>> efficient way to do this? My latest attempt to do this
>>        is shown below, but
>>         >>>>>> doesn't work as I had hoped.
>>         >>>>>>
>>         >>>>>> kIndex=0
>>         >>>>>> kSteps[] init 100
>>         >>>>>>
>>         >>>>>> GET_VALUES:
>>         >>>>>> SChannel sprintfk "step%d", kIndex+1
>>         >>>>>> kSteps[kIndex] chnget SChannel
>>         >>>>>> kIndex = kIndex+1
>>         >>>>>> cggoto kIndex<100, GET_VALUES
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>> 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
>>         >>>
>>         >>> 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
>>         >
>>         > 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
> 
> 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

Thanks guys. You're right of course. I'll have to rethink this one..

So one thing I've noticed with this latest change is that if one calls performksmps() and then csoundRewindScore()[1] Csound complains and says that "slider" is an invalid channel name. If on the other hand I declare a string variable as the channel name [2] it works fine no matter how many times it gets rewound. 

[1]
instr 1
k1 chnget "slider"
endin

[2]
instr 1
SChannel init "rslider"
k1 chnget SChannel
endin

I use csoundRewindScore at the start of each Cabbage performance. I make one call to performKsmps() in my Cabbage constructor so that I can query all the info I need from any tables before creating my table widgets. I then rewind the score back to the start. From thereon in performKsmps() is called from the plugin's processing method. I guess I don't really need to rewind. I can't imagine anyone will even notice if the open k-cycle is muted, but it's true that some Cabbage users have outstandingly high resolution hearing(Brandstegg, McCurdy et al.). Actually, I guess now rewinding will causes clicks in many cases.   

On 1 January 2016 at 21:46, Rory Walsh <rorywalsh@ear.ie> wrote:

Putting the event within the metro block does trick. Nice one. With not a lot of code I build quite a nice step sequencer. 

On 1 January 2016 at 21:04, Rory Walsh <rorywalsh@ear.ie> wrote:

Thanks guys. You're right of course. I'll have to rethink this one..

On 1 Jan 2016 8:57 pm, "Victor Lazzarini" <Victor.Lazzarini@nuim.ie> wrote:

yes, you will keep re-triggering for one whole second on every k-cycle.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

> On 1 Jan 2016, at 20:50, joachim heintz <jh@JOACHIMHEINTZ.DE> wrote:
>
> i think this is because you set kRow=0 at the beginning. once a second kColumn becomes zero, too, and in this second, it will always trigger instr 1000.
>
> cheers -
>       j
>
>
> On 01/01/16 21:20, Rory Walsh wrote:
>> So now I've hit the next hurdle! I would like to check the sate of each
>> channel, and if it is a 1, trigger an instrument. I've pasted the full
>> instrument code below. kRow is incrementing 10 times within each k
>> cycle, and kSteps[kRow+kColumn]==1 will only ever be true for a fraction
>> of a cycle every ten seconds. I was expecting to have only one instance
>> of instr1000 triggered, every ten second, as only one of the 100
>> channels ever gets set to 1? Any ideas?
>>
>> <CsoundSynthesizer>
>> <CsOptions>
>> -+rtaudio=jack -odac -b4096
>> </CsOptions>
>> <CsInstruments>
>> sr = 44100
>> ksmps = 64
>> nchnls = 2
>> 0dbfs=1
>>
>> ;============= set all 100 channels to 0 =======
>> instr 1;
>>     iCnt init 0
>>     until iCnt > 100 do
>>         S1 sprintf "step%d", iCnt+1
>>         chnset 0, S1
>>         iCnt=iCnt+1
>>     enduntil
>> endin
>>
>> ;============= constantly check channel states and trigger instr1000
>> accordingly =======
>> instr 2
>> kSteps[] init 100
>> kIndex = 0
>> kColumn init 0
>> kRow = 0
>>
>> ;increment columns
>> if metro(1)==1 then
>>     kColumn = kColumn<9 ? kColumn+1 : 0
>>     ;when column is 5 change the value stored on channel "step1" to 1
>>     if kColumn==5 then
>>         event "i", 3, 0, .1, 1
>>     endif
>> endif
>>
>> GET_STATES:
>>     kSteps[kIndex] chnget sprintfk("step%d", kIndex+1)
>>     kIndex = kIndex+1
>>     cggoto kIndex<100, GET_STATES
>>
>> TRIGGER_NOTES:
>>         if kSteps[kRow+kColumn]==1 then
>>             event "i", 1000, 0, .01,  100
>>             ;printks sprintfk("Column:%d, Row:%d", kColumn, kRow), 0
>>         endif
>>     kRow = kRow+10
>>     cggoto kRow<100, TRIGGER_NOTES
>>
>> endin
>>
>> ;============= triggered instrument =======
>> instr 1000
>>     print p4
>> endin
>>
>>
>> ;============= change state of channel ======
>> instr 3; change value of channel 'step1'
>>     SChannel sprintf "step%d", int(abs(p4))
>>     chnset 1, SChannel
>> endin
>>
>> </CsInstruments>
>> <CsScore>
>> i1 0 1
>> i2 1 1000
>> </CsScore>
>> </CsoundSynthesizer>
>>
>> On 1 January 2016 at 19:38, Rory Walsh <rorywalsh@ear.ie
>> <mailto:rorywalsh@ear.ie>> wrote:
>>
>>    Thanks Victor. Seems to be working here Victor. It would still be
>>    nice to have chnget work with arrays but this fix will do me fine!
>>
>>    On 1 January 2016 at 19:16, Victor Lazzarini
>>    <Victor.Lazzarini@nuim.ie <mailto:Victor.Lazzarini@nuim.ie>> wrote:
>>
>>        Ok, I’ve modified chnget:k to check for a change of channel
>>        names and in this case, to get the
>>        new channel pointer and the data. On normal operation the
>>        overhead is just an if() check.
>>        ========================
>>        Dr Victor Lazzarini
>>        Dean of Arts, Celtic Studies and Philosophy,
>>        Maynooth University,
>>        Maynooth, Co Kildare, Ireland
>>        Tel: 00 353 7086936
>>        Fax: 00 353 1 7086952
>>
>>         > On 31 Dec 2015, at 17:41, Steven Yi <stevenyi@gmail.com
>>        <mailto:stevenyi@gmail.com>> wrote:
>>         >
>>         > That makes a lot of sense.  If we do a lookup on each pass of the
>>         > channel name, that might make chnget more expensive, but it
>>        should be
>>         > backwards-compatible.  I imagine the way Rory was using it
>>        would be
>>         > the expected behavior, but I'm hesitant about the performance
>>        impact.
>>         >
>>         > Sidenote: This is a situation where having an i/k corollary
>>        for other
>>         > types might be useful, or adding a type modifier like "const
>>        S" might
>>         > clarify the intention of opcodes.
>>         >
>>         >
>>         > On Thu, Dec 31, 2015 at 12:33 PM, Victor Lazzarini
>>         > <Victor.Lazzarini@nuim.ie <mailto:Victor.Lazzarini@nuim.ie>>
>>        wrote:
>>         >> The reason is that chnget takes its channel name at init
>>        time, and then reads from
>>         >> it at k-time. If you change the channel name at k-time, it
>>        will not look into a different channel.
>>         >>
>>         >> Not quite sure whether it is a appropriate to change this
>>        behaviour, but it’s easy to do.
>>         >> ========================
>>         >> Dr Victor Lazzarini
>>         >> Dean of Arts, Celtic Studies and Philosophy,
>>         >> Maynooth University,
>>         >> Maynooth, Co Kildare, Ireland
>>         >> Tel: 00 353 7086936
>>         >> Fax: 00 353 1 7086952
>>         >>
>>         >>> On 31 Dec 2015, at 16:47, Rory Walsh <rorywalsh@EAR.IE
>>        <mailto:rorywalsh@EAR.IE>> wrote:
>>         >>>
>>         >>> Hi Steven. You can see in the full example I posted that
>>        instrument 3 is not picking up the change to channel 'step1'.
>>         >>>
>>         >>> On 31 Dec 2015 15:37, "Steven Yi" <stevenyi@gmail.com
>>        <mailto:stevenyi@gmail.com>> wrote:
>>         >>> On first glance it seems like the code should work.  What
>>        is happening
>>         >>> when you say it doesn't work?  Is it that only one value in
>>        the array
>>         >>> is set, or none are, or all are to the same value, or...?
>>         >>>
>>         >>>
>>         >>> On Thu, Dec 31, 2015 at 10:19 AM, Rory Walsh
>>        <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>> wrote:
>>         >>>> Actually, that's not quite my point. What I'm trying to do
>>        is save myself
>>         >>>> from writing 100s of lines of code like this:
>>         >>>>
>>         >>>> k1 chnget "foo1"
>>         >>>> k2 chnget "foo2"
>>         >>>> k3 chnget "foo3"
>>         >>>> k4 chnget "foo4"
>>         >>>> k5 chnget "foo5"
>>         >>>> k6 chnget "foo6"
>>         >>>> k7 chnget "foo7"
>>         >>>> etc...
>>         >>>>
>>         >>>> I am looking for a way to do this in a loop. I can get it
>>        to work if I check
>>         >>>> only one channel on each k-cycle, but not if I want to
>>        check them all on
>>         >>>> each k-cycle.
>>         >>>>
>>         >>>> On 31 December 2015 at 15:04, Tarmo Johannes
>>         >>>> <tarmo.johannes@otsakool.edu.ee
>>        <mailto:tarmo.johannes@otsakool.edu.ee>> wrote:
>>         >>>>>
>>         >>>>> Hi,
>>         >>>>>
>>         >>>>> I guess that reading from channels should be fast in Csound.
>>         >>>>> Maybe it is sprintfk that takes time? Can you try to fill
>>        an array of
>>         >>>>> string once with the channel names and use the channel
>>        names from the array
>>         >>>>> by index?
>>         >>>>>
>>         >>>>> Or can you use gk arrray instead of channels?
>>         >>>>>
>>         >>>>> Tamo
>>         >>>>>
>>         >>>>> 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh"
>>        <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>>:
>>         >>>>>>
>>         >>>>>> Has anyone any suggestions on how best to check the
>>        values stored on a
>>         >>>>>> large numbers of channels on each k-cycle? I've been
>>        thwarted in my attempts
>>         >>>>>> to efficiently do this. I have an instrument that has
>>        100 channels, named
>>         >>>>>> "step1" up to "step100".  I would like to run a loop on
>>        each k-cycle from
>>         >>>>>> another instrument, and fill an array with the values of
>>        each of the
>>         >>>>>> channels but I can't seem to get it to work. Surely
>>        there is a quick and
>>         >>>>>> efficient way to do this? My latest attempt to do this
>>        is shown below, but
>>         >>>>>> doesn't work as I had hoped.
>>         >>>>>>
>>         >>>>>> kIndex=0
>>         >>>>>> kSteps[] init 100
>>         >>>>>>
>>         >>>>>> GET_VALUES:
>>         >>>>>> SChannel sprintfk "step%d", kIndex+1
>>         >>>>>> kSteps[kIndex] chnget SChannel
>>         >>>>>> kIndex = kIndex+1
>>         >>>>>> cggoto kIndex<100, GET_VALUES
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>> Csound mailing list Csound@listserv.heanet.ie
>>        <mailto: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
>>        <mailto: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
>>        <mailto: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 <mailto: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
>>        <mailto: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 <mailto: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 <mailto: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 <mailto: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
>> <mailto: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

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

Gentle bump..

Gentle bump..

On 8 Jan 2016 12:34, "Rory Walsh" <rorywalsh@ear.ie> wrote:

Any movement on this? I very much like that I can now use arrays to check large numbers of channels, but it's not so nice that csoundRewindScore() doesn't work as it did before because it breaks Cabbage instruments. 

On 2 January 2016 at 11:49, Rory Walsh <rorywalsh@ear.ie> wrote:

It's an INIT ERROR.

On 2 January 2016 at 11:24, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:

Do you get a warning or an init error? It is being trapped in the channel check somewhere. I will see if a change of

checking method can fix it.

Victor Lazzarini

Dean of Arts, Celtic Studies, and Philosophy

Maynooth University

Ireland

On 2 Jan 2016, at 10:55, Rory Walsh <rorywalsh@EAR.IE> wrote:

So one thing I've noticed with this latest change is that if one calls performksmps() and then csoundRewindScore()[1] Csound complains and says that "slider" is an invalid channel name. If on the other hand I declare a string variable as the channel name [2] it works fine no matter how many times it gets rewound. 

[1]
instr 1
k1 chnget "slider"
endin

[2]
instr 1
SChannel init "rslider"
k1 chnget SChannel
endin

I use csoundRewindScore at the start of each Cabbage performance. I make one call to performKsmps() in my Cabbage constructor so that I can query all the info I need from any tables before creating my table widgets. I then rewind the score back to the start. From thereon in performKsmps() is called from the plugin's processing method. I guess I don't really need to rewind. I can't imagine anyone will even notice if the open k-cycle is muted, but it's true that some Cabbage users have outstandingly high resolution hearing(Brandstegg, McCurdy et al.). Actually, I guess now rewinding will causes clicks in many cases.   

On 1 January 2016 at 21:46, Rory Walsh <rorywalsh@ear.ie> wrote:

Putting the event within the metro block does trick. Nice one. With not a lot of code I build quite a nice step sequencer. 

On 1 January 2016 at 21:04, Rory Walsh <rorywalsh@ear.ie> wrote:

Thanks guys. You're right of course. I'll have to rethink this one..

On 1 Jan 2016 8:57 pm, "Victor Lazzarini" <Victor.Lazzarini@nuim.ie> wrote:

yes, you will keep re-triggering for one whole second on every k-cycle.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

> On 1 Jan 2016, at 20:50, joachim heintz <jh@JOACHIMHEINTZ.DE> wrote:
>
> i think this is because you set kRow=0 at the beginning. once a second kColumn becomes zero, too, and in this second, it will always trigger instr 1000.
>
> cheers -
>       j
>
>
> On 01/01/16 21:20, Rory Walsh wrote:
>> So now I've hit the next hurdle! I would like to check the sate of each
>> channel, and if it is a 1, trigger an instrument. I've pasted the full
>> instrument code below. kRow is incrementing 10 times within each k
>> cycle, and kSteps[kRow+kColumn]==1 will only ever be true for a fraction
>> of a cycle every ten seconds. I was expecting to have only one instance
>> of instr1000 triggered, every ten second, as only one of the 100
>> channels ever gets set to 1? Any ideas?
>>
>> <CsoundSynthesizer>
>> <CsOptions>
>> -+rtaudio=jack -odac -b4096
>> </CsOptions>
>> <CsInstruments>
>> sr = 44100
>> ksmps = 64
>> nchnls = 2
>> 0dbfs=1
>>
>> ;============= set all 100 channels to 0 =======
>> instr 1;
>>     iCnt init 0
>>     until iCnt > 100 do
>>         S1 sprintf "step%d", iCnt+1
>>         chnset 0, S1
>>         iCnt=iCnt+1
>>     enduntil
>> endin
>>
>> ;============= constantly check channel states and trigger instr1000
>> accordingly =======
>> instr 2
>> kSteps[] init 100
>> kIndex = 0
>> kColumn init 0
>> kRow = 0
>>
>> ;increment columns
>> if metro(1)==1 then
>>     kColumn = kColumn<9 ? kColumn+1 : 0
>>     ;when column is 5 change the value stored on channel "step1" to 1
>>     if kColumn==5 then
>>         event "i", 3, 0, .1, 1
>>     endif
>> endif
>>
>> GET_STATES:
>>     kSteps[kIndex] chnget sprintfk("step%d", kIndex+1)
>>     kIndex = kIndex+1
>>     cggoto kIndex<100, GET_STATES
>>
>> TRIGGER_NOTES:
>>         if kSteps[kRow+kColumn]==1 then
>>             event "i", 1000, 0, .01,  100
>>             ;printks sprintfk("Column:%d, Row:%d", kColumn, kRow), 0
>>         endif
>>     kRow = kRow+10
>>     cggoto kRow<100, TRIGGER_NOTES
>>
>> endin
>>
>> ;============= triggered instrument =======
>> instr 1000
>>     print p4
>> endin
>>
>>
>> ;============= change state of channel ======
>> instr 3; change value of channel 'step1'
>>     SChannel sprintf "step%d", int(abs(p4))
>>     chnset 1, SChannel
>> endin
>>
>> </CsInstruments>
>> <CsScore>
>> i1 0 1
>> i2 1 1000
>> </CsScore>
>> </CsoundSynthesizer>
>>
>> On 1 January 2016 at 19:38, Rory Walsh <rorywalsh@ear.ie
>> <mailto:rorywalsh@ear.ie>> wrote:
>>
>>    Thanks Victor. Seems to be working here Victor. It would still be
>>    nice to have chnget work with arrays but this fix will do me fine!
>>
>>    On 1 January 2016 at 19:16, Victor Lazzarini
>>    <Victor.Lazzarini@nuim.ie <mailto:Victor.Lazzarini@nuim.ie>> wrote:
>>
>>        Ok, I’ve modified chnget:k to check for a change of channel
>>        names and in this case, to get the
>>        new channel pointer and the data. On normal operation the
>>        overhead is just an if() check.
>>        ========================
>>        Dr Victor Lazzarini
>>        Dean of Arts, Celtic Studies and Philosophy,
>>        Maynooth University,
>>        Maynooth, Co Kildare, Ireland
>>        Tel: 00 353 7086936
>>        Fax: 00 353 1 7086952
>>
>>         > On 31 Dec 2015, at 17:41, Steven Yi <stevenyi@gmail.com
>>        <mailto:stevenyi@gmail.com>> wrote:
>>         >
>>         > That makes a lot of sense.  If we do a lookup on each pass of the
>>         > channel name, that might make chnget more expensive, but it
>>        should be
>>         > backwards-compatible.  I imagine the way Rory was using it
>>        would be
>>         > the expected behavior, but I'm hesitant about the performance
>>        impact.
>>         >
>>         > Sidenote: This is a situation where having an i/k corollary
>>        for other
>>         > types might be useful, or adding a type modifier like "const
>>        S" might
>>         > clarify the intention of opcodes.
>>         >
>>         >
>>         > On Thu, Dec 31, 2015 at 12:33 PM, Victor Lazzarini
>>         > <Victor.Lazzarini@nuim.ie <mailto:Victor.Lazzarini@nuim.ie>>
>>        wrote:
>>         >> The reason is that chnget takes its channel name at init
>>        time, and then reads from
>>         >> it at k-time. If you change the channel name at k-time, it
>>        will not look into a different channel.
>>         >>
>>         >> Not quite sure whether it is a appropriate to change this
>>        behaviour, but it’s easy to do.
>>         >> ========================
>>         >> Dr Victor Lazzarini
>>         >> Dean of Arts, Celtic Studies and Philosophy,
>>         >> Maynooth University,
>>         >> Maynooth, Co Kildare, Ireland
>>         >> Tel: 00 353 7086936
>>         >> Fax: 00 353 1 7086952
>>         >>
>>         >>> On 31 Dec 2015, at 16:47, Rory Walsh <rorywalsh@EAR.IE
>>        <mailto:rorywalsh@EAR.IE>> wrote:
>>         >>>
>>         >>> Hi Steven. You can see in the full example I posted that
>>        instrument 3 is not picking up the change to channel 'step1'.
>>         >>>
>>         >>> On 31 Dec 2015 15:37, "Steven Yi" <stevenyi@gmail.com
>>        <mailto:stevenyi@gmail.com>> wrote:
>>         >>> On first glance it seems like the code should work.  What
>>        is happening
>>         >>> when you say it doesn't work?  Is it that only one value in
>>        the array
>>         >>> is set, or none are, or all are to the same value, or...?
>>         >>>
>>         >>>
>>         >>> On Thu, Dec 31, 2015 at 10:19 AM, Rory Walsh
>>        <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>> wrote:
>>         >>>> Actually, that's not quite my point. What I'm trying to do
>>        is save myself
>>         >>>> from writing 100s of lines of code like this:
>>         >>>>
>>         >>>> k1 chnget "foo1"
>>         >>>> k2 chnget "foo2"
>>         >>>> k3 chnget "foo3"
>>         >>>> k4 chnget "foo4"
>>         >>>> k5 chnget "foo5"
>>         >>>> k6 chnget "foo6"
>>         >>>> k7 chnget "foo7"
>>         >>>> etc...
>>         >>>>
>>         >>>> I am looking for a way to do this in a loop. I can get it
>>        to work if I check
>>         >>>> only one channel on each k-cycle, but not if I want to
>>        check them all on
>>         >>>> each k-cycle.
>>         >>>>
>>         >>>> On 31 December 2015 at 15:04, Tarmo Johannes
>>         >>>> <tarmo.johannes@otsakool.edu.ee
>>        <mailto:tarmo.johannes@otsakool.edu.ee>> wrote:
>>         >>>>>
>>         >>>>> Hi,
>>         >>>>>
>>         >>>>> I guess that reading from channels should be fast in Csound.
>>         >>>>> Maybe it is sprintfk that takes time? Can you try to fill
>>        an array of
>>         >>>>> string once with the channel names and use the channel
>>        names from the array
>>         >>>>> by index?
>>         >>>>>
>>         >>>>> Or can you use gk arrray instead of channels?
>>         >>>>>
>>         >>>>> Tamo
>>         >>>>>
>>         >>>>> 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh"
>>        <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>>:
>>         >>>>>>
>>         >>>>>> Has anyone any suggestions on how best to check the
>>        values stored on a
>>         >>>>>> large numbers of channels on each k-cycle? I've been
>>        thwarted in my attempts
>>         >>>>>> to efficiently do this. I have an instrument that has
>>        100 channels, named
>>         >>>>>> "step1" up to "step100".  I would like to run a loop on
>>        each k-cycle from
>>         >>>>>> another instrument, and fill an array with the values of
>>        each of the
>>         >>>>>> channels but I can't seem to get it to work. Surely
>>        there is a quick and
>>         >>>>>> efficient way to do this? My latest attempt to do this
>>        is shown below, but
>>         >>>>>> doesn't work as I had hoped.
>>         >>>>>>
>>         >>>>>> kIndex=0
>>         >>>>>> kSteps[] init 100
>>         >>>>>>
>>         >>>>>> GET_VALUES:
>>         >>>>>> SChannel sprintfk "step%d", kIndex+1
>>         >>>>>> kSteps[kIndex] chnget SChannel
>>         >>>>>> kIndex = kIndex+1
>>         >>>>>> cggoto kIndex<100, GET_VALUES
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>> Csound mailing list Csound@listserv.heanet.ie
>>        <mailto: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
>>        <mailto: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
>>        <mailto: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 <mailto: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
>>        <mailto: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 <mailto: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 <mailto: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 <mailto: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
>> <mailto: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

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

That you did sort, but it messed up rewinding scores when channels are used. It's that the breaks so many Cabbage instruments. See my earlier mails. You may have missed them. Note however that I haven't pulled from git since Sunday I think.

That you did sort, but it messed up rewinding scores when channels are used. It's that the breaks so many Cabbage instruments. See my earlier mails. You may have missed them. Note however that I haven't pulled from git since Sunday I think.

On 12 Jan 2016 20:28, "Victor Lazzarini" <Victor.Lazzarini@nuim.ie> wrote:

I think I fixed that already. Didn't I say? Chnget now check for name changes. 
In git. If not put in a ticket with an example CSD for me 
Victor Lazzarini

Dean of Arts, Celtic Studies, and Philosophy

Maynooth University

Ireland

On 12 Jan 2016, at 20:05, Rory Walsh <rorywalsh@EAR.IE> wrote:

Gentle bump..

On 8 Jan 2016 12:34, "Rory Walsh" <rorywalsh@ear.ie> wrote:

Any movement on this? I very much like that I can now use arrays to check large numbers of channels, but it's not so nice that csoundRewindScore() doesn't work as it did before because it breaks Cabbage instruments. 

On 2 January 2016 at 11:49, Rory Walsh <rorywalsh@ear.ie> wrote:

It's an INIT ERROR.

On 2 January 2016 at 11:24, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:

Do you get a warning or an init error? It is being trapped in the channel check somewhere. I will see if a change of

checking method can fix it.

Victor Lazzarini

Dean of Arts, Celtic Studies, and Philosophy

Maynooth University

Ireland

On 2 Jan 2016, at 10:55, Rory Walsh <rorywalsh@EAR.IE> wrote:

So one thing I've noticed with this latest change is that if one calls performksmps() and then csoundRewindScore()[1] Csound complains and says that "slider" is an invalid channel name. If on the other hand I declare a string variable as the channel name [2] it works fine no matter how many times it gets rewound. 

[1]
instr 1
k1 chnget "slider"
endin

[2]
instr 1
SChannel init "rslider"
k1 chnget SChannel
endin

I use csoundRewindScore at the start of each Cabbage performance. I make one call to performKsmps() in my Cabbage constructor so that I can query all the info I need from any tables before creating my table widgets. I then rewind the score back to the start. From thereon in performKsmps() is called from the plugin's processing method. I guess I don't really need to rewind. I can't imagine anyone will even notice if the open k-cycle is muted, but it's true that some Cabbage users have outstandingly high resolution hearing(Brandstegg, McCurdy et al.). Actually, I guess now rewinding will causes clicks in many cases.   

On 1 January 2016 at 21:46, Rory Walsh <rorywalsh@ear.ie> wrote:

Putting the event within the metro block does trick. Nice one. With not a lot of code I build quite a nice step sequencer. 

On 1 January 2016 at 21:04, Rory Walsh <rorywalsh@ear.ie> wrote:

Thanks guys. You're right of course. I'll have to rethink this one..

On 1 Jan 2016 8:57 pm, "Victor Lazzarini" <Victor.Lazzarini@nuim.ie> wrote:

yes, you will keep re-triggering for one whole second on every k-cycle.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

> On 1 Jan 2016, at 20:50, joachim heintz <jh@JOACHIMHEINTZ.DE> wrote:
>
> i think this is because you set kRow=0 at the beginning. once a second kColumn becomes zero, too, and in this second, it will always trigger instr 1000.
>
> cheers -
>       j
>
>
> On 01/01/16 21:20, Rory Walsh wrote:
>> So now I've hit the next hurdle! I would like to check the sate of each
>> channel, and if it is a 1, trigger an instrument. I've pasted the full
>> instrument code below. kRow is incrementing 10 times within each k
>> cycle, and kSteps[kRow+kColumn]==1 will only ever be true for a fraction
>> of a cycle every ten seconds. I was expecting to have only one instance
>> of instr1000 triggered, every ten second, as only one of the 100
>> channels ever gets set to 1? Any ideas?
>>
>> <CsoundSynthesizer>
>> <CsOptions>
>> -+rtaudio=jack -odac -b4096
>> </CsOptions>
>> <CsInstruments>
>> sr = 44100
>> ksmps = 64
>> nchnls = 2
>> 0dbfs=1
>>
>> ;============= set all 100 channels to 0 =======
>> instr 1;
>>     iCnt init 0
>>     until iCnt > 100 do
>>         S1 sprintf "step%d", iCnt+1
>>         chnset 0, S1
>>         iCnt=iCnt+1
>>     enduntil
>> endin
>>
>> ;============= constantly check channel states and trigger instr1000
>> accordingly =======
>> instr 2
>> kSteps[] init 100
>> kIndex = 0
>> kColumn init 0
>> kRow = 0
>>
>> ;increment columns
>> if metro(1)==1 then
>>     kColumn = kColumn<9 ? kColumn+1 : 0
>>     ;when column is 5 change the value stored on channel "step1" to 1
>>     if kColumn==5 then
>>         event "i", 3, 0, .1, 1
>>     endif
>> endif
>>
>> GET_STATES:
>>     kSteps[kIndex] chnget sprintfk("step%d", kIndex+1)
>>     kIndex = kIndex+1
>>     cggoto kIndex<100, GET_STATES
>>
>> TRIGGER_NOTES:
>>         if kSteps[kRow+kColumn]==1 then
>>             event "i", 1000, 0, .01,  100
>>             ;printks sprintfk("Column:%d, Row:%d", kColumn, kRow), 0
>>         endif
>>     kRow = kRow+10
>>     cggoto kRow<100, TRIGGER_NOTES
>>
>> endin
>>
>> ;============= triggered instrument =======
>> instr 1000
>>     print p4
>> endin
>>
>>
>> ;============= change state of channel ======
>> instr 3; change value of channel 'step1'
>>     SChannel sprintf "step%d", int(abs(p4))
>>     chnset 1, SChannel
>> endin
>>
>> </CsInstruments>
>> <CsScore>
>> i1 0 1
>> i2 1 1000
>> </CsScore>
>> </CsoundSynthesizer>
>>
>> On 1 January 2016 at 19:38, Rory Walsh <rorywalsh@ear.ie
>> <mailto:rorywalsh@ear.ie>> wrote:
>>
>>    Thanks Victor. Seems to be working here Victor. It would still be
>>    nice to have chnget work with arrays but this fix will do me fine!
>>
>>    On 1 January 2016 at 19:16, Victor Lazzarini
>>    <Victor.Lazzarini@nuim.ie <mailto:Victor.Lazzarini@nuim.ie>> wrote:
>>
>>        Ok, I’ve modified chnget:k to check for a change of channel
>>        names and in this case, to get the
>>        new channel pointer and the data. On normal operation the
>>        overhead is just an if() check.
>>        ========================
>>        Dr Victor Lazzarini
>>        Dean of Arts, Celtic Studies and Philosophy,
>>        Maynooth University,
>>        Maynooth, Co Kildare, Ireland
>>        Tel: 00 353 7086936
>>        Fax: 00 353 1 7086952
>>
>>         > On 31 Dec 2015, at 17:41, Steven Yi <stevenyi@gmail.com
>>        <mailto:stevenyi@gmail.com>> wrote:
>>         >
>>         > That makes a lot of sense.  If we do a lookup on each pass of the
>>         > channel name, that might make chnget more expensive, but it
>>        should be
>>         > backwards-compatible.  I imagine the way Rory was using it
>>        would be
>>         > the expected behavior, but I'm hesitant about the performance
>>        impact.
>>         >
>>         > Sidenote: This is a situation where having an i/k corollary
>>        for other
>>         > types might be useful, or adding a type modifier like "const
>>        S" might
>>         > clarify the intention of opcodes.
>>         >
>>         >
>>         > On Thu, Dec 31, 2015 at 12:33 PM, Victor Lazzarini
>>         > <Victor.Lazzarini@nuim.ie <mailto:Victor.Lazzarini@nuim.ie>>
>>        wrote:
>>         >> The reason is that chnget takes its channel name at init
>>        time, and then reads from
>>         >> it at k-time. If you change the channel name at k-time, it
>>        will not look into a different channel.
>>         >>
>>         >> Not quite sure whether it is a appropriate to change this
>>        behaviour, but it’s easy to do.
>>         >> ========================
>>         >> Dr Victor Lazzarini
>>         >> Dean of Arts, Celtic Studies and Philosophy,
>>         >> Maynooth University,
>>         >> Maynooth, Co Kildare, Ireland
>>         >> Tel: 00 353 7086936
>>         >> Fax: 00 353 1 7086952
>>         >>
>>         >>> On 31 Dec 2015, at 16:47, Rory Walsh <rorywalsh@EAR.IE
>>        <mailto:rorywalsh@EAR.IE>> wrote:
>>         >>>
>>         >>> Hi Steven. You can see in the full example I posted that
>>        instrument 3 is not picking up the change to channel 'step1'.
>>         >>>
>>         >>> On 31 Dec 2015 15:37, "Steven Yi" <stevenyi@gmail.com
>>        <mailto:stevenyi@gmail.com>> wrote:
>>         >>> On first glance it seems like the code should work.  What
>>        is happening
>>         >>> when you say it doesn't work?  Is it that only one value in
>>        the array
>>         >>> is set, or none are, or all are to the same value, or...?
>>         >>>
>>         >>>
>>         >>> On Thu, Dec 31, 2015 at 10:19 AM, Rory Walsh
>>        <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>> wrote:
>>         >>>> Actually, that's not quite my point. What I'm trying to do
>>        is save myself
>>         >>>> from writing 100s of lines of code like this:
>>         >>>>
>>         >>>> k1 chnget "foo1"
>>         >>>> k2 chnget "foo2"
>>         >>>> k3 chnget "foo3"
>>         >>>> k4 chnget "foo4"
>>         >>>> k5 chnget "foo5"
>>         >>>> k6 chnget "foo6"
>>         >>>> k7 chnget "foo7"
>>         >>>> etc...
>>         >>>>
>>         >>>> I am looking for a way to do this in a loop. I can get it
>>        to work if I check
>>         >>>> only one channel on each k-cycle, but not if I want to
>>        check them all on
>>         >>>> each k-cycle.
>>         >>>>
>>         >>>> On 31 December 2015 at 15:04, Tarmo Johannes
>>         >>>> <tarmo.johannes@otsakool.edu.ee
>>        <mailto:tarmo.johannes@otsakool.edu.ee>> wrote:
>>         >>>>>
>>         >>>>> Hi,
>>         >>>>>
>>         >>>>> I guess that reading from channels should be fast in Csound.
>>         >>>>> Maybe it is sprintfk that takes time? Can you try to fill
>>        an array of
>>         >>>>> string once with the channel names and use the channel
>>        names from the array
>>         >>>>> by index?
>>         >>>>>
>>         >>>>> Or can you use gk arrray instead of channels?
>>         >>>>>
>>         >>>>> Tamo
>>         >>>>>
>>         >>>>> 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh"
>>        <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>>:
>>         >>>>>>
>>         >>>>>> Has anyone any suggestions on how best to check the
>>        values stored on a
>>         >>>>>> large numbers of channels on each k-cycle? I've been
>>        thwarted in my attempts
>>         >>>>>> to efficiently do this. I have an instrument that has
>>        100 channels, named
>>         >>>>>> "step1" up to "step100".  I would like to run a loop on
>>        each k-cycle from
>>         >>>>>> another instrument, and fill an array with the values of
>>        each of the
>>         >>>>>> channels but I can't seem to get it to work. Surely
>>        there is a quick and
>>         >>>>>> efficient way to do this? My latest attempt to do this
>>        is shown below, but
>>         >>>>>> doesn't work as I had hoped.
>>         >>>>>>
>>         >>>>>> kIndex=0
>>         >>>>>> kSteps[] init 100
>>         >>>>>>
>>         >>>>>> GET_VALUES:
>>         >>>>>> SChannel sprintfk "step%d", kIndex+1
>>         >>>>>> kSteps[kIndex] chnget SChannel
>>         >>>>>> kIndex = kIndex+1
>>         >>>>>> cggoto kIndex<100, GET_VALUES
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>>
>>         >>>>>> Csound mailing list Csound@listserv.heanet.ie
>>        <mailto: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
>>        <mailto: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
>>        <mailto: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 <mailto: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
>>        <mailto: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 <mailto: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 <mailto: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 <mailto: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
>> <mailto: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

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

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

I will build crash tomorrow and prepare an example if the problem persists. Thanks.

I managed to make a test CSD and fixed it. In git develop now.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 12 Jan 2016, at 21:18, Rory Walsh  wrote:
> 
> I will build crash tomorrow and prepare an example if the problem persists. Thanks.
> 
> On 12 Jan 2016 21:05, "Victor Lazzarini"  wrote:
> There was a problem with audio channels that I fixed on Sunday, Joachim had reported. So what is exactly the problem? I thought rewinding was the original
> issue, which was fixed with checking for channel changes. 
> I will see what I can do, but it will be after  I fix the prints escaping problem, which looks
> like will involve rewriting code.
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
> On 12 Jan 2016, at 20:52, Rory Walsh  wrote:
> 
>> That you did sort, but it messed up rewinding scores when channels are used. It's that the breaks so many Cabbage instruments. See my earlier mails. You may have missed them. Note however that I haven't pulled from git since Sunday I think.
>> 
>> On 12 Jan 2016 20:28, "Victor Lazzarini"  wrote:
>> I think I fixed that already. Didn't I say? Chnget now check for name changes. 
>> In git. If not put in a ticket with an example CSD for me 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>> On 12 Jan 2016, at 20:05, Rory Walsh  wrote:
>> 
>>> Gentle bump..
>>> 
>>> On 8 Jan 2016 12:34, "Rory Walsh"  wrote:
>>> Any movement on this? I very much like that I can now use arrays to check large numbers of channels, but it's not so nice that csoundRewindScore() doesn't work as it did before because it breaks Cabbage instruments. 
>>> 
>>> On 2 January 2016 at 11:49, Rory Walsh  wrote:
>>> It's an INIT ERROR. 
>>> 
>>> On 2 January 2016 at 11:24, Victor Lazzarini  wrote:
>>> Do you get a warning or an init error? It is being trapped in the channel check somewhere. I will see if a change of
>>> checking method can fix it.
>>> 
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>> 
>>> On 2 Jan 2016, at 10:55, Rory Walsh  wrote:
>>> 
>>>> So one thing I've noticed with this latest change is that if one calls performksmps() and then csoundRewindScore()[1] Csound complains and says that "slider" is an invalid channel name. If on the other hand I declare a string variable as the channel name [2] it works fine no matter how many times it gets rewound.  
>>>> 
>>>> [1]
>>>> instr 1
>>>> k1 chnget "slider"
>>>> endin
>>>> 
>>>> [2]
>>>> instr 1
>>>> SChannel init "rslider"
>>>> k1 chnget SChannel
>>>> endin
>>>> 
>>>> I use csoundRewindScore at the start of each Cabbage performance. I make one call to performKsmps() in my Cabbage constructor so that I can query all the info I need from any tables before creating my table widgets. I then rewind the score back to the start. From thereon in performKsmps() is called from the plugin's processing method. I guess I don't really need to rewind. I can't imagine anyone will even notice if the open k-cycle is muted, but it's true that some Cabbage users have outstandingly high resolution hearing(Brandstegg, McCurdy et al.). Actually, I guess now rewinding will causes clicks in many cases.    
>>>> 
>>>> On 1 January 2016 at 21:46, Rory Walsh  wrote:
>>>> Putting the event within the metro block does trick. Nice one. With not a lot of code I build quite a nice step sequencer.  
>>>> 
>>>> On 1 January 2016 at 21:04, Rory Walsh  wrote:
>>>> Thanks guys. You're right of course. I'll have to rethink this one..
>>>> 
>>>> On 1 Jan 2016 8:57 pm, "Victor Lazzarini"  wrote:
>>>> yes, you will keep re-triggering for one whole second on every k-cycle.
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952
>>>> 
>>>> > On 1 Jan 2016, at 20:50, joachim heintz  wrote:
>>>> >
>>>> > i think this is because you set kRow=0 at the beginning. once a second kColumn becomes zero, too, and in this second, it will always trigger instr 1000.
>>>> >
>>>> > cheers -
>>>> >       j
>>>> >
>>>> >
>>>> > On 01/01/16 21:20, Rory Walsh wrote:
>>>> >> So now I've hit the next hurdle! I would like to check the sate of each
>>>> >> channel, and if it is a 1, trigger an instrument. I've pasted the full
>>>> >> instrument code below. kRow is incrementing 10 times within each k
>>>> >> cycle, and kSteps[kRow+kColumn]==1 will only ever be true for a fraction
>>>> >> of a cycle every ten seconds. I was expecting to have only one instance
>>>> >> of instr1000 triggered, every ten second, as only one of the 100
>>>> >> channels ever gets set to 1? Any ideas?
>>>> >>
>>>> >> 
>>>> >> 
>>>> >> -+rtaudio=jack -odac -b4096
>>>> >> 
>>>> >> 
>>>> >> sr = 44100
>>>> >> ksmps = 64
>>>> >> nchnls = 2
>>>> >> 0dbfs=1
>>>> >>
>>>> >> ;============= set all 100 channels to 0 =======
>>>> >> instr 1;
>>>> >>     iCnt init 0
>>>> >>     until iCnt > 100 do
>>>> >>         S1 sprintf "step%d", iCnt+1
>>>> >>         chnset 0, S1
>>>> >>         iCnt=iCnt+1
>>>> >>     enduntil
>>>> >> endin
>>>> >>
>>>> >> ;============= constantly check channel states and trigger instr1000
>>>> >> accordingly =======
>>>> >> instr 2
>>>> >> kSteps[] init 100
>>>> >> kIndex = 0
>>>> >> kColumn init 0
>>>> >> kRow = 0
>>>> >>
>>>> >> ;increment columns
>>>> >> if metro(1)==1 then
>>>> >>     kColumn = kColumn<9 ? kColumn+1 : 0
>>>> >>     ;when column is 5 change the value stored on channel "step1" to 1
>>>> >>     if kColumn==5 then
>>>> >>         event "i", 3, 0, .1, 1
>>>> >>     endif
>>>> >> endif
>>>> >>
>>>> >> GET_STATES:
>>>> >>     kSteps[kIndex] chnget sprintfk("step%d", kIndex+1)
>>>> >>     kIndex = kIndex+1
>>>> >>     cggoto kIndex<100, GET_STATES
>>>> >>
>>>> >> TRIGGER_NOTES:
>>>> >>         if kSteps[kRow+kColumn]==1 then
>>>> >>             event "i", 1000, 0, .01,  100
>>>> >>             ;printks sprintfk("Column:%d, Row:%d", kColumn, kRow), 0
>>>> >>         endif
>>>> >>     kRow = kRow+10
>>>> >>     cggoto kRow<100, TRIGGER_NOTES
>>>> >>
>>>> >> endin
>>>> >>
>>>> >> ;============= triggered instrument =======
>>>> >> instr 1000
>>>> >>     print p4
>>>> >> endin
>>>> >>
>>>> >>
>>>> >> ;============= change state of channel ======
>>>> >> instr 3; change value of channel 'step1'
>>>> >>     SChannel sprintf "step%d", int(abs(p4))
>>>> >>     chnset 1, SChannel
>>>> >> endin
>>>> >>
>>>> >> 
>>>> >> 
>>>> >> i1 0 1
>>>> >> i2 1 1000
>>>> >> 
>>>> >> 
>>>> >>
>>>> >> On 1 January 2016 at 19:38, Rory Walsh >>> >> > wrote:
>>>> >>
>>>> >>    Thanks Victor. Seems to be working here Victor. It would still be
>>>> >>    nice to have chnget work with arrays but this fix will do me fine!
>>>> >>
>>>> >>    On 1 January 2016 at 19:16, Victor Lazzarini
>>>> >>    > wrote:
>>>> >>
>>>> >>        Ok, I’ve modified chnget:k to check for a change of channel
>>>> >>        names and in this case, to get the
>>>> >>        new channel pointer and the data. On normal operation the
>>>> >>        overhead is just an if() check.
>>>> >>        ========================
>>>> >>        Dr Victor Lazzarini
>>>> >>        Dean of Arts, Celtic Studies and Philosophy,
>>>> >>        Maynooth University,
>>>> >>        Maynooth, Co Kildare, Ireland
>>>> >>        Tel: 00 353 7086936
>>>> >>        Fax: 00 353 1 7086952
>>>> >>
>>>> >>         > On 31 Dec 2015, at 17:41, Steven Yi >>> >>        > wrote:
>>>> >>         >
>>>> >>         > That makes a lot of sense.  If we do a lookup on each pass of the
>>>> >>         > channel name, that might make chnget more expensive, but it
>>>> >>        should be
>>>> >>         > backwards-compatible.  I imagine the way Rory was using it
>>>> >>        would be
>>>> >>         > the expected behavior, but I'm hesitant about the performance
>>>> >>        impact.
>>>> >>         >
>>>> >>         > Sidenote: This is a situation where having an i/k corollary
>>>> >>        for other
>>>> >>         > types might be useful, or adding a type modifier like "const
>>>> >>        S" might
>>>> >>         > clarify the intention of opcodes.
>>>> >>         >
>>>> >>         >
>>>> >>         > On Thu, Dec 31, 2015 at 12:33 PM, Victor Lazzarini
>>>> >>         > >
>>>> >>        wrote:
>>>> >>         >> The reason is that chnget takes its channel name at init
>>>> >>        time, and then reads from
>>>> >>         >> it at k-time. If you change the channel name at k-time, it
>>>> >>        will not look into a different channel.
>>>> >>         >>
>>>> >>         >> Not quite sure whether it is a appropriate to change this
>>>> >>        behaviour, but it’s easy to do.
>>>> >>         >> ========================
>>>> >>         >> Dr Victor Lazzarini
>>>> >>         >> Dean of Arts, Celtic Studies and Philosophy,
>>>> >>         >> Maynooth University,
>>>> >>         >> Maynooth, Co Kildare, Ireland
>>>> >>         >> Tel: 00 353 7086936
>>>> >>         >> Fax: 00 353 1 7086952
>>>> >>         >>
>>>> >>         >>> On 31 Dec 2015, at 16:47, Rory Walsh >>> >>        > wrote:
>>>> >>         >>>
>>>> >>         >>> Hi Steven. You can see in the full example I posted that
>>>> >>        instrument 3 is not picking up the change to channel 'step1'.
>>>> >>         >>>
>>>> >>         >>> On 31 Dec 2015 15:37, "Steven Yi" >>> >>        > wrote:
>>>> >>         >>> On first glance it seems like the code should work.  What
>>>> >>        is happening
>>>> >>         >>> when you say it doesn't work?  Is it that only one value in
>>>> >>        the array
>>>> >>         >>> is set, or none are, or all are to the same value, or...?
>>>> >>         >>>
>>>> >>         >>>
>>>> >>         >>> On Thu, Dec 31, 2015 at 10:19 AM, Rory Walsh
>>>> >>        > wrote:
>>>> >>         >>>> Actually, that's not quite my point. What I'm trying to do
>>>> >>        is save myself
>>>> >>         >>>> from writing 100s of lines of code like this:
>>>> >>         >>>>
>>>> >>         >>>> k1 chnget "foo1"
>>>> >>         >>>> k2 chnget "foo2"
>>>> >>         >>>> k3 chnget "foo3"
>>>> >>         >>>> k4 chnget "foo4"
>>>> >>         >>>> k5 chnget "foo5"
>>>> >>         >>>> k6 chnget "foo6"
>>>> >>         >>>> k7 chnget "foo7"
>>>> >>         >>>> etc...
>>>> >>         >>>>
>>>> >>         >>>> I am looking for a way to do this in a loop. I can get it
>>>> >>        to work if I check
>>>> >>         >>>> only one channel on each k-cycle, but not if I want to
>>>> >>        check them all on
>>>> >>         >>>> each k-cycle.
>>>> >>         >>>>
>>>> >>         >>>> On 31 December 2015 at 15:04, Tarmo Johannes
>>>> >>         >>>> >>> >>        > wrote:
>>>> >>         >>>>>
>>>> >>         >>>>> Hi,
>>>> >>         >>>>>
>>>> >>         >>>>> I guess that reading from channels should be fast in Csound.
>>>> >>         >>>>> Maybe it is sprintfk that takes time? Can you try to fill
>>>> >>        an array of
>>>> >>         >>>>> string once with the channel names and use the channel
>>>> >>        names from the array
>>>> >>         >>>>> by index?
>>>> >>         >>>>>
>>>> >>         >>>>> Or can you use gk arrray instead of channels?
>>>> >>         >>>>>
>>>> >>         >>>>> Tamo
>>>> >>         >>>>>
>>>> >>         >>>>> 31.12.2015 16:52 kirjutas kuupäeval "Rory Walsh"
>>>> >>        >:
>>>> >>         >>>>>>
>>>> >>         >>>>>> Has anyone any suggestions on how best to check the
>>>> >>        values stored on a
>>>> >>         >>>>>> large numbers of channels on each k-cycle? I've been
>>>> >>        thwarted in my attempts
>>>> >>         >>>>>> to efficiently do this. I have an instrument that has
>>>> >>        100 channels, named
>>>> >>         >>>>>> "step1" up to "step100".  I would like to run a loop on
>>>> >>        each k-cycle from
>>>> >>         >>>>>> another instrument, and fill an array with the values of
>>>> >>        each of the
>>>> >>         >>>>>> channels but I can't seem to get it to work. Surely
>>>> >>        there is a quick and
>>>> >>         >>>>>> efficient way to do this? My latest attempt to do this
>>>> >>        is shown below, but
>>>> >>         >>>>>> doesn't work as I had hoped.
>>>> >>         >>>>>>
>>>> >>         >>>>>> kIndex=0
>>>> >>         >>>>>> kSteps[] init 100
>>>> >>         >>>>>>
>>>> >>         >>>>>> GET_VALUES:
>>>> >>         >>>>>> SChannel sprintfk "step%d", kIndex+1
>>>> >>         >>>>>> kSteps[kIndex] chnget SChannel
>>>> >>         >>>>>> kIndex = kIndex+1
>>>> >>         >>>>>> cggoto kIndex<100, GET_VALUES
>>>> >>         >>>>>>
>>>> >>         >>>>>>
>>>> >>         >>>>>>
>>>> >>         >>>>>>
>>>> >>         >>>>>>
>>>> >>         >>>>>> 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
>>>> >>         >>>
>>>> >>         >>> 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
>>>> >>         >
>>>> >>         > 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
>>>> >
>>>> > 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
>>> 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
>> 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

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