state maintenance within UDO

state maintenance within UDO

Date	2016-07-07 15:54
From	"C. R. Craig"
Subject	state maintenance within UDO
	I did a cursory search of the list archives and came up empty on this question for UDO’s. The only method I’ve found for maintaining state within a UDO between multiple invocations is something like opcode NOTE, i, i index xin index += 1 xout index endop instr TEST2 idur = p3 ifreq = p4 index init 0 index NOTE index printf_i "index=%i\n",1,index index NOTE index printf_i "index=%i\n",1,index index NOTE index printf_i "index=%i\n",1,index index NOTE index printf_i "index=%i\n",1,index endin This pushes the job of maintaining state into the calling instrument, not exactly what I want, which is a variable which is persistent over multiple invocations of the opcode. And there will be multiple simultaneous threads, of course, so a global variable is not a possibility. Here’s the real-life application: I’m building an instrument which uses an array of partials tables, which requires an index. I would like to be able to hide the operation of the index from the user, with each invocation of the instrument selecting the next partial table. I’ve thought of hacks like a global array indexed by something unique to the UDO (this array would hold the current value of the index for each instance of the opcode), but there must be a better way . . . Thanks, Robert 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

Date	2016-07-07 16:15
From	Victor Lazzarini
Subject	Re: state maintenance within UDO
	You have to think of an UDO exactly as you think of an opcode. Each separate mention of it in a code is a separate instance, with its own state. If you want one instance called many times, you need to put it in a loop. Victor Lazzarini Dean of Arts, Celtic Studies, and Philosophy Maynooth University Ireland > On 7 Jul 2016, at 15:54, C. R. Craig wrote: > > I did a cursory search of the list archives and came up empty on this question for UDO’s. The only method I’ve found for maintaining state within a UDO between multiple invocations is something like > > opcode NOTE, i, i > index xin > index += 1 > xout index > endop > > instr TEST2 > idur = p3 > ifreq = p4 > > index init 0 > > index NOTE index > printf_i "index=%i\n",1,index > index NOTE index > printf_i "index=%i\n",1,index > index NOTE index > printf_i "index=%i\n",1,index > index NOTE index > printf_i "index=%i\n",1,index > endin > > This pushes the job of maintaining state into the calling instrument, not exactly what I want, which is a variable which is persistent over multiple invocations of the opcode. And there will be multiple simultaneous threads, of course, so a global variable is not a possibility. > > Here’s the real-life application: I’m building an instrument which uses an array of partials tables, which requires an index. I would like to be able to hide the operation of the index from the user, with each invocation of the instrument selecting the next partial table. > > I’ve thought of hacks like a global array indexed by something unique to the UDO (this array would hold the current value of the index for each instance of the opcode), but there must be a better way . . . > > Thanks, > Robert > 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

Date	2016-07-07 17:07
From	"C. R. Craig"
Subject	Re: state maintenance within UDO
	I’ll stick with exposing the index to the user by returning and requiring it to be passed to the opcode. That’s is an interesting tidbit though, that each mention of an opcode is a separate instance and that using an opcode in a loop counts as one mention, resulting in one instance (with persistent state). Off to test the ramifications of this, just for fun :-) Thanks, Robert > On Jul 7, 2016, at 8:15 AM, Victor Lazzarini wrote: > > You have to think of an UDO exactly as you think of an opcode. Each separate mention of it in a code is a separate instance, with its own state. If you want one instance called many times, you need to put it in a loop. > > Victor Lazzarini > Dean of Arts, Celtic Studies, and Philosophy > Maynooth University > Ireland > >> On 7 Jul 2016, at 15:54, C. R. Craig wrote: >> >> I did a cursory search of the list archives and came up empty on this question for UDO’s. The only method I’ve found for maintaining state within a UDO between multiple invocations is something like >> >> opcode NOTE, i, i >> index xin >> index += 1 >> xout index >> endop >> >> instr TEST2 >> idur = p3 >> ifreq = p4 >> >> index init 0 >> >> index NOTE index >> printf_i "index=%i\n",1,index >> index NOTE index >> printf_i "index=%i\n",1,index >> index NOTE index >> printf_i "index=%i\n",1,index >> index NOTE index >> printf_i "index=%i\n",1,index >> endin >> >> This pushes the job of maintaining state into the calling instrument, not exactly what I want, which is a variable which is persistent over multiple invocations of the opcode. And there will be multiple simultaneous threads, of course, so a global variable is not a possibility. >> >> Here’s the real-life application: I’m building an instrument which uses an array of partials tables, which requires an index. I would like to be able to hide the operation of the index from the user, with each invocation of the instrument selecting the next partial table. >> >> I’ve thought of hacks like a global array indexed by something unique to the UDO (this array would hold the current value of the index for each instance of the opcode), but there must be a better way . . . >> >> Thanks, >> Robert >> 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

