Don't forget the Mixer opcodes. They are designed only for audio but they perhaps could either be extended to a more general type system using a variant data type, or integrated into another more general system.

Regards,
Mike

-----Original Message-----
From: Steven Yi 
Sent: Sep 11, 2005 11:56 PM
To: csound@lists.bath.ac.uk
Subject: Re: [Csnd] Instrument Static Variables, Completely encapsulated instruments

Hi Istvan,

I don't use the API, but the API functions seem like they'd cover any
usages i could imagine. As for putting all of the bus type opcodes
together, I think this could be an option:

-ZAK - redo opcodes to use named bus on backend with fixed names like
"ZAK_CHANNEL_" + channel number given, deprecate zakinit as it'd be
unnecessary, but leave it in as a stub opcode for compatibility

-chani/chano - perhaps the same measure as above

I don't know how big the performance hit would be moving from an
indexed array lookup of the channel (zak/chan) to string based map
lookup in the named channels. Is it worth having one set of opcodes
that can take either an integer or a string name, and the lookup would
be against two different data structures holding channels?

steven



On 9/11/05, Istvan Varga  wrote:
> Steven Yi wrote:
> 
> > I the functionality sounds good.  As for names, could we perhaps use a
> > common prefix so that the opcodes stay together in terms of manual and
> > my own memory? i.e.
> >
> > chnget
> > chnset
> > chn_k
> 
> Yes, this is a good idea.
> 
> > Also, just to get it straight in my head, will it be possible to
> > initialize a channel with chn_a and then setchn with an ival, as well
> > as read from a chn_k channel into an irate variable?
> 
> It may be possible for the opcodes to "cast" values in cases where
> doing so makes sense. Also, there are no separate types for 'k' and 'i',
> because these are both just single MYFLT values.
> 
> > chn seems a little short to remember, maybe it would be alright to
> > just use setchannel and getchannel?  And are these too close in name
> > to chani/chano?
> 
> Well, in fact the functionality is also very close, the only
> difference is that chani/chano are indexed by a number and are
> very similar to ZAK. I have chosen 'chn' to make the names short
> and save typing, but this can be changed.
> 
> Any comments on the API functions ?
> --
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>
--
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk



-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk