Csound Csound-dev Csound-tekno Search About

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

Date2005-02-17 15:42
From"gogins@pipeline.com"
SubjectRe: [Cs-dev] Re: ending the code freeze
Richard, nobody loves your many and long-standing contributions to the
Csound world as much as I do. However, I'm not sure that you have given
proper weight to the consequences of what you are asking.

Ensuring backward compatibility of Csound 5 opcodes with other versions is
not as simple as just moving the sources into the build system.

In the first place, the opcode signature has changed in Csound 5, so
backward compatibility now means maintaining at least 2 and possibly more
versions of opcode sources.

This, in turn, means that porting opcodes demands not only compiling them,
but also testing them.

Five times over? With platform differrences on top of that?

I certainly have better uses for my time, and I wouldn't be surprised if a
lot of other Csound developers feel the same way.

Regards,
Mike


Original Message:
-----------------
From: Richard Boulanger rboulanger@berklee.edu
Date: Thu, 17 Feb 2005 08:18:36 -0500
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Re: ending the code freeze


Thanks Anthony for making the time to articulate some of these points.

I do think that it is time to make sure that as many of the unique opcodes
and features that have been added to CsoundWin, CsoundAV, SuperMills,
CsoundVST, MacCsound, VargaLinux - that *would* work in the other versions,
should be ported and supported in all versions (and the new manual) at this
time - plugin opcode support might even make this an easier job.  And of
course, these *new* opcodes and features should all be migrated and tested
in Csound5 as well.

I hope that the maintainers of these versions will find the most efficient
way to make this happen.

I think that it is important to make sure that the versions of Csound in use
today are as standardized as they can be.  And when we ALL move to Csound5 -
everything will be there too!

-dB

on 2/17/05 2:08 AM, Anthony Kozar at anthony.kozar@utoledo.edu wrote:

> 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

_______________________________________________________________________
 +  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
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 17:55
FromAnthony Kozar
SubjectRe: [Cs-dev] Re: ending the code freeze
Well, I thought that I had been pretty clear about what I thought would be a
reasonable course of action that might at least partially please everyone.
But clearly I was not as clear as I thought :)

I agree with so many of the arguments *against* unfreezing the code at all.
And yet I DO think that Csound 5 is a LONG ways off.  (My totally unfounded
guess for the earliest possible release date would be Dec. 2005 -- and I
think that is VERY optimistic).  So, I also understand and sympathize with
Dr. B's wish to reconcile the opcode lists in Csound 4 before Csound 5
arrives.

A few quick points:

*  I do not think that we should perform "major surgery" on Csound 4 under
any circumstances.

*  I have never suggested that we try to provide Csound 5 enhancements such
as reentrancy, multiple instances, etc. in Csound 4.

*  Adding existing opcodes from CsoundAV, Istvan's 4.24, or MacCsound, that
do not change *anything* outside their own files is trivial.  This is
primarily what Dr. B is asking for !

*  I have argued and still mostly believe that adding these opcodes as
plugins to Csound 4 would be better.  But to satisfy Dr. B's requests, this
requires that the maintainers of non-canonical versions be willing to
support opcode plugins using an identical interface if they do not already.

*  What we are currently calling "Csound 5" is somewhat misleading.  I think
that it works well because it is not that much different than Csound 4 yet.
The biggest and most radical changes have not yet been made.  (1)


My conclusion for now -- based on the current prevailing consensus -- is
that we should NOT unfreeze canonical Csound 4 at all.  Efforts to make some
of the missing opcodes available as plugins could be made.  And getting
CsoundAV and MacCsound to fully support Csound 4-style plugins NOW would not
only be the best solution, but makes sense since all other versions of
Csound 4 support them (AFAIK).

Furthermore, as soon as I finish up the current Mills update that I am
working on, I pledge to put more effort into helping with Csound 5
development.  I have been reluctant to do so previously because many of the
changes made so far have made Csound 5 incompatible with MacOS 9 without a
lot more work. (2)  But Istvan's recent addition of rtaudio plugins may make
Csound 5 reasonably possible on MacOS 9 again.  (3)

In any case, I will try to make Csound 5 more of a priority than Csound 4
for myself from now on.  And I am glad that we had this discussion so that
everyone will have a deeper understanding of the current situation.


Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/


(1)  Of course, this is just my opinion, and I admit much ignorance about
Csound 5.

