Did you try this using numbered instruments? I think the problem might be caused by the new
definition taking a different number. It is still a bug, though.
========================
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 28 Dec 2015, at 09:17, Hlöðver Sigurðsson  wrote:
> 
> Hi list, I've encountered an unprefered behaviour, not sure if it's easily fixable.
> 
> It's when I have one instrument for controling globals and another one performing audio tasks. That if I perform the API function evalCode (ctrl+alt+w in csoundqt I guess) on a audio performing instrument and then on the global instrument (that also is sending event_i with negative p3 (indefinite amount of time)). What happens, instead of k-rate globals changing the current instance of a running instrument, will instead create a new instance, despite using maxalloc to 1(and csound sends friendly warning that it's using the exact same instrument number (using named instruments)). I assume this is due to the fact that for every evalCode call, a new table is created and the old instrument instance continues to be running in the background for indefinite amount of time. But surprisingly a turnoff2 call will turn all instances off. So somehow turnoff2 knows that there's more than one instance running but the active opcode will not.
> 
> Will leave my code here, not sure if anyone will understand it or the context. But I guess I'm busted here trying to borrow some of Iain McCurdy's code (and this does not sound nearly as tb303, but it's a work in progress :) )
> 
> http://pastebin.com/DZpx2V8n
> 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

Im using numbered instruments in the later example I posted (as reply):


http://pastebin.com/uQuerbya

2015-12-28 11:17 GMT+01:00 Victor Lazzarini <Victor.Lazzarini@nuim.ie>:

Did you try this using numbered instruments? I think the problem might be caused by the new
definition taking a different number. It is still a bug, though.
========================
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 28 Dec 2015, at 09:17, Hlöðver Sigurðsson <hlolli@gmail.com> wrote:
>
> Hi list, I've encountered an unprefered behaviour, not sure if it's easily fixable.
>
> It's when I have one instrument for controling globals and another one performing audio tasks. That if I perform the API function evalCode (ctrl+alt+w in csoundqt I guess) on a audio performing instrument and then on the global instrument (that also is sending event_i with negative p3 (indefinite amount of time)). What happens, instead of k-rate globals changing the current instance of a running instrument, will instead create a new instance, despite using maxalloc to 1(and csound sends friendly warning that it's using the exact same instrument number (using named instruments)). I assume this is due to the fact that for every evalCode call, a new table is created and the old instrument instance continues to be running in the background for indefinite amount of time. But surprisingly a turnoff2 call will turn all instances off. So somehow turnoff2 knows that there's more than one instance running but the active opcode will not.
>
> Will leave my code here, not sure if anyone will understand it or the context. But I guess I'm busted here trying to borrow some of Iain McCurdy's code (and this does not sound nearly as tb303, but it's a work in progress :) )
>
> http://pastebin.com/DZpx2V8n

> 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 had a quick look at this. The way maxalloc works is by adding to the instrument definition a maximum
number of instances. When a new version of the instrument replaces the old one, that is cleared (it’s
a new definition). If however, in that compilation you have the maxalloc line, then it will set the maximum
allocation for that new definition.There might be an overlap between an instance of the old instrument with
a new instance of the new instrument, but after that, the new definition will be limited to the maximum 
defined.

In other words, maxalloc works per compilation.

With active, I am not quite sure what is going on (i need to investigate further), but it looks like
it works per compilation as well. So if you modify your code to:

 giactive init 0
instr 1
if giactive == 0 then
event_i "i", 2, 0, -1
endif
krand random 200, 400
gkfreq = i(krand)
print giactive
endin

instr 2
giactive active 2
asig poscil 0.3 , gkfreq
outs asig, asig
endin

and re-compile instr 2, you won’t see more than one concurrent instance (at least that is what
I seem to be getting).

========================
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 28 Dec 2015, at 12:01, Hlöðver Sigurðsson  wrote:
> 
> well, this demonstration can communicate the bug ok. Re-eavaluating instr 2 while 1 is sending messages results in the amplitude stacking up and ending out of range of few evals.
> 
> http://pastebin.com/pSU29gPX
> 
> 2015-12-28 12:15 GMT+01:00 Victor Lazzarini :
> Could you check if active limits the number of instances after the second compilation, or if it is no-op completely? I mean after the second instance you reported, can you launch others?
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
> On 28 Dec 2015, at 10:44, Hlöðver Sigurðsson  wrote:
> 
>> Im using numbered instruments in the later example I posted (as reply):
>> 
>> 
>> http://pastebin.com/uQuerbya
>> 
>> 
>> 2015-12-28 11:17 GMT+01:00 Victor Lazzarini :
>> Did you try this using numbered instruments? I think the problem might be caused by the new
>> definition taking a different number. It is still a bug, though.
>> ========================
>> 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 28 Dec 2015, at 09:17, Hlöðver Sigurðsson  wrote:
>> >
>> > Hi list, I've encountered an unprefered behaviour, not sure if it's easily fixable.
>> >
>> > It's when I have one instrument for controling globals and another one performing audio tasks. That if I perform the API function evalCode (ctrl+alt+w in csoundqt I guess) on a audio performing instrument and then on the global instrument (that also is sending event_i with negative p3 (indefinite amount of time)). What happens, instead of k-rate globals changing the current instance of a running instrument, will instead create a new instance, despite using maxalloc to 1(and csound sends friendly warning that it's using the exact same instrument number (using named instruments)). I assume this is due to the fact that for every evalCode call, a new table is created and the old instrument instance continues to be running in the background for indefinite amount of time. But surprisingly a turnoff2 call will turn all instances off. So somehow turnoff2 knows that there's more than one instance running but the active opcode will not.
>> >
>> > Will leave my code here, not sure if anyone will understand it or the context. But I guess I'm busted here trying to borrow some of Iain McCurdy's code (and this does not sound nearly as tb303, but it's a work in progress :) )
>> >
>> > http://pastebin.com/DZpx2V8n
>> > 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

A deeper look at active tells me that in your example what happens is this:

1) when the new code is evaluated, instr 2 gets a new definition is placed
on the instrument table, and this has no instances.
2) active returns 0 because it looks at the new definition.
3) once the new instance is started, active returns 1.

