Hi All,

For opcodes that are polymorphic use dspace as 0xffff, 0xfffe, etc.,
this style of opcode is generally good for what cases?  I ended up
making a fluidCCi and fluidCCk opcode to run at different rates as I
didn't want to move the arguments around to have the differing rate
variable between the two to be the first argument; I imagine this is the
case for why many opcodes have extra versions for different rates versus
using the 0xffff, etc. version of polymorphism.  Is this correct?  I'd
also like to add this to csound.tex once this is explained.  (Apologies
all, I made an addition to csound.tex earlier and it now seems to die
when being processed by pdflatex.  It's a problem of needing to escape
characters, but since I don't know the rules of tex/latex I'm not sure
of a quick fix.  I should have it figured out and committed by end of
tonight though. =) )

Thanks!
steven

If you want an opcode that is polymorphic on its second argument, then
grab a code (a different code!) and add the code.  It is all in
Engine/rdorch.c and follow one of the others.  All very clear if you
read C.  Also document at start of entryX.c so we know what it means.
==John ffitch

Hi John,

Sounds good.  The opcode I made is actually only different on the fourth 
argument and as it works already with two different opcodes I might 
leave it at that.  But the idea to add more variants of 0xfffx to the 
parser wasn't something I thought about so will look at that.  I will 
try to draft something and get incorporated into the .tex and entryX.c 
files shortly.

Thanks!
steven


jpff@codemist.co.uk wrote:
> If you want an opcode that is polymorphic on its second argument, then
> grab a code (a different code!) and add the code.  It is all in
> Engine/rdorch.c and follow one of the others.  All very clear if you
> read C.  Also document at start of entryX.c so we know what it means.
> ==John ffitch
> 
> 
>