(2)  The term "cross-platform" usually doesn't include MacOS 9 :)  I simply
do not have the time to port or check old ports of PortAudio, PortMidi,
Scons, fluid, FLTK, Loris, Python, etc., and maintain them or worry about
whether future changes to Csound will require updating to a new version of
one of these libraries which is now incompatible with OS 9, etc.

(3)  Or perhaps Csound 5 will will only be a second-class citizen on OS 9
without real-time support and all the extra bells and whistles.



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

Date2005-02-18 02:05
FromDave Phillips
SubjectRe: [Cs-dev] Re: ending the code freeze
Anthony Kozar wrote:

>A few quick points:
>
>*  I do not think that we should perform "major surgery" on Csound 4 under
>any circumstances.
>
Sorry for mentioning that, Anthony. I didn't mean to imply that's what 
was happening or going to happen, only that it could happen and that it 
would not be a good thing (IMO of course).

>*  I have never suggested that we try to provide Csound 5 enhancements such
>as reentrancy, multiple instances, etc. in Csound 4.
>
>*  Adding existing opcodes from CsoundAV, Istvan's 4.24, or MacCsound, that
>do not change *anything* outside their own files is trivial.  This is
>primarily what Dr. B is asking for !
>
Okay, but when people start asking for realtime performance enhancements 
and the FLTK support I think we've entered a different ballpark.

>*  I have argued and still mostly believe that adding these opcodes as
>plugins to Csound 4 would be better.  But to satisfy Dr. B's requests, this
>requires that the maintainers of non-canonical versions be willing to
>support opcode plugins using an identical interface if they do not already.
>
Yes, this seems like a good bottom line.

My concern is that a lot of work has gone into keeping Cs5 backwards 
compatible with existing orc/sco and csd files. I feel it's important 
that further development of Cs4 try to be "forwards compatible" with Cs5.

>*  What we are currently calling "Csound 5" is somewhat misleading.  I think
>that it works well because it is not that much different than Csound 4 yet.
>The biggest and most radical changes have not yet been made.  (1)
>
Umm...

>My conclusion for now -- based on the current prevailing consensus -- is
>that we should NOT unfreeze canonical Csound 4 at all.  Efforts to make some
>of the missing opcodes available as plugins could be made.  And getting
>CsoundAV and MacCsound to fully support Csound 4-style plugins NOW would not
>only be the best solution, but makes sense since all other versions of
>Csound 4 support them (AFAIK).
>
I agree.

>In any case, I will try to make Csound 5 more of a priority than Csound 4
>for myself from now on.  And I am glad that we had this discussion so that
>everyone will have a deeper understanding of the current situation.
>  
>
Thanks for starting it, Anthony, and thanks to everyone for their 
patience and interest.

>(3)  Or perhaps Csound 5 will will only be a second-class citizen on OS 9
>without real-time support and all the extra bells and whistles.
>  
>
Someone just has to step up and take the initiative.

Best,

dp




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

Date2005-02-18 17:19
From"Richard Boulanger"
SubjectRe: [Cs-dev] Re: ending the code freeze
Mike and other Csound5 Developers,

To end this discussion for now - and make a couple of things clear that
might have been confused by my suggestions/request....

I have never suggested that we make sure all the new Csound5 features find
their way back in to Csound4.

Rather, I am saying that all the features in the various current Csound4
versions (including your CsoundVST) make it into Csound5 and that those that
are easy to add but currently missing from the various Csound4 versions
should be added to Csound4 to make these versions more compatible.

And, in order to save time and energy for all developers, and keep the focus
on Csound5... I was simply thinking that the place to look for these (once
submitted and tested in Csound5) would be in the Csound5 sources.  But
actually, what I was hoping was that:

You, Istvan, Gabriel, Matt, Anthony, Victor, John, John, Andres, and other
developers - might pull out the code for those opcodes that you determined
were exclusive to one or another version of the Csound4 and share these
*specific* sources with each other so that they might be more efficiently
added to the versions currently in use.

========================

NOW... Regarding the questions on when Csound5 will be done, and whether
Csound5 is still alpha or beta?  I find these discussions very
*interesting.*

Please forgive me for over-exaggerating here but.. ...if you don't need
efficient real-time, if you don't need great MIDI, if you don't need the
program to integrate with commercial production tools, if you don't really
need a GUI, if you don't need re-entrancy, if you don't need John ffitch's
parser (which was the main reason he asked for the *code-freeze* in the
first place), and if you don't need XYZ that you have been using for the
past 10 years in your Csound teaching, performing, composing, etc... Then...
Csound5 is almost done (2 months away).