Date	2016-07-07 17:15
From	Victor Lazzarini
Subject	Re: state maintenance within UDO
	yes, and this also means that using opcodes in loops carry their own health warnings. Of course, there are stateless opcodes (which are effectively functions), in which case you can do anything you want. ======================== 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 7 Jul 2016, at 17:07, C. R. Craig wrote: > > I’ll stick with exposing the index to the user by returning and requiring it to be passed to the opcode. > > That’s is an interesting tidbit though, that each mention of an opcode is a separate instance and that using an opcode in a loop counts as one mention, resulting in one instance (with persistent state). > > Off to test the ramifications of this, just for fun :-) > > Thanks, > Robert > >> On Jul 7, 2016, at 8:15 AM, Victor Lazzarini wrote: >> >> You have to think of an UDO exactly as you think of an opcode. Each separate mention of it in a code is a separate instance, with its own state. If you want one instance called many times, you need to put it in a loop. >> >> Victor Lazzarini >> Dean of Arts, Celtic Studies, and Philosophy >> Maynooth University >> Ireland >> >>> On 7 Jul 2016, at 15:54, C. R. Craig wrote: >>> >>> I did a cursory search of the list archives and came up empty on this question for UDO’s. The only method I’ve found for maintaining state within a UDO between multiple invocations is something like >>> >>> opcode NOTE, i, i >>> index xin >>> index += 1 >>> xout index >>> endop >>> >>> instr TEST2 >>> idur = p3 >>> ifreq = p4 >>> >>> index init 0 >>> >>> index NOTE index >>> printf_i "index=%i\n",1,index >>> index NOTE index >>> printf_i "index=%i\n",1,index >>> index NOTE index >>> printf_i "index=%i\n",1,index >>> index NOTE index >>> printf_i "index=%i\n",1,index >>> endin >>> >>> This pushes the job of maintaining state into the calling instrument, not exactly what I want, which is a variable which is persistent over multiple invocations of the opcode. And there will be multiple simultaneous threads, of course, so a global variable is not a possibility. >>> >>> Here’s the real-life application: I’m building an instrument which uses an array of partials tables, which requires an index. I would like to be able to hide the operation of the index from the user, with each invocation of the instrument selecting the next partial table. >>> >>> I’ve thought of hacks like a global array indexed by something unique to the UDO (this array would hold the current value of the index for each instance of the opcode), but there must be a better way . . . >>> >>> Thanks, >>> Robert >>> 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

