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