Why would most Mac/Windows (and they are in the majority I think) user,
teacher, composer, performer not simply continue using CsoundAV or MacCsound
- maybe with Cecilia or Blue in the front and Ngen or Cmask to fuel them now
and then?  

(And Michael, if it only worked with *all* commercial VST-based sequencers
and apps *on all platforms,* I think that they would *all* be using
CsoundVST in those production environments too?, but... Under windows, why
not use CsoundAV with all of its extras and great MIDI?)

==================

Just a reminder then - from a teacher, user, friend...

1. efficient and optimal real-time performance and great full-featured MIDI
support are essential for Csound.

Both are superb in CsoundAV and in in MacCsound (especially it Max/MSP
version - csound~ because of the ASIO support there) I know that they are a
top priority for the Csound5 developers, but I would not consider Csound5
done until these were both *done* and *done well.*

2. UDO and plugin support is very important.

I think you have this happening already and this is great.  As it is in
MacCsound and SuperMills on the Mac, UDOs are helping beginners and
intermediate users to expand the language without having to re-compile or
learn to program in anything but Csound.  Plugins will mean that it will be
easier to share opcodes and grow the language in unique ways without having
to re-compile or later the wonderfully stable new cross-platform core that
you are all working on.

3. An intuitive, clean, efficient, cross platform Graphical User Interface
(maybe this also comes with FLTK opcode support?) is also quite important.

I don't think that this is a high priority at all with developers.  But I do
think that it needs to be (when you get close to the end) because the
front-end for MacCsound is quite great and very intuitive.  (Designing
Graphical interfaces for Csound instruments is a piece of cake for beginners
in this environment as well.)  CsoundAV is a decent front-end too and ALL
the FLTK examples are an inspiration for beginners as well.

====================

If my ignorance regarding the current state of Csound5 is completely
misunderstood and misrepresented in my comments and suggestions above and
over these past few weeks, I do beg your forgiveness and understanding.

I will spend a good chunk of time (days/nights) this weekend trying to catch
up  - on my PC Laptop running CsoundVST5 under XP, and the Command-Line
versions running Linux (installed by Steven Yi I might add!), and on my Mac
I will try using Csound5 with BLUE and from the terminal.

My hope is to better enlighten myself regarding the current state of
development.  To that end... I may need some of your advice as I try to make
all this happen and I sincerely hope that my comments have not alienated too
many of you.

Have a great and productive weekend.

Rick (aka Dr. B.)


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

> Richard, nobody loves your many and long-standing contributions to the
> Csound world as much as I do. However, I'm not sure that you have given
> proper weight to the consequences of what you are asking.
> 
> Ensuring backward compatibility of Csound 5 opcodes with other versions is
> not as simple as just moving the sources into the build system.
> 
> In the first place, the opcode signature has changed in Csound 5, so
> backward compatibility now means maintaining at least 2 and possibly more
> versions of opcode sources.
> 
> This, in turn, means that porting opcodes demands not only compiling them,
> but also testing them.
> 
> Five times over? With platform differrences on top of that?
> 
> I certainly have better uses for my time, and I wouldn't be surprised if a
> lot of other Csound developers feel the same way.
> 
> Regards,
> Mike
> 
> 
> Original Message:
> -----------------
> From: Richard Boulanger rboulanger@berklee.edu
> Date: Thu, 17 Feb 2005 08:18:36 -0500
> To: csound-devel@lists.sourceforge.net
> Subject: Re: [Cs-dev] Re: ending the code freeze
> 
> 
> Thanks Anthony for making the time to articulate some of these points.
> 
> I do think that it is time to make sure that as many of the unique opcodes
> and features that have been added to CsoundWin, CsoundAV, SuperMills,
> CsoundVST, MacCsound, VargaLinux - that *would* work in the other versions,
> should be ported and supported in all versions (and the new manual) at this
> time - plugin opcode support might even make this an easier job.  And of
> course, these *new* opcodes and features should all be migrated and tested
> in Csound5 as well.
> 
> I hope that the maintainers of these versions will find the most efficient
> way to make this happen.
> 
> I think that it is important to make sure that the versions of Csound in use
> today are as standardized as they can be.  And when we ALL move to Csound5 -
> everything will be there too!
> 
> -dB
> 
> on 2/17/05 2:08 AM, Anthony Kozar at anthony.kozar@utoledo.edu wrote:
> 
>> 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
> 
> _______________________________________________________________________
> +  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
> 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