I too am bothered by Csound bloat.

I'd very much like to see a basic or core Csound that is a subset of the
larger program, and would both be more approachable for beginners as well as
less intimidating for more advanced users (like myself).

Of course, then there is the issue of exactly what gets included.

Art Hunkins

----- Original Message ----- 
From: "matt ingalls" 
To: "Developer discussions" 
Sent: Friday, May 26, 2006 6:31 PM
Subject: Re: [Cs-dev] instring/outstring


> 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

One of the reasons for the plugin mechanism was to allow the creation
of small, lean systems for maximum real-time performance.  This is
still realisable.
==John ffitch


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