Here is a more detailed explanation why the 'else' branch is always
run at i-time. The following orchestra code:

    if (cond) then
    ...
    else
    ...
    endif

is internally translated to something like:

    cngoto (cond), _else
    ...
    kgoto _endif
_else:
    ...
_endif:

'cngoto' is an opcode that jumps to the specified label if 'cond' is
not true; if the conditional is valid at i-time, it is evaluated both
at init and perf time, while if it is considered a "k-rate" conditional,
'cngoto' is a no-op at init time.
So, with an i-rate conditional, the 'else' branch is always run at i-time
because the 'kgoto' falls through to it. With a k-rate conditional, both
branches are always run at i-time because 'cngoto' falls through as well.

Now the question is why is a 'kgoto' used to skip the else branch ?
It is obvious that if the conditional is "k-rate" then initializing the
else stuff is always needed, but why is it not replaced with a 'goto'
if the conditional is "i-rate" ? Well, at the point in time when the
'else' is replaced with the kgoto/label pair, the parser does not know
the type of the conditional expression, as the if/then/else expansion is
done in splitline(), while the (cond) expression is parsed by express()
which does not know about the context where a particular expression is
used. This is also the reason why 'cngoto' determines the type of the
conditional at run-time and not at compile time. However, to have run-time
checks in else as well, it should somehow know the type of an argument of
an opcode elsewhere in the orchestra. Either way, the solution might be
non-trivial.

'ithen' is basically a hack to allow for i-time only conditionals.
It replaces the cngoto with a cogoto, and kgoto with a goto. However,
for some reason cogoto always jumps at performance time, so it will
then always take the 'else' branch and never the 'if'.

On Monday 06 February 2006 11:32, Istvan Varga wrote:

> On Monday 06 February 2006 09:39, Matt J. Ingalls wrote:
> 
> > it looks like there might be  a bug in csound 5.  the csound4 output looks 
> > right.
> 
> No, it does not. If you look more carefully, you will notice that in the
> Csound 4 output, the 'if' and 'elseif' branches are always executed, while
> the 'else' ones are never, regardless of the value of p4. Also, the report
> was done with an old version of Csound 4. With the latest 4.23 sources from
> CVS, its output is exactly identical to that of version 5.
> In fact, the current if/then/else code in Csound 5 is synchronized with
> your most recent changes to 4.23, and it is since then that the 'else'
> branch is always executed at i-time. 'ithen' was also added by you,
> apparently to work around this limitation.
> 
> > if i remember right, p-variables are treated as k-rate variables in  
> > conditionals.
> 
> No, they are i-rate conditionals. If you compile with -v, you should notice
> that the temporary boolean variables are of type 'b' and not 'B' (but maybe
> not in older versions).