Date	2016-07-07 17:31
From	"C. R. Craig"
Subject	Re: state maintenance within UDO
Attachments	test_opcode_state.csd
	So this actually works the way I want already! I love it when things work out like this . . . Thanks, Robert 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 and the output i1 0.00000 <— this is the loop i1 1.00000 i1 2.00000 i1 3.00000 i1 4.00000 <— loop ends here i1 0.00000 <— first k-rate NOTE i1 0.00000 <— second k-rate NOTE i1 1.00000 and so on i1 1.00000 i1 2.00000 i1 2.00000 i1 3.00000 i1 3.00000 i1 4.00000 i1 4.00000 > On Jul 7, 2016, at 9:15 AM, Victor Lazzarini wrote: > > yes, and this also means that using opcodes in loops carry their own health warnings. Of course, there > are stateless opcodes (which are effectively functions), in which case you can do anything you want. > ======================== > 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 7 Jul 2016, at 17:07, C. R. Craig wrote: >> >> I’ll stick with exposing the index to the user by returning and requiring it to be passed to the opcode. >> >> That’s is an interesting tidbit though, that each mention of an opcode is a separate instance and that using an opcode in a loop counts as one mention, resulting in one instance (with persistent state). >> >> Off to test the ramifications of this, just for fun :-) >> >> Thanks, >> Robert >> >>> On Jul 7, 2016, at 8:15 AM, Victor Lazzarini wrote: >>> >>> You have to think of an UDO exactly as you think of an opcode. Each separate mention of it in a code is a separate instance, with its own state. If you want one instance called many times, you need to put it in a loop. >>> >>> Victor Lazzarini >>> Dean of Arts, Celtic Studies, and Philosophy >>> Maynooth University >>> Ireland >>> >>>> On 7 Jul 2016, at 15:54, C. R. Craig wrote: >>>> >>>> I did a cursory search of the list archives and came up empty on this question for UDO’s. The only method I’ve found for maintaining state within a UDO between multiple invocations is something like >>>> >>>> opcode NOTE, i, i >>>> index xin >>>> index += 1 >>>> xout index >>>> endop >>>> >>>> instr TEST2 >>>> idur = p3 >>>> ifreq = p4 >>>> >>>> index init 0 >>>> >>>> index NOTE index >>>> printf_i "index=%i\n",1,index >>>> index NOTE index >>>> printf_i "index=%i\n",1,index >>>> index NOTE index >>>> printf_i "index=%i\n",1,index >>>> index NOTE index >>>> printf_i "index=%i\n",1,index >>>> endin >>>> >>>> This pushes the job of maintaining state into the calling instrument, not exactly what I want, which is a variable which is persistent over multiple invocations of the opcode. And there will be multiple simultaneous threads, of course, so a global variable is not a possibility. >>>> >>>> Here’s the real-life application: I’m building an instrument which uses an array of partials tables, which requires an index. I would like to be able to hide the operation of the index from the user, with each invocation of the instrument selecting the next partial table. >>>> >>>> I’ve thought of hacks like a global array indexed by something unique to the UDO (this array would hold the current value of the index for each instance of the opcode), but there must be a better way . . . >>>> >>>> Thanks, >>>> Robert >>>> 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

Date	2016-07-07 17:34
From	Victor Lazzarini
Subject	Re: state maintenance within UDO
	Great. ======================== 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 7 Jul 2016, at 17:31, C. R. Craig wrote: > > So this actually works the way I want already! I love it when things work out like this . . . > > Thanks, > Robert > > > 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 > > > and the output > > i1 0.00000 <— this is the loop > i1 1.00000 > i1 2.00000 > i1 3.00000 > i1 4.00000 <— loop ends here > i1 0.00000 <— first k-rate NOTE > i1 0.00000 <— second k-rate NOTE > i1 1.00000 and so on > i1 1.00000 > i1 2.00000 > i1 2.00000 > i1 3.00000 > i1 3.00000 > i1 4.00000 > i1 4.00000 > >> On Jul 7, 2016, at 9:15 AM, Victor Lazzarini wrote: >> >> yes, and this also means that using opcodes in loops carry their own health warnings. Of course, there >> are stateless opcodes (which are effectively functions), in which case you can do anything you want. >> ======================== >> 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 7 Jul 2016, at 17:07, C. R. Craig wrote: >>> >>> I’ll stick with exposing the index to the user by returning and requiring it to be passed to the opcode. >>> >>> That’s is an interesting tidbit though, that each mention of an opcode is a separate instance and that using an opcode in a loop counts as one mention, resulting in one instance (with persistent state). >>> >>> Off to test the ramifications of this, just for fun :-) >>> >>> Thanks, >>> Robert >>> >>>> On Jul 7, 2016, at 8:15 AM, Victor Lazzarini wrote: >>>> >>>> You have to think of an UDO exactly as you think of an opcode. Each separate mention of it in a code is a separate instance, with its own state. If you want one instance called many times, you need to put it in a loop. >>>> >>>> Victor Lazzarini >>>> Dean of Arts, Celtic Studies, and Philosophy >>>> Maynooth University >>>> Ireland >>>> >>>>> On 7 Jul 2016, at 15:54, C. R. Craig wrote: >>>>> >>>>> I did a cursory search of the list archives and came up empty on this question for UDO’s. The only method I’ve found for maintaining state within a UDO between multiple invocations is something like >>>>> >>>>> opcode NOTE, i, i >>>>> index xin >>>>> index += 1 >>>>> xout index >>>>> endop >>>>> >>>>> instr TEST2 >>>>> idur = p3 >>>>> ifreq = p4 >>>>> >>>>> index init 0 >>>>> >>>>> index NOTE index >>>>> printf_i "index=%i\n",1,index >>>>> index NOTE index >>>>> printf_i "index=%i\n",1,index >>>>> index NOTE index >>>>> printf_i "index=%i\n",1,index >>>>> index NOTE index >>>>> printf_i "index=%i\n",1,index >>>>> endin >>>>> >>>>> This pushes the job of maintaining state into the calling instrument, not exactly what I want, which is a variable which is persistent over multiple invocations of the opcode. And there will be multiple simultaneous threads, of course, so a global variable is not a possibility. >>>>> >>>>> Here’s the real-life application: I’m building an instrument which uses an array of partials tables, which requires an index. I would like to be able to hide the operation of the index from the user, with each invocation of the instrument selecting the next partial table. >>>>> >>>>> I’ve thought of hacks like a global array indexed by something unique to the UDO (this array would hold the current value of the index for each instance of the opcode), but there must be a better way . . . >>>>> >>>>> Thanks, >>>>> Robert >>>>> 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

