while testing the floss manual csd files for the new release, i came 
across one example which worked before, but now lead to an error, unless 
i manually reset a counter to zero via the init opcode. so i am not sure 
whether the new behaviour is as expected, or whether some initialization 
is missing here.

this is what happens:
* instr 1 calls the udo PrtArr1k. when the udo is left, the kndx 
variable is 7.
* instr 2 calls the same udo. obviously, in the init pass, kArr[kndx] is 
evaluated and returns an error.
* the line
kndx       init       0
in the udo definition solves the problem.

i am wondering:
is it correct that kndx is not automatically reset to 0 when a new 
instance is called?

the csd is attached. best -

	joachim

I *think* what is happening is this:

* we changed kvar[indx] to operate at i-time as well as perf-time, so
that users can use i(kvar[indx])

* The call to kArr[kndx] is happening at i-time, though the message
says "PERF ERROR".

* Csound reuses previous instances of instruments if they are no
longer in use.  The previous instance has the value of 7 for kndx when
it is turned off. When the instrument is reused, because there is no
init, the kvar[kndx] during the init pass uses the 7 value and errors
out.

* Csound then segfaults.  This is a problem as Csound should not
segfault there, only have a perf error and kill that instance.


I can see a possible solution is that for the = opcode, to go ahead
and copy at i-time as well as perf-time (the line that has "kndx =
kstart").  That might solve the problem or it might not.  Another is
to say, always  use init to clear a var "just in case". I'm not
certain what is the best solution, or if there should be another
solution.

On Fri, Apr 11, 2014 at 4:38 PM, joachim heintz  wrote:
> while testing the floss manual csd files for the new release, i came across
> one example which worked before, but now lead to an error, unless i manually
> reset a counter to zero via the init opcode. so i am not sure whether the
> new behaviour is as expected, or whether some initialization is missing
> here.
>
> this is what happens:
> * instr 1 calls the udo PrtArr1k. when the udo is left, the kndx variable is
> 7.
> * instr 2 calls the same udo. obviously, in the init pass, kArr[kndx] is
> evaluated and returns an error.
> * the line
> kndx       init       0
> in the udo definition solves the problem.
>
> i am wondering:
> is it correct that kndx is not automatically reset to 0 when a new instance
> is called?
>
> the csd is attached. best -
>
>         joachim
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

hi steven -

yes, i think this is what happens. definitely the call to kArr[kndx] is 
happening at i-time. i inserted some k-print statements yesterday, and 
was surprised to see they not in action at all.

i am wondering whether it would be possible for csound to re-initialize 
all k-variables if a previous instance is being used. i think, a user 
who do not know about these insights of csound will not easily catch 
this error. he will not know that the second instance of the udo has to 
be treated in another way than the first one.

best -

	joachim


Am 11.04.2014 23:02, schrieb Steven Yi:
> I *think* what is happening is this:
>
> * we changed kvar[indx] to operate at i-time as well as perf-time, so
> that users can use i(kvar[indx])
>
> * The call to kArr[kndx] is happening at i-time, though the message
> says "PERF ERROR".
>
> * Csound reuses previous instances of instruments if they are no
> longer in use.  The previous instance has the value of 7 for kndx when
> it is turned off. When the instrument is reused, because there is no
> init, the kvar[kndx] during the init pass uses the 7 value and errors
> out.
>
> * Csound then segfaults.  This is a problem as Csound should not
> segfault there, only have a perf error and kill that instance.
>
>
> I can see a possible solution is that for the = opcode, to go ahead
> and copy at i-time as well as perf-time (the line that has "kndx =
> kstart").  That might solve the problem or it might not.  Another is
> to say, always  use init to clear a var "just in case". I'm not
> certain what is the best solution, or if there should be another
> solution.
>
> On Fri, Apr 11, 2014 at 4:38 PM, joachim heintz  wrote:
>> while testing the floss manual csd files for the new release, i came across
>> one example which worked before, but now lead to an error, unless i manually
>> reset a counter to zero via the init opcode. so i am not sure whether the
>> new behaviour is as expected, or whether some initialization is missing
>> here.
>>
>> this is what happens:
>> * instr 1 calls the udo PrtArr1k. when the udo is left, the kndx variable is
>> 7.
>> * instr 2 calls the same udo. obviously, in the init pass, kArr[kndx] is
>> evaluated and returns an error.
>> * the line
>> kndx       init       0
>> in the udo definition solves the problem.
>>
>> i am wondering:
>> is it correct that kndx is not automatically reset to 0 when a new instance
>> is called?
>>
>> the csd is attached. best -
>>
>>          joachim
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

For UDOs, there is a type “K” that runs at i and k time, maybe we can implement K[] for arrays, and that would
be in line with what has been before.

========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 12 Apr 2014, at 09:33, joachim heintz  wrote:

> hi steven -
> 
> yes, i think this is what happens. definitely the call to kArr[kndx] is 
> happening at i-time. i inserted some k-print statements yesterday, and 
> was surprised to see they not in action at all.
> 
> i am wondering whether it would be possible for csound to re-initialize 
> all k-variables if a previous instance is being used. i think, a user 
> who do not know about these insights of csound will not easily catch 
> this error. he will not know that the second instance of the udo has to 
> be treated in another way than the first one.
> 
> best -
> 
> 	joachim
> 
> 
> Am 11.04.2014 23:02, schrieb Steven Yi:
>> I *think* what is happening is this:
>> 
>> * we changed kvar[indx] to operate at i-time as well as perf-time, so
>> that users can use i(kvar[indx])
>> 
>> * The call to kArr[kndx] is happening at i-time, though the message
>> says "PERF ERROR".
>> 
>> * Csound reuses previous instances of instruments if they are no
>> longer in use.  The previous instance has the value of 7 for kndx when
>> it is turned off. When the instrument is reused, because there is no
>> init, the kvar[kndx] during the init pass uses the 7 value and errors
>> out.
>> 
>> * Csound then segfaults.  This is a problem as Csound should not
>> segfault there, only have a perf error and kill that instance.
>> 
>> 
>> I can see a possible solution is that for the = opcode, to go ahead
>> and copy at i-time as well as perf-time (the line that has "kndx =
>> kstart").  That might solve the problem or it might not.  Another is
>> to say, always  use init to clear a var "just in case". I'm not
>> certain what is the best solution, or if there should be another
>> solution.
>> 
>> On Fri, Apr 11, 2014 at 4:38 PM, joachim heintz  wrote:
>>> while testing the floss manual csd files for the new release, i came across
>>> one example which worked before, but now lead to an error, unless i manually
>>> reset a counter to zero via the init opcode. so i am not sure whether the
>>> new behaviour is as expected, or whether some initialization is missing
>>> here.
>>> 
>>> this is what happens:
>>> * instr 1 calls the udo PrtArr1k. when the udo is left, the kndx variable is
>>> 7.
>>> * instr 2 calls the same udo. obviously, in the init pass, kArr[kndx] is
>>> evaluated and returns an error.
>>> * the line
>>> kndx       init       0
>>> in the udo definition solves the problem.
>>> 
>>> i am wondering:
>>> is it correct that kndx is not automatically reset to 0 when a new instance
>>> is called?
>>> 
>>> the csd is attached. best -
>>> 
>>>         joachim
>>> 
>>> ------------------------------------------------------------------------------
>>> Put Bad Developers to Shame
>>> Dominate Development with Jenkins Continuous Integration
>>> Continuously Automate Build, Test & Deployment
>>> Start a new project now. Try Jenkins in the cloud.
>>> http://p.sf.net/sfu/13600_Cloudbees
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>> 
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
> 
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment 
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think the changes I made for the UDO Type system work made k and K
act the same and just copy at init-time all the time.  The idea is
that if you get garbage at i-time, it's the same as if you had an
uninitialized k-var, in that it's unknown what you'll get.  On the
other hand, if you do have a valid value (say, from a gk var) that you
copy at i-time, then you're good to go. The code that is written to
use the kvar then would be designed to use that value or not at
i-time.

I don't think having a difference at i or k-time would be good for
k-var's.  Joachim mentioned:

 "i am wondering whether it would be possible for csound to re-initialize
all k-variables if a previous instance is being used"

and I think we can't do that because previous instances are also used
for tied notes. In that case, we might break existing orchestras that
depend on previous instance values when tied.

I think too that when we introduced kvar[kval] to run at i-time for
i(kvar[kval]), we inadvertently also introduced a form of i-time
initialization of a k-var.  Making the = opcode for k-var's work at
i-time may make some prior code fail, but I think only if the prior
code was written in a very poor way, and so it might not affect much.

On Sat, Apr 12, 2014 at 5:18 AM, Victor Lazzarini
 wrote:
> For UDOs, there is a type "K" that runs at i and k time, maybe we can implement K[] for arrays, and that would
> be in line with what has been before.
>
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
>
>
>
>
> On 12 Apr 2014, at 09:33, joachim heintz  wrote:
>
>> hi steven -
>>
>> yes, i think this is what happens. definitely the call to kArr[kndx] is
>> happening at i-time. i inserted some k-print statements yesterday, and
>> was surprised to see they not in action at all.
>>
>> i am wondering whether it would be possible for csound to re-initialize
>> all k-variables if a previous instance is being used. i think, a user
>> who do not know about these insights of csound will not easily catch
>> this error. he will not know that the second instance of the udo has to
>> be treated in another way than the first one.
>>
>> best -
>>
>>       joachim
>>
>>
>> Am 11.04.2014 23:02, schrieb Steven Yi:
>>> I *think* what is happening is this:
>>>
>>> * we changed kvar[indx] to operate at i-time as well as perf-time, so
>>> that users can use i(kvar[indx])
>>>
>>> * The call to kArr[kndx] is happening at i-time, though the message
>>> says "PERF ERROR".
>>>
>>> * Csound reuses previous instances of instruments if they are no
>>> longer in use.  The previous instance has the value of 7 for kndx when
>>> it is turned off. When the instrument is reused, because there is no
>>> init, the kvar[kndx] during the init pass uses the 7 value and errors
>>> out.
>>>
>>> * Csound then segfaults.  This is a problem as Csound should not
>>> segfault there, only have a perf error and kill that instance.
>>>
>>>
>>> I can see a possible solution is that for the = opcode, to go ahead
>>> and copy at i-time as well as perf-time (the line that has "kndx =
>>> kstart").  That might solve the problem or it might not.  Another is
>>> to say, always  use init to clear a var "just in case". I'm not
>>> certain what is the best solution, or if there should be another
>>> solution.
>>>
>>> On Fri, Apr 11, 2014 at 4:38 PM, joachim heintz  wrote:
>>>> while testing the floss manual csd files for the new release, i came across
>>>> one example which worked before, but now lead to an error, unless i manually
>>>> reset a counter to zero via the init opcode. so i am not sure whether the
>>>> new behaviour is as expected, or whether some initialization is missing
>>>> here.
>>>>
>>>> this is what happens:
>>>> * instr 1 calls the udo PrtArr1k. when the udo is left, the kndx variable is
>>>> 7.
>>>> * instr 2 calls the same udo. obviously, in the init pass, kArr[kndx] is
>>>> evaluated and returns an error.
>>>> * the line
>>>> kndx       init       0
>>>> in the udo definition solves the problem.
>>>>
>>>> i am wondering:
>>>> is it correct that kndx is not automatically reset to 0 when a new instance
>>>> is called?
>>>>
>>>> the csd is attached. best -
>>>>
>>>>         joachim
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Put Bad Developers to Shame
>>>> Dominate Development with Jenkins Continuous Integration
>>>> Continuously Automate Build, Test & Deployment
>>>> Start a new project now. Try Jenkins in the cloud.
>>>> http://p.sf.net/sfu/13600_Cloudbees
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Put Bad Developers to Shame
>>> Dominate Development with Jenkins Continuous Integration
>>> Continuously Automate Build, Test & Deployment
>>> Start a new project now. Try Jenkins in the cloud.
>>> http://p.sf.net/sfu/13600_Cloudbees
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net