Thanks John,

I asume the following is the "yes and no":

I understand your explanation of oscil. Are all multirate opcodes
implemented like this or would it be true to say that sometimes opcodes
dynamically select behavior (internally - using if()s or switch()es for
example) based on their input types - even though this information is
essentially static (could be determined at compile time)?

I am just thinking that if all of these determinations were always performed
at compile time (if they are not already), things might be faster (not that
they are slow now).

Would I be correct in saying that the current implementation is a trade off
between having a million leaf types for every opcode, and the penalty
incurred by checking parameter types at runtime. Or is there something more
subtle that I am missing.

The reason I ask is that I am trying to assess whether such runtime type
indentification techniques are part of csound, and hence whether that is a
reasonable (if not optimal) way of doing things.

Best regards,

Ross.

jpff writes:

>Well teh simple answer is yes and no.
>
>In some cases there is descrimination on the result of an opcode, and
>in some others there is descrimination on the first two arguments.
>
>For exampel oscil is really one of oscil_kk oscil_ka oscil_ak oscil_aa
>depending on answer and first argument.
>
>Similarly = is on of 4 versions (special, i, k or a)
>
>and so on.
>
>I have recently done some recoding in this area so this relationship
>is more explicit.
>
>Is that enough?
>
>==John ff