Date	2016-07-07 17:55
From	"C. R. Craig"
Subject	Re: state maintenance within UDO
	With the caveat that at i-rate, each invocation of the opcode in a loop is effectively a new instance, and no state is maintained. Or at least so it seems to me. Robert > On Jul 7, 2016, at 9:34 AM, Victor Lazzarini wrote: > > Great. > ======================== > 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 7 Jul 2016, at 17:31, C. R. Craig wrote: >> >> So this actually works the way I want already! I love it when things work out like this . . . >> >> Thanks, >> Robert >> >> >> 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 >> >> >> and the output >> >> i1 0.00000 <— this is the loop >> i1 1.00000 >> i1 2.00000 >> i1 3.00000 >> i1 4.00000 <— loop ends here >> i1 0.00000 <— first k-rate NOTE >> i1 0.00000 <— second k-rate NOTE >> i1 1.00000 and so on >> i1 1.00000 >> i1 2.00000 >> i1 2.00000 >> i1 3.00000 >> i1 3.00000 >> i1 4.00000 >> i1 4.00000 >> >>> On Jul 7, 2016, at 9:15 AM, Victor Lazzarini wrote: >>> >>> yes, and this also means that using opcodes in loops carry their own health warnings. Of course, there >>> are stateless opcodes (which are effectively functions), in which case you can do anything you want. >>> ======================== >>> 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 7 Jul 2016, at 17:07, C. R. Craig wrote: >>>> >>>> I’ll stick with exposing the index to the user by returning and requiring it to be passed to the opcode. >>>> >>>> That’s is an interesting tidbit though, that each mention of an opcode is a separate instance and that using an opcode in a loop counts as one mention, resulting in one instance (with persistent state). >>>> >>>> Off to test the ramifications of this, just for fun :-) >>>> >>>> Thanks, >>>> Robert >>>> >>>>> On Jul 7, 2016, at 8:15 AM, Victor Lazzarini wrote: >>>>> >>>>> You have to think of an UDO exactly as you think of an opcode. Each separate mention of it in a code is a separate instance, with its own state. If you want one instance called many times, you need to put it in a loop. >>>>> >>>>> Victor Lazzarini >>>>> Dean of Arts, Celtic Studies, and Philosophy >>>>> Maynooth University >>>>> Ireland >>>>> >>>>>> On 7 Jul 2016, at 15:54, C. R. Craig wrote: >>>>>> >>>>>> I did a cursory search of the list archives and came up empty on this question for UDO’s. The only method I’ve found for maintaining state within a UDO between multiple invocations is something like >>>>>> >>>>>> opcode NOTE, i, i >>>>>> index xin >>>>>> index += 1 >>>>>> xout index >>>>>> endop >>>>>> >>>>>> instr TEST2 >>>>>> idur = p3 >>>>>> ifreq = p4 >>>>>> >>>>>> index init 0 >>>>>> >>>>>> index NOTE index >>>>>> printf_i "index=%i\n",1,index >>>>>> index NOTE index >>>>>> printf_i "index=%i\n",1,index >>>>>> index NOTE index >>>>>> printf_i "index=%i\n",1,index >>>>>> index NOTE index >>>>>> printf_i "index=%i\n",1,index >>>>>> endin >>>>>> >>>>>> This pushes the job of maintaining state into the calling instrument, not exactly what I want, which is a variable which is persistent over multiple invocations of the opcode. And there will be multiple simultaneous threads, of course, so a global variable is not a possibility. >>>>>> >>>>>> Here’s the real-life application: I’m building an instrument which uses an array of partials tables, which requires an index. I would like to be able to hide the operation of the index from the user, with each invocation of the instrument selecting the next partial table. >>>>>> >>>>>> I’ve thought of hacks like a global array indexed by something unique to the UDO (this array would hold the current value of the index for each instance of the opcode), but there must be a better way . . . >>>>>> >>>>>> Thanks, >>>>>> Robert >>>>>> 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

