Backward compatibility applies mainly to orchestras and scores, since the API has not been, and perhaps still is not, in a finished state. Once the API is really stable we can tag a set of it as stable.

Just how do you like to work, anyway? Perhaps we could come up with some suggestions to support it.

Regards,
Mike

-----Original Message-----
>From: Erik de Castro Lopo 
>Sent: Jul 11, 2006 5:00 AM
>To: csound-devel@lists.sourceforge.net
>Subject: Re: [Cs-dev] Future of Csound
>
>Michael Gogins wrote:
>
>> A while ago I said I would post my suggestions for the future of Csound, and 
>> for managing Csound development. Here they are.
>
>Hi Mike,
>
>Thanks for posting this. Its interesting to see discussion like this
>out in the open.
>
>I must admit that my interest in Csound is more as a user than as a
>developer. As a user I found have found it rather difficult to move
>from the ORC/SCO input to a input that maps better to how I would
>like to work. These difficulties caused me too look elsewhere, 
>specifically to SuperCollider. Unfortunately I can not even get a
>sound out of SC so I'm back here with Csound :-).
>
>Some of the stuff that really piqued my interest was this:
>
>    "Developers of music software who can use Csound and the Csound
>    API as a synthesis engine in their applications."
>
>This might be the easiest way for me to get to where I want to go.
>Is this API documented? Is there any example code? Is the API stable?
>
>If there is such an API, I would be tempted to try and access it via
>my favourite high level language, Ocaml :-).
>
>Finally, you write "Csound must maintain complete backward
>compatibility". Is this backward compatibility desired for ORC/SCOs 
>or does it relate to the API as well?
>
>Erik
>-- 
>+-----------------------------------------------------------+
>  Erik de Castro Lopo
>+-----------------------------------------------------------+
>"We can build a better product than Linux" -- Microsoft
>Corp.'s Windows operating-system chief, Jim Allchin.
>One has to wonder why, with their huge resources, they haven't.
>
>
>-------------------------------------------------------------------------
>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

Michael Gogins wrote:

> Backward compatibility applies mainly to orchestras and scores,
> since the API has not been, and perhaps still is not, in a
> finished state. Once the API is really stable we can tag a set
> of it as stable.

Ok, that makes sense.
 
> Just how do you like to work, anyway? Perhaps we could come up
> with some suggestions to support it.

Well first off, I don't like the score files very much. I would
prefer to work with external software and hardware event generators
and controllers. I probably haven't dug deep enough into the 
possibilities here.

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 don't mind defining instruments in a text file. I do mind the
current orchestra definition language :-). Its nasty and really 
showing its age. A language something like what sfront uses would 
seem more appropriate.

Thats off the top of my head. Maybe more later.

Cheers,
Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"I ran it on my DeathStation 9000 and demons flew out of my nose." --Kaz


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

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

> Well first off, I don't like the score files very much. I would
> prefer to work with external software and hardware event generators
> and controllers. I probably haven't dug deep enough into the 
> possibilities here.

Eric, the score files are kinda gross if you work on them directly, but
on the otherhand, they are absolutely beautiful for rendering from other
apps, in either deferred or real time, because the syntax is both so
clean and flexible. For an example of what I mean, you can check out the
renderer I made at my site: www.xornot.com ( renderer is makescore ).

When I started using csound I was all over midi control, but now find
that the cleanest way to integrate various forms of control is to have
everything get parsed down to score files/lines and send those to the
instruments. The score syntax is a great intermediate layer that way.

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

Zak channels work well for that. But they could be improved.

Iain

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net