Steven,

Just to clarify one thing: the *only* reason why I placed a k-rate opcode 
within my i-rate if/then was because i needed to see the value of givar 
within the loop, i.e., to see how if/then was working. Indeed, it showed 
that the condition was not being evaluated as I wanted.

I'm trying to spawn an event on the "then" condition, without much luck. 
I'll probably need to use schedkwhen with a trigger mechanism instead.

Thanks to all for your helpful comments.

Art Hunkins

----- Original Message ----- 
From: "Steven Yi" 
To: 
Sent: Friday, February 17, 2012 5:33 PM
Subject: Re: [Csnd] gi variable evaluation?


Hi Art,

The reason Victor gave is correct, but may require more explanation.
On the whole, one should not ever mix i-time if-then's with any k-rate
code within it, as it will lead to this exact situation.

When an i-time if-then is evaluated, it is *only* evaluated at i-time.
 At performance time, Csound essentially goes right through. If-thens
are syntax sugar, and Csound will unroll it as an if-goto with labels.
 Also to note, while we may look at Csound code as having branches,
internally it is not a tree but a flat list of opcodes, with labels
used for jumping.  So imagine this:

if (ival != 2) then
printk kval
endif

becomes:
#b0 = (ival == 2)
cigoto #b0,  __label0
printk kval
__label0:


On the i-time pass, Csound goes through each opcode one-by-one.  It
will hit that cigoto (I think that's the opcode that gets put in) at
that time and then proceed to the label.  The printk doesn't happen,
but that's expected as it is supposed to print at performance time.
At performance time, the cigoto does nothing because it is an i-time
only opcode, and csound then proceeds to the printk and calls it's
performance function.  Even though logically you'll think "but ival is
equal to 0," it is only evaluated at that first pass.

This is why one should never mix k-rate code within i-time if-then's.
The solution is to cast an i-var to k-rate, to force k-rate
comparison, or use if-kgoto.  (I would need to check about
if-kgoto...).  Also, the danger in putting in k-rate code within the
loop is that i-time it *does* jump, and therefore your opcodes don't
get their init-functions called.  If they later get called during
performance time, those opcodes won't be initialized and you'll get
unexpected results.

To simplify then, one should always follow the rule that when using
if-then, always match up the code within the if-then with the rate of
the value used within the if comparison.  In general, it becomes
pretty natural once you follow the rule.

There is one case where there is some weird things going on, which is
when you recursively call UDO's and want to limit the number at i-time
as well as number called during performance time.  It's an edge case
though and likely not many people have run into it, but you
essentially have to use two sets of if-then's, one at i-time and
another at k-time.

Hopefully that should explain the issue!
steven



On Fri, Feb 17, 2012 at 10:17 PM, Art Hunkins  wrote:
> Victor,
>
> But the problem is with the if/then branch in instr 1. Since during k-time
> givar == 2, the branch should be taken and nothing should print. Part of
> instr 1 during this time (the printk) seems to think givar = 2, while
> another part (if/then) thinks it is some other value (probably 0?)
>
> And, as you point out, when instr 1 starts slightly later than instr 2, 
> the
> if/then construction acts correctly (realizing that givar ==2) and taking
> the branch. Why it/then works correctly with the delay, but not with a
> simultaneous start, remains a mystery to me.
>
> Art Hunkins
>
> ----- Original Message ----- From: "Victor Lazzarini"
> 
> To: 
> Sent: Friday, February 17, 2012 4:24 PM
> Subject: Re: [Csnd] gi variable evaluation?
>
>
>
> The reason is this:
>
> 1) if ... then is evaluated at i-time when gival == 0
> Since the condition is true, both print statements will be executed. At 
> this
> stage (initi-pass) only print is executed
>
> 2) instr 2 changes the value of gival to 2 at its init-pass
>
> 3) the printk statement now runs at performance time and correctly reads 
> the
> global var value (now 2).
>
> NB: if you start instr 1 1-kcycle after instr 2, nothing will print.
>
> Victor
> On 17 Feb 2012, at 20:54, Art Hunkins wrote:
>
>> I don't understand what is happening in the simple csd below:
>>
>> During the init pass, gival is initialized to 0, but instr 2 changes it 
>> to
>> 2. Meanwhile, instr 1 correctly evaluates it to 0, falling into the 
>> if/then
>> construction (print gival), the condition being true.
>>
>> During the k passes, instr 1, consistently prints (printk) gival as = 2,
>> as you'd expect - since instr 2 changed its value.
>>
>> However, *it should never have fallen into the if/then construction*; as
>> the condition is now false (gival == 2).
>>
>> If the if/then construction is changed to if/goto, the same evaluation
>> error occurs.
>>
>> This, BTW, is all with the old parser, Windows XP, Csound 5.06. (And of
>> course if instruments 1 and 2 are interchanged, all works as expected.)
>>
>> What's going on?
>>
>> Art Hunkins
>>
>>
>> 
>> 
>> -odac
>> 
>> 
>> sr = 44100
>> kr = 44100
>> nchnls = 1
>> gival init 0
>>
>> instr 1
>>
>> if gival != 2 then
>> print gival
>> printk .1, gival
>> endif
>> endin
>>
>> instr 2
>> gival = 2
>> endin
>>
>> 
>>
>> 
>> i1 0 1
>> i2 0 1
>>
>> e
>> 
>> 
>>
>>
>> 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"
>>
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
>
> 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"

=