m is differet as input (as i min) or outout (as in loscil).  Documented i 
Engine/entry1.c at the start

On Sun, 10 Dec 2017, Hlöðver Sigurðsson wrote:

> Not sure if I'm reporting bugs or just thinking out loud. But I'm noticing
> inconsistency with the documentation of many in/out types of opcodes vs what
> the command csound -z1 outputs. To name a few:
> `m`
> m seems to stand for optional-vararg i-rate, as with min and max opcodes this
> seems very clear
> min         a           ay
> min         i           im
> min         k           kz
> 
> amin min ain1, ain2 [, ain3] [, ain4] [...]
> 
> kmin min kin1, kin2 [, kin3] [, kin4] [...]
> 
> imin min iin1, iin2 [, iin3] [, iin4] [...]
> 
> Also clear when reading the comment section here:
> https://github.com/csound/csound/blob/develop/Engine/entry1.c#L27-L81
> 
> Sometimes the vararg count seems to be hard-coded:
> 
> monitor     mmmmmmmmmmmmmmmmmmmmmmmm (null)
> 
> Sometimes `m` stands for required a-rate
> mincer      mm          akkkkoo
> 
> asig mincer atimpt, kamp, kpitch, ktab, klock[,ifftsize,idecim]
> Somtimes `m` stands for required and opt-arg a-rate
> loscil      mm          xkjojoojoo
> 
> ar1 [,ar2] loscil xamp, kcps, ifn [, ibas] [, imod1] [, ibeg1] [, iend1] \
>       [, imod2] [, ibeg2] [, iend2]
> 
> `*`
> Star seems to be the ultimate wildcard, opt-arg, var-arg and var-rate
> ex.
> xout        (null)      *
> sometimes star is neither opt-arg, var-arg nor var-rate
> framebuffer *           *
> 
> kout[] framebuffer ain, isize
> 
> aout framebuffer kin, isize
> 
> Once is the var-arg count is hard coded
> xin         **************** (null)
> 
> 
> In general hard-coded var-arg count don't bother me as much as wrong rate
> meaning.
> 
> Are these metadata descriptor bugs or is the manual better source for
> programatic access to the in/out types of Csound opcodes?
> 
>

I should ave said that this system just grew from a few codes.  There are 
plans to revise it to make it more consistent but tat would be for a future 
csound7.  One o the boring technical difficulties is that the space for the 
outputs must be allocated before the inputs, and so must ave an explicit 
size.  The inputs can be open ended.  I have trouble explaining this and I 
think it is rather detailed for the general list, but...

The structure for ins, outs and locals for an opcode look like
struct {
     OPDS    h;		// structure for counts etc
     MYFLT   *out1,*out2, // two results eg stereo
     MYFLT   *in1, *in2, *in3; // or an array
     int     local1,.....
}
cearly wit no locals the ins can be arbitary size,.......  Further 
discussion on csound-dev please



On Sun, 10 Dec 2017, Hlöðver Sigurðsson wrote:

> Not sure if I'm reporting bugs or just thinking out loud. But I'm noticing
> inconsistency with the documentation of many in/out types of opcodes vs what
> the command csound -z1 outputs. To name a few:
> `m`
> m seems to stand for optional-vararg i-rate, as with min and max opcodes this
> seems very clear
> min         a           ay
> min         i           im
> min         k           kz
.....