Date	2016-07-08 10:42
From	Victor Lazzarini
Subject	Re: state maintenance within UDO
	It is only one instance, but somehow the state is not preserved. I’ll investigate. ======================== 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 7 Jul 2016, at 17:55, C. R. Craig wrote: > > With the caveat that at i-rate, each invocation of the opcode in a loop is effectively a new instance, and no state is maintained. Or at least so it seems to me. > > Robert > >> On Jul 7, 2016, at 9:34 AM, Victor Lazzarini wrote: >> >> Great. >> ======================== >> 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 7 Jul 2016, at 17:31, C. R. Craig wrote: >>> >>> So this actually works the way I want already! I love it when things work out like this . . . >>> >>> Thanks, >>> Robert >>> >>> >>> 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 >>> >>> >>> and the output >>> >>> i1 0.00000 <— this is the loop >>> i1 1.00000 >>> i1 2.00000 >>> i1 3.00000 >>> i1 4.00000 <— loop ends here >>> i1 0.00000 <— first k-rate NOTE >>> i1 0.00000 <— second k-rate NOTE >>> i1 1.00000 and so on >>> i1 1.00000 >>> i1 2.00000 >>> i1 2.00000 >>> i1 3.00000 >>> i1 3.00000 >>> i1 4.00000 >>> i1 4.00000 >>> >>>> On Jul 7, 2016, at 9:15 AM, Victor Lazzarini wrote: >>>> >>>> yes, and this also means that using opcodes in loops carry their own health warnings. Of course, there >>>> are stateless opcodes (which are effectively functions), in which case you can do anything you want. >>>> ======================== >>>> 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 7 Jul 2016, at 17:07, C. R. Craig wrote: >>>>> >>>>> I’ll stick with exposing the index to the user by returning and requiring it to be passed to the opcode. >>>>> >>>>> That’s is an interesting tidbit though, that each mention of an opcode is a separate instance and that using an opcode in a loop counts as one mention, resulting in one instance (with persistent state). >>>>> >>>>> Off to test the ramifications of this, just for fun :-) >>>>> >>>>> Thanks, >>>>> Robert >>>>> >>>>>> On Jul 7, 2016, at 8:15 AM, Victor Lazzarini wrote: >>>>>> >>>>>> You have to think of an UDO exactly as you think of an opcode. Each separate mention of it in a code is a separate instance, with its own state. If you want one instance called many times, you need to put it in a loop. >>>>>> >>>>>> Victor Lazzarini >>>>>> Dean of Arts, Celtic Studies, and Philosophy >>>>>> Maynooth University >>>>>> Ireland >>>>>> >>>>>>> On 7 Jul 2016, at 15:54, C. R. Craig wrote: >>>>>>> >>>>>>> I did a cursory search of the list archives and came up empty on this question for UDO’s. The only method I’ve found for maintaining state within a UDO between multiple invocations is something like >>>>>>> >>>>>>> opcode NOTE, i, i >>>>>>> index xin >>>>>>> index += 1 >>>>>>> xout index >>>>>>> endop >>>>>>> >>>>>>> instr TEST2 >>>>>>> idur = p3 >>>>>>> ifreq = p4 >>>>>>> >>>>>>> index init 0 >>>>>>> >>>>>>> index NOTE index >>>>>>> printf_i "index=%i\n",1,index >>>>>>> index NOTE index >>>>>>> printf_i "index=%i\n",1,index >>>>>>> index NOTE index >>>>>>> printf_i "index=%i\n",1,index >>>>>>> index NOTE index >>>>>>> printf_i "index=%i\n",1,index >>>>>>> endin >>>>>>> >>>>>>> This pushes the job of maintaining state into the calling instrument, not exactly what I want, which is a variable which is persistent over multiple invocations of the opcode. And there will be multiple simultaneous threads, of course, so a global variable is not a possibility. >>>>>>> >>>>>>> Here’s the real-life application: I’m building an instrument which uses an array of partials tables, which requires an index. I would like to be able to hide the operation of the index from the user, with each invocation of the instrument selecting the next partial table. >>>>>>> >>>>>>> I’ve thought of hacks like a global array indexed by something unique to the UDO (this array would hold the current value of the index for each instance of the opcode), but there must be a better way . . . >>>>>>> >>>>>>> Thanks, >>>>>>> Robert >>>>>>> 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

