I agree. Also the three 'channel' systems are slightly
different:
with invalue/outvalue, it is up to the host to create and
manage
channels, whith Istvan's 'chn's,  the csound lib takes care
of
all that. And with John's chani,o  we have a numeric
interface.

Victor

>
> redundancy is not such a bad thing - it is an essential
> part of   incremental learning.
>
> On May 26, 2006, at 6:31 PM, matt ingalls wrote:
>
> > using the software bus is unacceptable for me in the
> > short term - i   just
> > do not have time/desire to restructure my program at
> > this point. i think i will add the hack i mentioned to
> > not change the API, and will make invalue/outvalue have
> optional input/output as strings. >
> > ==
> >
> > and i think what i was attempting to say in what you
> > quoted below is what i have always advocated, to reduce
> > all the in/out/chn/chan/outvalue/zak/etc family opcodes
> into just 2: >
> > xsig in Schan        ; Schan is a channel name or number
> >       out Schan, xsig
> >
> > of course keep all the "replaced" opcodes for backwards
> > compatibility [ internally they would probably just call
> "in" or "out" ] >
> > but i have stopped trying to push for a consolidated
> > "core opcodes" family, as it seems people aren't
> bothered by bloat like i am.. >
> > -m
> >
> > On May 26, 2006, at 1:15 PM, Istvan Varga wrote:
> >
> >> I may have missed some of these discussions, but the
> last time, >> when the 'chn' opcodes were added, you wrote
> about them "but i >> think in the end would be a
> replacement of invalue/outvalue and >> zak too really - as
> well as the proposed bussing system [ has >> that ever
> been finished? ] i'm fine with replacing with >>
> invalue/outvalue -- but i do think it would be VERY nice
> if zak >> and buss [ and even inch/outch ] were replaced
> as well, so we >> get ONE system". I interpreted this as
> invalue and outvalue not >> being very important: they
> should be kept for compatibility, but >> not extended.
> >>
> >> If using the software bus is really unacceptable, it is
> possible >> to:
> >>   - create new extended API functions for
> invalue/outvalue, and >>     optionally make the old
> k-rate only ones deprecated (i.e. >>     scheduled for
> removal when the API major version is >>     increased)
> >>   - implement hacks like the one described below that
> allow for >>     passing strings even with the already
> existing callbacks >>
> >> On Friday 26 May 2006 22:48, matt ingalls wrote:
> >>
> >>> If there is a way to enhance the current API
> >>> functs without breaking existing hosts, i am all for
> it - >>> but i can't think of a way other than what i
> currently do with >>> csound4, which is a hack by
> appending a string at the end >>> of the channel name and
> sending a special# for the value >>> to signal that the
> string is appended to the channel name. >>>
> >>> i'll look into enhancing the current invalue/outvalue
> opcodes. >>>
> >>> As far as duplicating efforts, in my view, MY WORK has
> been >>> duplicated!  invalue/outvalue has been in there
> since michael >>> and i merged our APIs (2001 was it?)
> >>>
> >>> Read the archives - i pleaded even BEGGED many times
> on the >>> dev list to expand the invalue/outvalue opcodes
> instead of created >>> an entirely new interface for the
> bus.  i offered to roll in my code >>> from
> >>> my frontend app that handles the creation and table of
> channels >>> MANY times and, except for Steven Yi, i was
> completely ignored. >>>
> >>> And now i am supposed to trash my work and
> re-implement the >>> same functionality with your software
> bus.  It is you who are   >>> wasting
> >>> my time!
> >>
> >>
> >> _______________________________________________
> >> Csound-devel mailing list
> >> Csound-devel@lists.sourceforge.net
> >>
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >> >
> >
> >
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> >
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net