So in my modification of your example, active always returns 1 because it
is always called after the instrument is instantiated.

========================
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 28 Dec 2015, at 14:17, Victor Lazzarini  wrote:
> 
> Ok, I had a quick look at this. The way maxalloc works is by adding to the instrument definition a maximum
> number of instances. When a new version of the instrument replaces the old one, that is cleared (it’s
> a new definition). If however, in that compilation you have the maxalloc line, then it will set the maximum
> allocation for that new definition.There might be an overlap between an instance of the old instrument with
> a new instance of the new instrument, but after that, the new definition will be limited to the maximum 
> defined.
> 
> In other words, maxalloc works per compilation.
> 
> With active, I am not quite sure what is going on (i need to investigate further), but it looks like
> it works per compilation as well. So if you modify your code to:
> 
> giactive init 0
> instr 1
> if giactive == 0 then
> event_i "i", 2, 0, -1
> endif
> krand random 200, 400
> gkfreq = i(krand)
> print giactive
> endin
> 
> instr 2
> giactive active 2
> asig poscil 0.3 , gkfreq
> outs asig, asig
> endin
> 
> and re-compile instr 2, you won’t see more than one concurrent instance (at least that is what
> I seem to be getting).
> 
> ========================
> 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 28 Dec 2015, at 12:01, Hlöðver Sigurðsson  wrote:
>> 
>> well, this demonstration can communicate the bug ok. Re-eavaluating instr 2 while 1 is sending messages results in the amplitude stacking up and ending out of range of few evals.
>> 
>> http://pastebin.com/pSU29gPX
>> 
>> 2015-12-28 12:15 GMT+01:00 Victor Lazzarini :
>> Could you check if active limits the number of instances after the second compilation, or if it is no-op completely? I mean after the second instance you reported, can you launch others?
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>> On 28 Dec 2015, at 10:44, Hlöðver Sigurðsson  wrote:
>> 
>>> Im using numbered instruments in the later example I posted (as reply):
>>> 
>>> 
>>> http://pastebin.com/uQuerbya
>>> 
>>> 
>>> 2015-12-28 11:17 GMT+01:00 Victor Lazzarini :
>>> Did you try this using numbered instruments? I think the problem might be caused by the new
>>> definition taking a different number. It is still a bug, though.
>>> ========================
>>> 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 28 Dec 2015, at 09:17, Hlöðver Sigurðsson  wrote:
>>>> 
>>>> Hi list, I've encountered an unprefered behaviour, not sure if it's easily fixable.
>>>> 
>>>> It's when I have one instrument for controling globals and another one performing audio tasks. That if I perform the API function evalCode (ctrl+alt+w in csoundqt I guess) on a audio performing instrument and then on the global instrument (that also is sending event_i with negative p3 (indefinite amount of time)). What happens, instead of k-rate globals changing the current instance of a running instrument, will instead create a new instance, despite using maxalloc to 1(and csound sends friendly warning that it's using the exact same instrument number (using named instruments)). I assume this is due to the fact that for every evalCode call, a new table is created and the old instrument instance continues to be running in the background for indefinite amount of time. But surprisingly a turnoff2 call will turn all instances off. So somehow turnoff2 knows that there's more than one instance running but the active opcode will not.
>>>> 
>>>> Will leave my code here, not sure if anyone will understand it or the context. But I guess I'm busted here trying to borrow some of Iain McCurdy's code (and this does not sound nearly as tb303, but it's a work in progress :) )
>>>> 
>>>> http://pastebin.com/DZpx2V8n
>>>> 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 changed it so that newly-compiled instrument definitions inherit maxalloc and active values
from previously existing instances. It seems to fix the bug.

========================
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 28 Dec 2015, at 14:43, Victor Lazzarini  wrote:
> 
> A deeper look at active tells me that in your example what happens is this:
> 
> 1) when the new code is evaluated, instr 2 gets a new definition is placed
> on the instrument table, and this has no instances.
> 2) active returns 0 because it looks at the new definition.
> 3) once the new instance is started, active returns 1.
> 
> So in my modification of your example, active always returns 1 because it
> is always called after the instrument is instantiated.
> 
> ========================
> 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 28 Dec 2015, at 14:17, Victor Lazzarini  wrote:
>> 
>> Ok, I had a quick look at this. The way maxalloc works is by adding to the instrument definition a maximum
>> number of instances. When a new version of the instrument replaces the old one, that is cleared (it’s
>> a new definition). If however, in that compilation you have the maxalloc line, then it will set the maximum
>> allocation for that new definition.There might be an overlap between an instance of the old instrument with
>> a new instance of the new instrument, but after that, the new definition will be limited to the maximum 
>> defined.
>> 
>> In other words, maxalloc works per compilation.
>> 
>> With active, I am not quite sure what is going on (i need to investigate further), but it looks like
>> it works per compilation as well. So if you modify your code to:
>> 
>> giactive init 0
>> instr 1
>> if giactive == 0 then
>> event_i "i", 2, 0, -1
>> endif
>> krand random 200, 400
>> gkfreq = i(krand)
>> print giactive
>> endin
>> 
>> instr 2
>> giactive active 2
>> asig poscil 0.3 , gkfreq
>> outs asig, asig
>> endin
>> 
>> and re-compile instr 2, you won’t see more than one concurrent instance (at least that is what
>> I seem to be getting).
>> 
>> ========================
>> 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 28 Dec 2015, at 12:01, Hlöðver Sigurðsson  wrote:
>>> 
>>> well, this demonstration can communicate the bug ok. Re-eavaluating instr 2 while 1 is sending messages results in the amplitude stacking up and ending out of range of few evals.
>>> 
>>> http://pastebin.com/pSU29gPX
>>> 
>>> 2015-12-28 12:15 GMT+01:00 Victor Lazzarini :
>>> Could you check if active limits the number of instances after the second compilation, or if it is no-op completely? I mean after the second instance you reported, can you launch others?
>>> 
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>> 
>>> On 28 Dec 2015, at 10:44, Hlöðver Sigurðsson  wrote:
>>> 
>>>> Im using numbered instruments in the later example I posted (as reply):
>>>> 
>>>> 
>>>> http://pastebin.com/uQuerbya
>>>> 
>>>> 
>>>> 2015-12-28 11:17 GMT+01:00 Victor Lazzarini :
>>>> Did you try this using numbered instruments? I think the problem might be caused by the new
>>>> definition taking a different number. It is still a bug, though.
>>>> ========================
>>>> 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 28 Dec 2015, at 09:17, Hlöðver Sigurðsson  wrote:
>>>>> 
>>>>> Hi list, I've encountered an unprefered behaviour, not sure if it's easily fixable.
>>>>> 
>>>>> It's when I have one instrument for controling globals and another one performing audio tasks. That if I perform the API function evalCode (ctrl+alt+w in csoundqt I guess) on a audio performing instrument and then on the global instrument (that also is sending event_i with negative p3 (indefinite amount of time)). What happens, instead of k-rate globals changing the current instance of a running instrument, will instead create a new instance, despite using maxalloc to 1(and csound sends friendly warning that it's using the exact same instrument number (using named instruments)). I assume this is due to the fact that for every evalCode call, a new table is created and the old instrument instance continues to be running in the background for indefinite amount of time. But surprisingly a turnoff2 call will turn all instances off. So somehow turnoff2 knows that there's more than one instance running but the active opcode will not.
>>>>> 
>>>>> Will leave my code here, not sure if anyone will understand it or the context. But I guess I'm busted here trying to borrow some of Iain McCurdy's code (and this does not sound nearly as tb303, but it's a work in progress :) )
>>>>> 
>>>>> http://pastebin.com/DZpx2V8n
>>>>> 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

Very good! thanks so much!

I updated my csound and by counting the active from within the instrument 2 does work fine so it solves my problem. The active sure can't be used in instrument 1. So maybe good to document this as a tip for future pitfalls, if so happens someone organizes their instrument controls from another instrument (and you or anyone reading this has time to spare). Didn't try maxalloc method, but it's not part of this solution, only added that to try to fix this bug which laid mainly in the active opcode.

2015-12-28 16:03 GMT+01:00 Victor Lazzarini <Victor.Lazzarini@nuim.ie>:

Ok, I’ve changed it so that newly-compiled instrument definitions inherit maxalloc and active values
from previously existing instances. It seems to fix the bug.

========================
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 28 Dec 2015, at 14:43, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
>
> A deeper look at active tells me that in your example what happens is this:
>
> 1) when the new code is evaluated, instr 2 gets a new definition is placed
> on the instrument table, and this has no instances.
> 2) active returns 0 because it looks at the new definition.
> 3) once the new instance is started, active returns 1.
>
> So in my modification of your example, active always returns 1 because it
> is always called after the instrument is instantiated.
>
> ========================
> 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 28 Dec 2015, at 14:17, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
>>
>> Ok, I had a quick look at this. The way maxalloc works is by adding to the instrument definition a maximum
>> number of instances. When a new version of the instrument replaces the old one, that is cleared (it’s
>> a new definition). If however, in that compilation you have the maxalloc line, then it will set the maximum
>> allocation for that new definition.There might be an overlap between an instance of the old instrument with
>> a new instance of the new instrument, but after that, the new definition will be limited to the maximum
>> defined.
>>
>> In other words, maxalloc works per compilation.
>>
>> With active, I am not quite sure what is going on (i need to investigate further), but it looks like
>> it works per compilation as well. So if you modify your code to:
>>
>> giactive init 0
>> instr 1
>> if giactive == 0 then
>> event_i "i", 2, 0, -1
>> endif
>> krand random 200, 400
>> gkfreq = i(krand)
>> print giactive
>> endin
>>
>> instr 2
>> giactive active 2
>> asig poscil 0.3 , gkfreq
>> outs asig, asig
>> endin
>>
>> and re-compile instr 2, you won’t see more than one concurrent instance (at least that is what
>> I seem to be getting).
>>
>> ========================
>> 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 28 Dec 2015, at 12:01, Hlöðver Sigurðsson <hlolli@gmail.com> wrote:
>>>
>>> well, this demonstration can communicate the bug ok. Re-eavaluating instr 2 while 1 is sending messages results in the amplitude stacking up and ending out of range of few evals.
>>>
>>> http://pastebin.com/pSU29gPX
>>>
>>> 2015-12-28 12:15 GMT+01:00 Victor Lazzarini <Victor.Lazzarini@nuim.ie>:
>>> Could you check if active limits the number of instances after the second compilation, or if it is no-op completely? I mean after the second instance you reported, can you launch others?
>>>
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>>
>>> On 28 Dec 2015, at 10:44, Hlöðver Sigurðsson <hlolli@GMAIL.COM> wrote:
>>>
>>>> Im using numbered instruments in the later example I posted (as reply):
>>>>
>>>>
>>>> http://pastebin.com/uQuerbya
>>>>
>>>>
>>>> 2015-12-28 11:17 GMT+01:00 Victor Lazzarini <Victor.Lazzarini@nuim.ie>:
>>>> Did you try this using numbered instruments? I think the problem might be caused by the new
>>>> definition taking a different number. It is still a bug, though.
>>>> ========================
>>>> 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 28 Dec 2015, at 09:17, Hlöðver Sigurðsson <hlolli@gmail.com> wrote:
>>>>>
>>>>> Hi list, I've encountered an unprefered behaviour, not sure if it's easily fixable.
>>>>>
>>>>> It's when I have one instrument for controling globals and another one performing audio tasks. That if I perform the API function evalCode (ctrl+alt+w in csoundqt I guess) on a audio performing instrument and then on the global instrument (that also is sending event_i with negative p3 (indefinite amount of time)). What happens, instead of k-rate globals changing the current instance of a running instrument, will instead create a new instance, despite using maxalloc to 1(and csound sends friendly warning that it's using the exact same instrument number (using named instruments)). I assume this is due to the fact that for every evalCode call, a new table is created and the old instrument instance continues to be running in the background for indefinite amount of time. But surprisingly a turnoff2 call will turn all instances off. So somehow turnoff2 knows that there's more than one instance running but the active opcode will not.
>>>>>
>>>>> Will leave my code here, not sure if anyone will understand it or the context. But I guess I'm busted here trying to borrow some of Iain McCurdy's code (and this does not sound nearly as tb303, but it's a work in progress :) )
>>>>>
>>>>> http://pastebin.com/DZpx2V8n
>>>>> 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