Date	2016-07-08 11:06
From	John
Subject	Re: state maintenance within UDO
	Surely at each time in the loop it does an initialisation do wiping out the previous values Sent from TypeApp On 8 Jul 2016, at 11:01, Victor Lazzarini <Victor.Lazzarini@NUIM.IE> wrote: It is only one instance, but somehow the state is not preserved. I’ll investigate. ======================== 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 7 Jul 2016, at 17:55, C. R. Craig <robert@CRAIG-WOODS.NET> wrote: With the caveat that at i-rate, each invocation of the opcode in a loop is effectively a new instance, and no state is maintained. Or at least so it seems to me. Robert On Jul 7, 2016, at 9:34 AM, Victor Lazzarini <Victor.Lazzarini@NUIM.IE> wrote: Great. ======================== 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 7 Jul 2016, at 17:31, C. R. Craig <robert@CRAIG-WOODS.NET> wrote: So this actually works the way I want already! I love it when things work out like this . . . Thanks, Robert 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 b ugs and features can be posted here <test_opcode_state.csd> and the output i1 0.00000 <— this is the loop i1 1.00000 i1 2.00000 i1 3.00000 i1 4.00000 <— loop ends here i1 0.00000 <— first k-rate NOTE i1 0.00000 <— second k-rate NOTE i1 1.00000 and so on i1 1.00000 i1 2.00000 i1 2.00000 i1 3.00000 i1 3.00000 i1 4.00000 i1 4.00000 On Jul 7, 2016, at 9:15 AM, Victor Lazzarini <Victor.Lazzarini@NUIM.IE> wrote: yes, and this also means that using opcodes in loops carry their own health warnings. Of course, there are stateless opcodes (which are effectively functions), in which case you can do anything you want. ======================== 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 7 Jul 2016, at 17:07, C. R. Craig <robert@CRAIG-WOODS.NET> wrote: I’ll stick with exposing the index to the user by returning and requiring it to be passed to the opcode. That’s is an interesting tidbit though, that each mention of an opcode is a separate instance and that using an opcode in a loop counts as one mention, resulting in one instance (with persistent state). Off to test the ramifications of this, just for fun :-) Thanks, Robert On Jul 7, 2016, at 8:15 AM, Victor Lazzarini <Victor.Lazzarini@NUIM.IE> wrote: You have to think of an UDO exactly as you think of an opcode. Each separate mention of it in a code is a separate instance, with its own state. If you want one instance called many times, you need to put it in a loop. Victor Lazzarini Dean of Arts, Celtic Studies, and Philosophy Maynooth University Ireland On 7 Jul 2016, at 15:54, C. R. Craig <robert@CRAIG-WOODS.NET> wrote: I did a cursory search of the list archives and came up empty on this question for UDO’s. The only method I’ve found for maintaining state within a UDO between multiple invocations is something like opcode NOTE, i, i index xin index += 1 xout index endop instr TEST2 idur = p3 ifreq = p4 index init 0 index NOTE index printf_i "index=%i\n",1,index index NOTE index printf_i "inde x=%i\n",1,index index NOTE index printf_i "index=%i\n",1,index index NOTE index printf_i "index=%i\n",1,index endin This pushes the job of maintaining state into the calling instrument, not exactly what I want, which is a variable which is persistent over multiple invocations of the opcode. And there will be multiple simultaneous threads, of course, so a global variable is not a possibility. Here’s the real-life application: I’m building an instrument which uses an array of partials tables, which requires an index. I would like to be able to hide the operation of the index from the user, with each invocation of the instrument selecting the next partial table. I’ve thought of hacks like a global array indexed by something unique to the UDO (this array would hold the current value of the index for each instance of the opcode), but there must be a better way . . . Thanks, Robert Csound mailing list Csound@lists erv.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 h ttps://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

