Hi, Steven,

Thanks; you are surely correct.

The docs for "if" state:
     Note
      Note that if the condition uses a k-rate variable (for instance, "if 
kval > 0"), the if...goto or if...then statement will be ignored during the 
i-time pass. This allows for opcode initialization, even if the k-rate 
variable has already been assigned an appropriate value by an earlier init 
statement.



Interestingly, this behavior means - in my example - that certain opcodes do 
*not* get initialized.

Ultimately, in my code, the problem is the "goto end" line, in its init 
pass. Everything from there to the end of the instrument is uninitialized. 
This, in performance, results in note/event deletion!

Given this fact, I'd recommend to Andres that the following note be added to 
the "goto" doc:

"Note:
Beware of goto, as in: goto end. Its initialization pass will fail to 
initialize any intervening code. In performance, such code, if otherwise 
required, will cause deletion of the note/event. In such cases, substitute 
kgoto (as in: kgoto end)."

Part of my problem, strangely, was that I was running 5.06. It does not give 
the PERF ERROR you cite - even in verbose mode. V5.09 does! (I had no idea 
the note had been deleted, as otherwise the realtime performance runs to 
completion.) One more reason to run the latest versions, I guess.

Thanks again.

Art Hunkins

----- Original Message ----- 
From: "Steven Yi" 
To: 
Sent: Thursday, January 29, 2009 12:23 AM
Subject: [Csnd] Re: Problem with goto?


> Hi Art,
>
> I ran this and got:
>
> SECTION 1:
> new alloc for instr 1:
> PERF ERROR in instr 1: printk not initialised
>        printk  1       knum    0
>
> I think what is going on is that during the init pass, the knum > 0 is
> not evaluating as the parser I think will see that it is a k-rate
> comparison and will then use a krate version of "if".  So skipping
> that at init time, it then moves to the "goto end" line and then skips
> over initializing printk.  Then at performance time, the printk is not
> initialized so it fails.
>
> I changed the code to use if-then instead of if-goto, and the following 
> works:
>
>
> instr 1
>
> knum    init 10
>
> if knum > 0 then
>    printk 1, knum
> else
>    ; additional code goes here
> endif
>
> endin
>
>
> So I'm pretty sure that the explanation is correct, and it's a tricky
> bit of code as it involves understanding how the parser works with if
> statements to know what's going on.
>
> If anyone sees something off with this explanation, please feel to correct 
> me!
>
> steven
>
>
> On Wed, Jan 28, 2009 at 9:08 PM, Art Hunkins  wrote:
>> The simple .csd below does not render as I expect (the value of knum 
>> doesn't
>> print to the screen).
>>
>> When substituting "kgoto end" for "goto end", it renders as expected.
>>
>> I'm at a loss as to why the original doesn't work, especially when it
>> shouldn't seem to matter.
>>
>> I run into this "code block" frequently, when processing the output of
>> sensekey. I can easily program around it (including using kgoto instead 
>> of
>> goto), but it "bugs" me.
>>
>> And actually, I'm wondering if maybe it *is* a bug.
>>
>> At any rate, any explanation?
>>
>> Art Hunkins
>>
>> 
>> 
>> -odac0
>> 
>> 
>>
>> sr = 32000
>> ksmps = 100
>> nchnls = 2
>>
>> instr 1
>>
>> knum    = 10
>>       if knum > 0 goto next
>> ; additional code goes here
>>       goto end
>> next:
>> printk 1, knum
>>
>> end:    endin
>>
>> 
>> 
>>
>> i1 0 60
>> e
>>
>>
>> 
>> 
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

Done, I've added some text to this effect in the cvs manual.

Cheers,
Andrés

On Thu, Jan 29, 2009 at 12:57 PM, Art Hunkins  wrote:
> Hi, Steven,
>
> Thanks; you are surely correct.
>
> The docs for "if" state:
>    Note
>     Note that if the condition uses a k-rate variable (for instance, "if
> kval > 0"), the if...goto or if...then statement will be ignored during the
> i-time pass. This allows for opcode initialization, even if the k-rate
> variable has already been assigned an appropriate value by an earlier init
> statement.
>
>
>
> Interestingly, this behavior means - in my example - that certain opcodes do
> *not* get initialized.
>
> Ultimately, in my code, the problem is the "goto end" line, in its init
> pass. Everything from there to the end of the instrument is uninitialized.
> This, in performance, results in note/event deletion!
>
> Given this fact, I'd recommend to Andres that the following note be added to
> the "goto" doc:
>
> "Note:
> Beware of goto, as in: goto end. Its initialization pass will fail to
> initialize any intervening code. In performance, such code, if otherwise
> required, will cause deletion of the note/event. In such cases, substitute
> kgoto (as in: kgoto end)."
>
> Part of my problem, strangely, was that I was running 5.06. It does not give
> the PERF ERROR you cite - even in verbose mode. V5.09 does! (I had no idea
> the note had been deleted, as otherwise the realtime performance runs to
> completion.) One more reason to run the latest versions, I guess.
>
> Thanks again.
>
> Art Hunkins
>
> ----- Original Message ----- From: "Steven Yi" 
> To: 
> Sent: Thursday, January 29, 2009 12:23 AM
> Subject: [Csnd] Re: Problem with goto?
>
>
>> Hi Art,
>>
>> I ran this and got:
>>
>> SECTION 1:
>> new alloc for instr 1:
>> PERF ERROR in instr 1: printk not initialised
>>       printk  1       knum    0
>>
>> I think what is going on is that during the init pass, the knum > 0 is
>> not evaluating as the parser I think will see that it is a k-rate
>> comparison and will then use a krate version of "if".  So skipping
>> that at init time, it then moves to the "goto end" line and then skips
>> over initializing printk.  Then at performance time, the printk is not
>> initialized so it fails.
>>
>> I changed the code to use if-then instead of if-goto, and the following
>> works:
>>
>>
>> instr 1
>>
>> knum    init 10
>>
>> if knum > 0 then
>>   printk 1, knum
>> else
>>   ; additional code goes here
>> endif
>>
>> endin
>>
>>
>> So I'm pretty sure that the explanation is correct, and it's a tricky
>> bit of code as it involves understanding how the parser works with if
>> statements to know what's going on.
>>
>> If anyone sees something off with this explanation, please feel to correct
>> me!
>>
>> steven
>>
>>
>> On Wed, Jan 28, 2009 at 9:08 PM, Art Hunkins  wrote:
>>>
>>> The simple .csd below does not render as I expect (the value of knum
>>> doesn't
>>> print to the screen).
>>>
>>> When substituting "kgoto end" for "goto end", it renders as expected.
>>>
>>> I'm at a loss as to why the original doesn't work, especially when it
>>> shouldn't seem to matter.
>>>
>>> I run into this "code block" frequently, when processing the output of
>>> sensekey. I can easily program around it (including using kgoto instead
>>> of
>>> goto), but it "bugs" me.
>>>
>>> And actually, I'm wondering if maybe it *is* a bug.
>>>
>>> At any rate, any explanation?
>>>
>>> Art Hunkins
>>>
>>> 
>>> 
>>> -odac0
>>> 
>>> 
>>>
>>> sr = 32000
>>> ksmps = 100
>>> nchnls = 2
>>>
>>> instr 1
>>>
>>> knum    = 10
>>>      if knum > 0 goto next
>>> ; additional code goes here
>>>      goto end
>>> next:
>>> printk 1, knum
>>>
>>> end:    endin
>>>
>>> 
>>> 
>>>
>>> i1 0 60
>>> e
>>>
>>>
>>> 
>>> 
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>



-- 


Andrés