Csound Csound-dev Csound-tekno Search About

RE: [Cs-dev] Re: ending the code freeze

Date2005-02-17 15:17
From"gogins@pipeline.com"
SubjectRE: [Cs-dev] Re: ending the code freeze
With all due respect, this is a really bad idea. It would create 2 widely
used but different versions of Csound, each requiring significant
maintenance work.

Csound has suffered, I think, more than most people realize by having
several slightly but critically divergent code bases. Nobody worries about
which version of PD or SuperCollider they are running.

Speaking as a developer and a composer, I have done it both ways. I used to
maintain CsoundVST as a separate project, now I maintain it as a frontend
and extensions within the canonical version. 

Since I moved into the canonical CVS I have saved, I am sure, dozens if not
hundreds of hours a year of my PRECIOUS FREAKING TIME. 

PRECIOUS FREAKING TIME THAT I SHOULD BE SPENDING MAKING MUSIC!

MUSIC!

MUSIC!

Get it?

For those who are not composers but do work on Csound development, merely
substitute DOING NEW DEVELOPMENT for MAKING MUSIC in the above.

I imagine that other maintainers of divergent versions would experience the
same thing... if they ever merged back into the canonical tree. 

Of course, for some of them, this would require a lot of work, and I can
understand that reluctance!...

People, please, get it together and, instead of improving the old csound,
get the new one up to speed. It already has more features. For
non-real-time work, it is already significantly more musically useful than
the old version. Thanks to Istvan's work, it now even RUNS FASTER than the
old version!

All it needs is some refinement and there will be no question which is the
version to use.

Original Message:
-----------------
From: Anthony Kozar anthony.kozar@utoledo.edu
Date: Thu, 17 Feb 2005 02:08:10 -0500
To: csound-devel@lists.sourceforge.net, rboulanger@csounds.com
Subject: [Cs-dev] Re: ending the code freeze


While I have resisted the notion of ending the code freeze both publicly and
privately, I think that when the call comes from one of the veritable
leaders of our community that perhaps the dev team should give the request
some serious consideration.

Here are some of my thoughts on the idea.

Disadvantages of unfreezing:

*  It will delay Csound 5 even more both by creating more changes to "port"
   from Cs4 and by possibly diverting resources.
*  New bugs may be introduced even if we are extremely careful.
*  ???  (The first reason is huge).

Advantages:

*  Increased compatibility between the most used versions of Csound 4.
*  New toys for everyone to appease their appetites until Cs5 arrives.
*  Comparing code between divergent versions will likely help us fix more
   bugs.
*  Cs4 may be a better test bed for resolving differences than Cs5.
*  Some features already added have never worked correctly in canonical but
   they do in other versions.  We could correct this.
(6)

I think that the truth is that Csound 5 is still a LONG way off.  And we
should take the time to do it right.

We would not have to completely thaw Csound 4.  We could put limitations on
the types of changes that could be made.  (Only "stable" new opcodes or GEN
routines that do not change the engine.  Or additionally, changes that fix
features that were partially added to Cs4 (1) or minor additions (2) should
be allowed, but not major new features or functionality changes).  And we
should probably have very strict standards for testing changes so that we
don't break anything else.  (A test suite of scores and orchestras that
demonstrate not only allowed syntax but disallowed syntax would be very
helpful anyways). (3)

I also think that there are two or three developers who already spend most
of their time on Csound 4 anyways (myself included).  I would be willing to
run diffs between AV, MacCsound, and CVS myself in order to identify those
pieces of code which could be assimilated.  It would be up to the developers
of these versions to make sure that they include the CVS changes when
possible.  Those developers focused on Csound 5 the most (John, Michael,
Steven) probably would not have to worry about releasing new versions of Cs4
since this is primarily done by John R, Matt, Gab, and myself now anyways.
(4)

On the other hand, I think many of the most noticeable differences (such as
missing opcodes) can be solved already in Csound 4 by using opcode
libraries.  If Gab and Matt would make sure that the plugin mechanism works
in their versions, then we could get the opcode lists pretty close (ignoring
things like OpenGL, etc). (5) (And I am grateful to Matt for already looking
into this).  However, the macro example attached by Dr. B to this thread
would not have a prayer of working anywhere but on CsoundAV under this
scenario.

I see advantages to both paths, but I will follow the team on this.  I hope
that everyone will contribute to the discussion and I hope that we can
arrive at a consensus about how to proceed.  In the end though, I think that
we should look to John ffitch to make the final decision on this matter.

Thanks for reading my babbling ...