Date	2016-07-08 11:07
From	Victor Lazzarini
Subject	Re: state maintenance within UDO
	Actually the state is preserved but if you put an UDO inside an i-time loop, all of its code will be executed over and over again, including any init calls. This might give the appearance that the state is not preserved, but it is. This example shows it: opcode Test,i,ii i1,ic xin if ic == 0 then i2 init 0 else i2 += i1 endif xout i2 endop instr 1 i1 init 0 ic init 0 i2 init 0 while i2 < 10 do i2 Test 1,ic print i2 ic = 1 od endin if we don’t protect the initialisation of the variable, the loop would never end and it would appear that we have multiple instances or that the state is not preserved. If you prevent the variable from initialising every time, you will see that the previous value is kept alright. ======================== 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 8 Jul 2016, at 10:42, Victor Lazzarini wrote: > > It is only one instance, but somehow the state is not preserved. I’ll investigate. > ======================== > 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 7 Jul 2016, at 17:55, C. R. Craig wrote: >> >> With the caveat that at i-rate, each invocation of the opcode in a loop is effectively a new instance, and no state is maintained. Or at least so it seems to me. >> >> Robert >> >>> On Jul 7, 2016, at 9:34 AM, Victor Lazzarini wrote: >>> >>> Great. >>> ======================== >>> 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 7 Jul 2016, at 17:31, C. R. Craig wrote: >>>> >>>> So this actually works the way I want already! I love it when things work out like this . . . >>>> >>>> Thanks, >>>> Robert >>>> >>>> >>>> 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 >>>> >>>> >>>> and the output >>>> >>>> i1 0.00000 <— this is the loop >>>> i1 1.00000 >>>> i1 2.00000 >>>> i1 3.00000 >>>> i1 4.00000 <— loop ends here >>>> i1 0.00000 <— first k-rate NOTE >>>> i1 0.00000 <— second k-rate NOTE >>>> i1 1.00000 and so on >>>> i1 1.00000 >>>> i1 2.00000 >>>> i1 2.00000 >>>> i1 3.00000 >>>> i1 3.00000 >>>> i1 4.00000 >>>> i1 4.00000 >>>> >>>>> On Jul 7, 2016, at 9:15 AM, Victor Lazzarini wrote: >>>>> >>>>> yes, and this also means that using opcodes in loops carry their own health warnings. Of course, there >>>>> are stateless opcodes (which are effectively functions), in which case you can do anything you want. >>>>> ======================== >>>>> 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 7 Jul 2016, at 17:07, C. R. Craig wrote: >>>>>> >>>>>> I’ll stick with exposing the index to the user by returning and requiring it to be passed to the opcode. >>>>>> >>>>>> That’s is an interesting tidbit though, that each mention of an opcode is a separate instance and that using an opcode in a loop counts as one mention, resulting in one instance (with persistent state). >>>>>> >>>>>> Off to test the ramifications of this, just for fun :-) >>>>>> >>>>>> Thanks, >>>>>> Robert >>>>>> >>>>>>> On Jul 7, 2016, at 8:15 AM, Victor Lazzarini wrote: >>>>>>> >>>>>>> You have to think of an UDO exactly as you think of an opcode. Each separate mention of it in a code is a separate instance, with its own state. If you want one instance called many times, you need to put it in a loop. >>>>>>> >>>>>>> Victor Lazzarini >>>>>>> Dean of Arts, Celtic Studies, and Philosophy >>>>>>> Maynooth University >>>>>>> Ireland >>>>>>> >>>>>>>> On 7 Jul 2016, at 15:54, C. R. Craig wrote: >>>>>>>> >>>>>>>> I did a cursory search of the list archives and came up empty on this question for UDO’s. The only method I’ve found for maintaining state within a UDO between multiple invocations is something like >>>>>>>> >>>>>>>> opcode NOTE, i, i >>>>>>>> index xin >>>>>>>> index += 1 >>>>>>>> xout index >>>>>>>> endop >>>>>>>> >>>>>>>> instr TEST2 >>>>>>>> idur = p3 >>>>>>>> ifreq = p4 >>>>>>>> >>>>>>>> index init 0 >>>>>>>> >>>>>>>> index NOTE index >>>>>>>> printf_i "index=%i\n",1,index >>>>>>>> index NOTE index >>>>>>>> printf_i "index=%i\n",1,index >>>>>>>> index NOTE index >>>>>>>> printf_i "index=%i\n",1,index >>>>>>>> index NOTE index >>>>>>>> printf_i "index=%i\n",1,index >>>>>>>> endin >>>>>>>> >>>>>>>> This pushes the job of maintaining state into the calling instrument, not exactly what I want, which is a variable which is persistent over multiple invocations of the opcode. And there will be multiple simultaneous threads, of course, so a global variable is not a possibility. >>>>>>>> >>>>>>>> Here’s the real-life application: I’m building an instrument which uses an array of partials tables, which requires an index. I would like to be able to hide the operation of the index from the user, with each invocation of the instrument selecting the next partial table. >>>>>>>> >>>>>>>> I’ve thought of hacks like a global array indexed by something unique to the UDO (this array would hold the current value of the index for each instance of the opcode), but there must be a better way . . . >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Robert >>>>>>>> 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

