Working with these cases a bit more, I've come to see the truth of what 
Steven was saying. For me it boils down to this: if you want an if/then 
condition (or if/goto for that matter) to be (re)evaluated at k-time, the if 
condition must include a k-variable. If it doesn't, the condition won't be 
reevaluated. If you are working with i-time variables, as Steven suggests, 
you can force a k-time reevaluation by casting the variable to k-rate.

A revised instrument 1 (that illustrates the difference in behavior) is:

instr 1

kval = gival
;if kval != 2 then
if gival != 2 then
print gival
printk .5, gival
endif
endin

Using "if gival" does not reevaluate; using "if kval" does reevaluate. So 
for me at least, case closed.

Thanks again to all who furnished input to this thread.

Art Hunkins
----- Original Message ----- 
From: "joachim heintz" 
To: 
Sent: Saturday, February 18, 2012 9:22 AM
Subject: Re: [Csnd] gi variable evaluation?


> hi art -
>
> you did really start an interesting thread ...
>
> i can't confirm that  "even if instr 1 starts a bit  *later* than instr
> 2, the if comparison in instr 1 still evaluates to 0 (or something other
> than 2) - executing the then condition" (see below, case 3).
>
> i think there are three cases. i have simplified your instrument
> slightly to this form:
>
> 
> 
> gival init 0
> instr 1
> if gival != 2 then
> printk .5, gival
> endif
> print gival
> endin
> instr 2
> gival = 2
> endin
> 
> 
> i1 0 1
> i2 0 1
> e
> 
> 
>
> CASE 1
> running the csd as here (or in your original post) evaluates the
> condition 'gival != 2' as true. so the gate to the 'then' statement is
> open, both: at the initialization path and at the performance time.
> the change of gival in instr 2 has no effect to this, because it's "too
> late" now. but it changes the value of gival from 0 to 2, so this will
> be printed during performance time in instr 1 via printk. (printk will
> ask for the actual value of gival at its printing time, not for the
> first value ever been there.) my output:
> instr 1:  gival = 0.000
> new alloc for instr 2:
> i   1 time     0.00023:     2.00000
> i   1 time     0.50000:     2.00000
> i   1 time     1.00000:     2.00000
>
> CASE 2
> changing the instrument numbers (instr 1 becomes instr 2 and vice versa)
> performs the statement 'gival = 2' first, because it now has the lower
> instrument number. so the if-condition is false, the gate stays closed,
> and the printk is not evaluated at all. this is my output:
> new alloc for instr 1:
> new alloc for instr 2:
> instr 2:  gival = 2.000
>
> CASE 3
> going back to the original numbering of instr 1 and instr 2 (as in the
> csd above), but now starting instr 1 after instr 2 (at least one k-cycle
> after instr 2, for instance 0.001). now instr 2 can change gival to 2,
> so when instr 1 starts, the expression 'gival != 2' is false, and the
> printk statement is not evaluated at all. this is my printout:
> new alloc for instr 2:
> B  0.000 ..  0.001 T  0.001 TT  0.001 M:      0.0
> new alloc for instr 1:
> instr 1:  gival = 2.000
> B  0.001 ..  1.000 T  1.000 TT  1.000 M:      0.0
> B  1.000 ..  1.001 T  1.001 TT  1.001 M:      0.0
>
> this is with the old parser (csound 5.16). i get the same result with
> the new parser. so, no bug / incompatibility, steven?!
>
> thanks, matt, for the condensed overview. i never ever used ithen, but
> it might be very useful in certain cases.
>
> joachim
>
>
> Am 18.02.2012 03:13, schrieb Art Hunkins:
>> I'm beginning to understand.
>>
>> It looks like you have to watch out for if/then's as much as for
>> if/goto's. (I was led to believe that if/then's were much "safer.")
>>
>> There is one further complicating factor: even if instr 1 starts a
>> bit *later* than instr 2, the if comparison in instr 1 still
>> evaluates to 0 (or something other than 2) - executing the then
>> condition.
>>
>> It must have to do with the global variable (givar) being evaluated
>> at *orch* initialization rather than at instrument initialization
>> time. I gather that orch initialization is done by instrument number
>> order rather than start time.
>>
>> Does this make sense?
>>
>> Art Hunkins
>>
>> ----- Original Message ----- From: "Steven Yi" 
>> To:  Sent: Friday, February 17, 2012 8:13
>> PM Subject: Re: [Csnd] gi variable evaluation?
>>
>>
>> Hmm, interesting!  I think I had either looked at this before,
>> forgot it, and remembered something wrong, or maybe just had it wrong
>> in my head all this time, and the side effect was that it got me the
>> right results. (!!)  I went and looked at the code.  In the old
>> parser, if-then uses cngoto, and if-ithen uses cogoto.  In the new
>> parser, it looks like it is only using cngoto (that's a bug that
>> should be fixed...).
>>
>> So, Matt's correct and the current Csound *does* what he says.
>>
>> However, I think I do understand what is going on with Art's
>> situation.  The value that is compared on the first pass is cached
>> as a boolean on that init-pass.  At that time, the value evaluated
>> to false, and that is stored in a synthetic b variable.  So going
>> back to the translated code:
>>
>> #b0 = (ival == 2) cngoto #b0, __label0 printk kval __label0:
>>
>> That #b0 stores the initial comparison.  Therefore, if it's true or
>> false at init-time, it's going to stay that way through
>> performance-time.  If the gival changes, it won't affect the value
>> used in the conditional check.
>>
>> This is great that you chimed in Matt, thanks!  Now I've got it
>> clearer in my head.
>>
>> (Rory: You may want to revise what you present! :P)
>>
>> steven
>>
>>
>> On Fri, Feb 17, 2012 at 11:58 PM, matt ingalls 
>> wrote:
>>> and just to clarify a bit more, i think this is how it should work
>>> (at least how it used to)
>>>
>>> ival init 0 if (ival != 0) then ; never gets here at i or k passes
>>> endif
>>>
>>> if (kval == kotherval) then ; always here at i-pass ; could be here
>>> or not at k-pass depending on conditional endif
>>>
>>> if (xval) ithen ; here during the i-pass (if conditional was true)
>>> ; never here during k-pass endif
>>>
>>> On Feb 17, 2012, at 3:47 PM, matt ingalls wrote:
>>>
>>>> steven: if this is how it works now, then this is a change from
>>>> the original implementation.
>>>>
>>>> if/then is supposed to be the equivalent to if/goto and as should
>>>> do the conditional at BOTH i and k rates.
>>>>
>>>>
>>>>
>>>> On Feb 17, 2012, at 2:33 PM, Steven Yi wrote:
>>>>
>>>>> if (ival != 2) then printk kval endif
>>>>>
>>>>> becomes: #b0 = (ival == 2) cigoto #b0, __label0 printk kval
>>>>> __label0:
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here To
>>>> unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe csound"
>>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here To unsubscribe,
>>> send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here To unsubscribe,
>> send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>> =
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here To unsubscribe,
>> send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"
>