Anthony

(1) Like multi-line strings {{ }} and score repeats using { }.
(2) Like the R and T score operators from Gab.
(3) I have already started to make a set of scores for demonstrating both
bugs and fixed bugs.
(4) Any developers I haven't mentioned is not due to oversight as much as
that I am unclear exactly what projects they are currently working on.
(5) Opcode plugins should already work in canonical 4.23, 4.23 GBS, Mills
4.23f12, Istvan's 4.24, and CsoundVST, I think.
(6) And we could increment the version to 4.25 because I get so dizzy with
the current versioning scheme ;)  (4.23f12gbs.8, 4.24.1, etc.)


On 2/7/05 8:05 PM, Dr. Richard Boulanger  etched in
stone:

> I think that the "opcode freeze" was a great idea and that this has given
> developers a good amount of time to learn to work together and solve many
of
> the huge, fundamental, core restructuring issues of Csound - hopefully
> leading to an incredibly functional and transparent, powerful, and
adaptable
> Csound5 in the future,
> 
> but... There has still be a lot of cooking going on in a number of
wonderful
> kitchens around the world - While we wait for the Thanksgiving feast of
> Csound5, can't we share some of the breadcrumbs and leftovers from all the
> cool proprietary stuff that has been added to Csound4 with the composers,
> teachers, sound designers?  Hope that you and other developers could
> encourage this.
> 
> - Dr. B.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2005-02-17 16:16
From"Richard Boulanger"
SubjectRe: [Cs-dev] Re: ending the code freeze
Michael,

Absolutely looking forward to more new music from you.  Your stuff is
wonderful.  And more new music from John ffitch, Gabriel Maldonado, Anthony
and *all* the developers.

Since there are *2 versions* currently, I am just wanting to make sure that
as many aspects of the heavily used Csound4 stuff has as much common opcodes
as it can and that are easy to add - if they sources are shared by those who
wrote and tested them in their versions.

Rick

on 2/17/05 10:17 AM, gogins@pipeline.com at gogins@pipeline.com wrote:

