I did not suggest the removal or incompatible change of
any opcodes. However, the current API functions for
invalue/outvalue may be deprecated if a new, more
generalized version is added that is not limited to
k-rate signals.

On Saturday 27 May 2006 00:07, Victor Lazzarini wrote:

> I don't think we should remove the channel opcodes, as
> they are quite important for a number of API projects
> under way. Doing this would just create more confusion.
> I have been using them for both control and strings
> data and they do the job for me. But I also think that
> we can't remove the invalue/outvalue, as they also have
> been used quite a lot (for instance: csoundapi~).
> 
> > 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