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~).

Victor

>
> 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

invalue and outvalue are incredibly important to me and all my students.

they are simple and clear and we have been using them for years.

hundreds of MacCsound GUIs and csound~ max/msp patches (and I mean
hundreds) have been designed with them.

because many of the developers do not use Macintosh computers, they
might not realize how important matt ingalls opcodes and implementation
have been.

in the united states, most computer musicians use the macintosh.

at berklee, all 5000 music majors, are required to purchase macintosh  
computers
as one of their textbooks.

-dB

On May 26, 2006, at 6:07 PM, 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~).
>
> Victor
>
>>
>> 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

extending them would be wonderful.

On May 27, 2006, at 7:45 AM, Istvan Varga wrote:

> OK, no one is talking about removing the invalue opcodes or support
> for the Mac platform. As explained by Matt Ingalls, the already
> existing opcodes can be extended to support strings without the
> addition of new API functions, and that should be fine.
>
> On Saturday 27 May 2006 14:22, Dr. Richard Boulanger wrote:
>
>> invalue and outvalue are incredibly important to me and all my  
>> students.
>>
>> they are simple and clear and we have been using them for years.
>>
>> hundreds of MacCsound GUIs and csound~ max/msp patches (and I mean
>> hundreds) have been designed with them.
>>
>> because many of the developers do not use Macintosh computers, they
>> might not realize how important matt ingalls opcodes and  
>> implementation
>> have been.
>>
>> in the united states, most computer musicians use the macintosh.
>>
>> at berklee, all 5000 music majors, are required to purchase macintosh
>> computers as one of their textbooks.
>
>
> _______________________________________________
> 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