> With all due respect, this is a really bad idea. It would create 2 widely
> used but different versions of Csound, each requiring significant
> maintenance work.
> 
> Csound has suffered, I think, more than most people realize by having
> several slightly but critically divergent code bases. Nobody worries about
> which version of PD or SuperCollider they are running.
> 
> Speaking as a developer and a composer, I have done it both ways. I used to
> maintain CsoundVST as a separate project, now I maintain it as a frontend
> and extensions within the canonical version.
> 
> Since I moved into the canonical CVS I have saved, I am sure, dozens if not
> hundreds of hours a year of my PRECIOUS FREAKING TIME.
> 
> PRECIOUS FREAKING TIME THAT I SHOULD BE SPENDING MAKING MUSIC!
> 
> MUSIC!
> 
> MUSIC!
> 
> Get it?
> 
> For those who are not composers but do work on Csound development, merely
> substitute DOING NEW DEVELOPMENT for MAKING MUSIC in the above.
> 
> I imagine that other maintainers of divergent versions would experience the
> same thing... if they ever merged back into the canonical tree.
> 
> Of course, for some of them, this would require a lot of work, and I can
> understand that reluctance!...
> 
> People, please, get it together and, instead of improving the old csound,
> get the new one up to speed. It already has more features. For
> non-real-time work, it is already significantly more musically useful than
> the old version. Thanks to Istvan's work, it now even RUNS FASTER than the
> old version!
> 
> All it needs is some refinement and there will be no question which is the
> version to use.
> 
> Original Message:
> -----------------
> From: Anthony Kozar anthony.kozar@utoledo.edu
> Date: Thu, 17 Feb 2005 02:08:10 -0500
> To: csound-devel@lists.sourceforge.net, rboulanger@csounds.com
> Subject: [Cs-dev] Re: ending the code freeze
> 
> 
> While I have resisted the notion of ending the code freeze both publicly and
> privately, I think that when the call comes from one of the veritable
> leaders of our community that perhaps the dev team should give the request
> some serious consideration.
> 
> Here are some of my thoughts on the idea.
> 
> Disadvantages of unfreezing:
> 
> *  It will delay Csound 5 even more both by creating more changes to "port"
>  from Cs4 and by possibly diverting resources.
> *  New bugs may be introduced even if we are extremely careful.
> *  ???  (The first reason is huge).
> 
> Advantages:
> 
> *  Increased compatibility between the most used versions of Csound 4.
> *  New toys for everyone to appease their appetites until Cs5 arrives.
> *  Comparing code between divergent versions will likely help us fix more
>  bugs.
> *  Cs4 may be a better test bed for resolving differences than Cs5.
> *  Some features already added have never worked correctly in canonical but
>  they do in other versions.  We could correct this.
> (6)
> 
> I think that the truth is that Csound 5 is still a LONG way off.  And we
> should take the time to do it right.
> 
> We would not have to completely thaw Csound 4.  We could put limitations on
> the types of changes that could be made.  (Only "stable" new opcodes or GEN
> routines that do not change the engine.  Or additionally, changes that fix
> features that were partially added to Cs4 (1) or minor additions (2) should
> be allowed, but not major new features or functionality changes).  And we
> should probably have very strict standards for testing changes so that we
> don't break anything else.  (A test suite of scores and orchestras that
> demonstrate not only allowed syntax but disallowed syntax would be very
> helpful anyways). (3)
> 
> I also think that there are two or three developers who already spend most
> of their time on Csound 4 anyways (myself included).  I would be willing to
> run diffs between AV, MacCsound, and CVS myself in order to identify those
> pieces of code which could be assimilated.  It would be up to the developers
> of these versions to make sure that they include the CVS changes when
> possible.  Those developers focused on Csound 5 the most (John, Michael,
> Steven) probably would not have to worry about releasing new versions of Cs4
> since this is primarily done by John R, Matt, Gab, and myself now anyways.
> (4)
> 
> On the other hand, I think many of the most noticeable differences (such as
> missing opcodes) can be solved already in Csound 4 by using opcode
> libraries.  If Gab and Matt would make sure that the plugin mechanism works
> in their versions, then we could get the opcode lists pretty close (ignoring
> things like OpenGL, etc). (5) (And I am grateful to Matt for already looking
> into this).  However, the macro example attached by Dr. B to this thread
> would not have a prayer of working anywhere but on CsoundAV under this
> scenario.
> 
> I see advantages to both paths, but I will follow the team on this.  I hope
> that everyone will contribute to the discussion and I hope that we can
> arrive at a consensus about how to proceed.  In the end though, I think that
> we should look to John ffitch to make the final decision on this matter.
> 
> Thanks for reading my babbling ...
> 
> Anthony
> 
> (1) Like multi-line strings {{ }} and score repeats using { }.
> (2) Like the R and T score operators from Gab.
> (3) I have already started to make a set of scores for demonstrating both
> bugs and fixed bugs.
> (4) Any developers I haven't mentioned is not due to oversight as much as
> that I am unclear exactly what projects they are currently working on.
> (5) Opcode plugins should already work in canonical 4.23, 4.23 GBS, Mills
> 4.23f12, Istvan's 4.24, and CsoundVST, I think.
> (6) And we could increment the version to 4.25 because I get so dizzy with
> the current versioning scheme ;)  (4.23f12gbs.8, 4.24.1, etc.)
> 
> 
> On 2/7/05 8:05 PM, Dr. Richard Boulanger  etched in
> stone:
> 
>> I think that the "opcode freeze" was a great idea and that this has given
>> developers a good amount of time to learn to work together and solve many
> of
>> the huge, fundamental, core restructuring issues of Csound - hopefully
>> leading to an incredibly functional and transparent, powerful, and
> adaptable
>> Csound5 in the future,
>> 
>> but... There has still be a lot of cooking going on in a number of
> wonderful
>> kitchens around the world - While we wait for the Thanksgiving feast of
>> Csound5, can't we share some of the breadcrumbs and leftovers from all the
>> cool proprietary stuff that has been added to Csound4 with the composers,
>> teachers, sound designers?  Hope that you and other developers could
>> encourage this.
>> 
>> - Dr. B.
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

_______________________________________________________________________
 +  Dr. Richard Boulanger, Professor
 +  Music Synthesis Department, Berklee College of Music
 +  1140 Boylston Street  - Boston, MA  02215-3693
 +  Office Phone: (617) 747-2485   Office Fax: (617) 747-2564
 +  eMail: rboulanger@csounds.com  or  rboulanger@berklee.edu
 +  WebPage: http://csounds.com/boulanger/
________________________________________________________________________
 +  Almost Everything Csound @ http://csounds.com/
 +  The Csound Catalog with Audio @ http://csounds.com/catalog/
 +  The Csound Book @ http://csounds.com/book/
 +  The Csound Magazine @ http://csounds.com/ezine/
 +  CsoundForums @ http://csounds.com/phpBB2/
________________________________________________________________________



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net