What you want is good, but it conflicts with the power of a high-level 
programming language, which is what Csound, for all its warts, is.

The only real solution to this sort of thing is an agreement by a community 
of users to use standard ways of doing things. It doesn't, and can't, depend 
on changes to the Csound language itself.

So far, this hasn't happened in Csound, but it's a good idea.

Regards,
Mike

----- Original Message ----- 
From: "Graham Breed" 
To: "Developer discussions" 
Sent: Wednesday, July 12, 2006 5:01 AM
Subject: Re: [Cs-dev] Future of Csound


> Erik de Castro Lopo wrote:
>
>> Secondly, I'm not real keen on the way the default method for
>> instrument output is to the final output buss. I'd much prefer
>> it if each instruments wrote to its own output buss which was then
>> mixed to generate the final output. I know this is basically possible
>> by defining a mix instrument, but that seems so clunky, especially
>> if the mix control for each instrument comes from an external source.
>
> I want more modularity generally, and I don't know what the consensus is
> on this.  The way I've written my orchestra, there are standard UDOs to
> implement timbres and envelopes, then macros to define instruments built
> from these UDOs, outputting to standard zak channels, and applying my
> own tunings.  And it works, but the macros are a hack, so all I really
> need is for UDOs to accept other UDOs as parameters.
>
> The real problem is that I'm doing this in a different way to everybody
> else.  I can't expect to download somebody else's envelope generator and
> plug it in to my instruments.  Why should anybody code their own
> envelope generators, after all?  There should be a way of defining a UDO
> so that a GUI application knows that it's supposed to be an envelope and
> can be plugged into an instrument that requires an envelope.  And if I
> want to play with a new synthesis method I only need to edit the
> orchestra for the timbre and then plug it in to the standard instruments
> and effects.
>
> I don't know what the state of the art is on this.  But it's really a
> matter of conventions rather than features.  And if there are
> conventions I should be following you can tell me about them now.
>
>
>                         Graham
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net