What you is technically feasible and even common, but it is not ideal. It complicates the installation process and creates confusion among musicians. If there is no technical reason not to build the wrappers into the core library, why not do it? That makes it even easier to build on to Csound.

I've yet to hear a compelling technical reason not to build the wrappers in. There are no technical obstacles, no run time or install time dependencies. They will build and work on all the platforms Csound currently supports -- no question. So, what's the big deal? Sounds like a question of personal taste, which should not decide such an issue.

In the history of computing, systems that offer too many choices have suffered grievously. LISP is an excellent example. It lost out to Java and C++ despite being a superior language conceptually, because Java (right away) and C++ (eventually) created standards to offer the same stuff in all environments and on all platforms. LISP is a language of great power spoken in a mulitude of contending dialects, which effectively cancel each other out. 

I don't want this kind of situation to happen in computer music, where it already happens too much.

Suppose the Python interface to Csound is not standardized. Well, I have one. Someone else might have one too. So far, so good. Then a user comes along to write a Python composing program using Csound. The Python interface is not in the standard distribution, so he picks a Python interface at random. Then another user comes along to write another Python composing program, and he picks the other Python interface. Now, the two composing programs can't talk to each other, which is sad because they might have worked great with each other, and when the composers talk to each other about using Csound, they find it harder to understand each other than they would have if the interface was in the core and it was an automatic decision to just use it.

Regards,
Mike

-----Original Message-----
From: Jean Piche 
Sent: Oct 21, 2005 11:57 AM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Re: More unasked for changes


This is the opinion of a high-end user/frontend developper who can roll 
his own but has developped a sane aversion to the process. The Cs5 
engine builds easily and i must congratulate everyone for that. If i 
understand the issue of frontends correctly, ideally, binaries should 
come in all sorts of mixes for all platforms and be readily available 
for download.  If i want a CsoundVST option, mixed with a tcl/tk lib, I 
should be able to get that. If I prefer a LISP interpreter on top, I 
should be able to have that too.  I know this requires work. This is a 
community project and i am certain that many people will build from 
separate libraries to include the options they want.

Why not have a barebones engine sit in the distro, along with all 
libraries necessary to build custom versions. As people build different 
flavors, have them upload their binaries in a separate branch of the 
CVS (?). That is pretty much how the old bath ftp site worked and it 
was manageable.


j

__________________________________________
http://jeanpiche.com



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I just want to make sure I understand the issue properly. Do you 
suggest that Cs5 would include only certain wrappers for certain 
languages? If there is a build-to-order branch of the CVS which 
contains all libs for all wrappers and frontends, you dont think people 
will build what they want and provide binaries for the rest of us who 
are too impatient (musicians...)? The installation process for 
musicians would be simply a matter of choosing the build that contains 
what each desires, no?

Sorry for the missleading subject line on my previous post. I also wish 
to applaud Istvan's contribution and hope he will stay.  As an old 
timer, I can tell you that this is not the first time there are 
frictions of this kind. Some will recall the initial days of Cs3 dev. 
Cs5, from what I can see, will be a defining moment in music 
technology, not just computer music. Much of this will depend how the 
distro is handled. BTW: is there a systematic beta testing run planned? 
I mean a systematic beta campaign. I still see errors in Cs5 that date 
back to Cs3.

j



__________________________________________
http://jeanpiche.com


On 05-10-21, at 12:31, Michael Gogins wrote:

> What you is technically feasible and even common, but it is not ideal. 
> It complicates the installation process and creates confusion among 
> musicians. If there is no technical reason not to build the wrappers 
> into the core library, why not do it? That makes it even easier to 
> build on to Csound.
>
> I've yet to hear a compelling technical reason not to build the 
> wrappers in. There are no technical obstacles, no run time or install 
> time dependencies. They will build and work on all the platforms 
> Csound currently supports -- no question. So, what's the big deal? 
> Sounds like a question of personal taste, which should not decide such 
> an issue.
>
> In the history of computing, systems that offer too many choices have 
> suffered grievously. LISP is an excellent example. It lost out to Java 
> and C++ despite being a superior language conceptually, because Java 
> (right away) and C++ (eventually) created standards to offer the same 
> stuff in all environments and on all platforms. LISP is a language of 
> great power spoken in a mulitude of contending dialects, which 
> effectively cancel each other out.
>
> I don't want this kind of situation to happen in computer music, where 
> it already happens too much.
>
> Suppose the Python interface to Csound is not standardized. Well, I 
> have one. Someone else might have one too. So far, so good. Then a 
> user comes along to write a Python composing program using Csound. The 
> Python interface is not in the standard distribution, so he picks a 
> Python interface at random. Then another user comes along to write 
> another Python composing program, and he picks the other Python 
> interface. Now, the two composing programs can't talk to each other, 
> which is sad because they might have worked great with each other, and 
> when the composers talk to each other about using Csound, they find it 
> harder to understand each other than they would have if the interface 
> was in the core and it was an automatic decision to just use it.
>
> Regards,
> Mike
>
> -----Original Message-----
> From: Jean Piche 
> Sent: Oct 21, 2005 11:57 AM
> To: csound-devel@lists.sourceforge.net
> Subject: Re: [Cs-dev] Re: More unasked for changes
>
>
> This is the opinion of a high-end user/frontend developper who can roll
> his own but has developped a sane aversion to the process. The Cs5
> engine builds easily and i must congratulate everyone for that. If i
> understand the issue of frontends correctly, ideally, binaries should
> come in all sorts of mixes for all platforms and be readily available
> for download.  If i want a CsoundVST option, mixed with a tcl/tk lib, I
> should be able to get that. If I prefer a LISP interpreter on top, I
> should be able to have that too.  I know this requires work. This is a
> community project and i am certain that many people will build from
> separate libraries to include the options they want.
>
> Why not have a barebones engine sit in the distro, along with all
> libraries necessary to build custom versions. As people build different
> flavors, have them upload their binaries in a separate branch of the
> CVS (?). That is pretty much how the old bath ftp site worked and it
> was manageable.
>
>
> j
>
> __________________________________________
> http://jeanpiche.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, 
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, 
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

__________________________________________
http://jeanpiche.com


On 05-10-21, at 13:16, Steven Yi wrote:

>> distro is handled. BTW: is there a systematic beta testing run 
>> planned?
>> I mean a systematic beta campaign. I still see errors in Cs5 that date
>> back to Cs3.
>
> Just a quick reply, but what errors are you discussing?


two off the top of my head (will try and document more):

randi starts generating data only after the first period of its 
frequency has elapsed, when default seeded (0.5)
pvanal's -c flag doesn't seem to work and does not accept stereo files 
as input




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Jean Piche wrote:

> two off the top of my head (will try and document more):
> 
> randi starts generating data only after the first period of its 
> frequency has elapsed, when default seeded (0.5)

I will look at that (while I am not locked out from CVS access yet).

> pvanal's -c flag doesn't seem to work and does not accept stereo files 
> as input

Does this also happen with the latest version ? Does pvsfread not
work with stereo PVOC-EX files (I know pvoc does not, but that was
always limited to mono files) ?


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Jean Piche wrote:

> randi starts generating data only after the first period of its 
> frequency has elapsed, when default seeded (0.5)

Well, this is not exactly true, it already generates data in the
first period, it only happens that with the default seed the first
two values are almost exactly the same. You can check that this
will not happen if you use a different seed value or the 31 bit
algorithm. So, there is not really a bug, and "fixing" it would
probably have the side-effect of changing the output of already
existing orchestras (I think the 16 bit generator is still the
default for the same reason).


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net