Date	2016-07-08 11:54
From	Victor Lazzarini
Subject	Re: state maintenance within UDO
	exactly. ======================== 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 8 Jul 2016, at 11:06, John wrote: > > Surely at each time in the loop it does an initialisation do wiping out the previous values > > > Sent from TypeApp > > > On 8 Jul 2016, at 11:01, Victor Lazzarini wrote: > It is only one instance, but somehow the state is not preserved. I’ll investigate. > ======================== > 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 7 Jul 2016, at 17:55, C. R. Craig wrote: > > With the caveat that at i-rate, each invocation of the opcode in a loop is effectively a new instance, and no state is maintained. Or at least so it seems to me. > > Robert > > On Jul 7, 2016, at 9:34 AM, Victor Lazzarini wrote: > > Great. > ======================== > 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 7 Jul 2016, at 17:31, C. R. Craig wrote: > > So this actually works the way I want already! I love it when things work out like this . . . > > Thanks, > Robert > > > 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 > > > and the output > > i1 0.00000 <— this is the loop > i1 1.00000 > i1 2.00000 > i1 > 3.00000 > > i1 4.00000 <— loop ends here > i1 0.00000 <— first k-rate NOTE > i1 0.00000 <— second k-rate NOTE > i1 1.00000 and so on > i1 1.00000 > i1 2.00000 > i1 2.00000 > i1 3.00000 > i1 3.00000 > i1 4.00000 > i1 4.00000 > > On Jul 7, 2016, at 9:15 AM, Victor Lazzarini wrote: > > yes, and this also means that using opcodes in loops carry their own health warnings. Of course, there > are stateless opcodes (which are effectively functions), in which case you can do anything you want. > ======================== > 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 7 Jul 2016, at 17:07, C. R. Craig wrote: > > I’ll stick with exposing the index to the user by returning and requiring it to be passed to the opcode. > > That’s is an interesting tidbit though, that each mention of an opcode is a separate instance and that using an opcode in a loop counts as one mention, resulting in one instance (with persistent state). > > Off to test the ramifications of this, just for fun :-) > > Thanks, > Robert > > On Jul 7, 2016, at 8:15 AM, Victor Lazzarini wrote: > > You have to think of an UDO exactly as you think of an opcode. Each separate mention of it in a code is a separate instance, with its own state. If you want one instance called many times, you > need to put it in a loop. > > > Victor Lazzarini > Dean of Arts, Celtic Studies, and Philosophy > Maynooth University > Ireland > > On 7 Jul 2016, at 15:54, C. R. Craig wrote: > > I did a cursory search of the list archives and came up empty on this question for UDO’s. The only method I’ve found for maintaining state within a UDO between multiple invocations is something like > > opcode NOTE, i, i > index xin > index += 1 > xout index > endop > > instr TEST2 > idur = p3 > ifreq = p4 > > index init 0 > > index NOTE index > printf_i "index=%i\n",1,index > index NOTE index > printf_i "index=%i\n",1,index > index NOTE index > printf_i "index=%i\n",1,index > index NOTE index > printf_i "index=%i\n",1,index > endin > > This pushes the job of maintaining state into the > calling instrument, not exactly what I want, which is a variable which is persistent over multiple invocations of the opcode. And there will be multiple simultaneous threads, of course, so a global variable is not a possibility. > > > Here’s the real-life application: I’m building an instrument which uses an array of partials tables, which requires an index. I would like to be able to hide the operation of the index from the user, with each invocation of the instrument selecting the next partial table. > > I’ve thought of hacks like a global array indexed by something unique to the UDO (this array would hold the current value of the index for each instance of the opcode), but there must be a better way . . . > > Thanks, > Robert > 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