The first printk is not initialised so the triggers etc sare not set

Not done complete analysis yet but I am sure it is the random
initialisarion.  Perhaps we should trapnon-initialisation

==Johnff

> Hi,
>
> in an attempt to understand csound's control flow I've read this
> informative article http://www.goodeveca.net/ifs-buts-gotos.html. As
> you can see, it explains some at first sight bizarre behavior as
> caused by the separation of opcodes in perf and init time chains. I
> thought I have grasped the idea so I wrote a simple instr to
> corroborate it:
>
> 
>
> sr      = 48000
> kr      = 375
> nchnls  = 2
>
> instr 1
>
> igoto B
> A:
> printk .1, 1
> B:
> printk .1, 2
> END:
>
> endin
>
> 
>
> 
> i 1 0 1
> 
>
> I expected the output to be 1,2,1,2,1,2,..... as both printk would
> reside at the perf-chain while the igoto stayed at the init-chain.
> Well, the output was in fact this:
>
>  i   1 time     0.00267:     2.00000
>  i   1 time     0.10133:     2.00000
>  i   1 time     0.20267:     2.00000
>  i   1 time     0.30133:     2.00000
>  i   1 time     0.40267:     2.00000
>  i   1 time     0.50133:     2.00000
>  i   1 time     0.60267:     2.00000
>  i   1 time     0.70133:     2.00000
>  i   1 time     0.80267:     2.00000
>  i   1 time     0.90133:     2.00000
>
> The A-B "branch" was never executed. I thought: maybe opcodes that are
> not seen at init phase are considered non initialized and therefore
> not added to the perf-chain, or they're added but later ignored. So I
> run a little variation of my first instr:
>
> instr 1
> igoto B
> A:
> printk .1, 1
> kgoto END
> B:
> printk .1, 2
> END:
>
> Here I added a kgoto to the A-B branch that according to my adhoc
> extension of the two-chain theory shouldn't be executed  (it has
> somehow the same status of printk .1, 1, being in the A-B branch). But
> then the new hypothesis was also refuted by the example:
>
> NO printk output at all  => kgoto END was executed while the printk
> immediately above it didn't.
>
> Could you explain this brain melting behavior? Is this because printk
> was never initialized with its parameters (or was initialized with
> defaults parameters that avoid any printing) while kgoto doesn't need
> any initialization at all? Or are control opcodes given special
> treatment? Or whatever...
>
> Thank you in advance
> Regards
> -Carlos
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>

I have added  code to check for this case. Will be in next release
==John ff