I don't at all appreciate the tone in some of the posts to which I am 
responding, and I would appreciate an apology.

I do not view myself as a member of any sort of "priesthood," and views that 
I do are contradicted by the extensive efforts that I have made to enable 
other people easily to use Csound and CsoundAC. I have contributed a build 
system that actually does build Csound on all platforms, after other 
approaches failed to do so; I have written a tutorial introduction to Csound 
that several have told me is quite useful to beginners; and I have written 
two of the several guides to building Csound, including the one in the 
Csound manual, and a separate standalone guide to building on Windows.

I don't view any of the other committed Csound developers as a "priesthood" 
either. But most of us are quite busy and Csound is one part of what we do.

Now, I would like to address some substantive points.

I'm sorry, but it is indeed the use of SWIG that creates a dependency on a 
specific version of Python, that is just how SWIG works. I have looked 
through the SWIG documentation and mailing list for pointers on this issue, 
and everybody just builds version-specific wrappers. In fact, this is the 
case with most Python extension modules -- not just ones built with SWIG.

If anyone happens to know how to get SWIG to make a non-version-specific 
wrapper, I will admit that I am wrong, I would be very glad to hear about 
it, and I would definitely try to adopt it. Otherwise, please do not repeat 
factual errors.

The use of a specific version of Python does not prevent users from using 
Csound with or without Python. You can have several versions of Python 
installed on the same computer and they will happily co-exist. You can use 
one version of Python to run one Python extension module that is specific to 
that version, and you can use another version of Python to run another 
Python extension module that is specific to that version. You can do this by 
setting up different "environments" for different versions of Python. You 
can do this in a batch file that sets the appropriate PATH and other 
environment variables for running Csound with its required version of 
python, and another batch file for running other programs that need other 
versions of Python.

It also, of course, is possible to simply throw out annoying parts of 
Csound, as Art Hunkins has so clearly explained.

In the meantime, be assured that I will make every reasonable effort to make 
the installer, and Csound, easier to use. More information about specific 
problems, including OS and Csound and Python versions, and screen shots of 
error messages, would be most useful.

I am considering creating two installers, one with a "cut-down" release of 
Csound, and one with all bells and whistles including all the language APIs. 
Then the installer with Python stuff wouldn't have to try to figure out what 
is what on the installee's computer.

I also will look into changing the build system to use Python distutils to 
make the Python extension module, although I am not sure that this will 
really be an improvement.

Regards,
Mike

----- Original Message ----- 
From: "DavidW" 
To: 
Sent: Thursday, July 02, 2009 6:54 PM
Subject: [Csnd] Re: Building Python API (was Re: : Score Alignment Utility)


> It is good to here that it is not just me banging on about these  issue. 
> It is simply not true - or a solution - to assume that build  difficulties 
> mean "(dumb) newbie at work." In another current thread  (Sugar on a 
> Stick - and OLPCsound) On 03/07/2009, at 7:01 AM, Michael  Gogins wrote:
>
>> As I have mentioned several times on this list, making the Csound API
>> independent of the Python version is not practical.
>>
>> We use SWIG to generate the Python wrapper, because it saves a simply
>> enormous amount of work to do so. Using SWIG also makes it easy to
>> generate two of the other wrappers: the Lua API and the Java API (the
>> Lisp API is done with cffi, which is different).
>>
>> SWIG, however, makes the Python wrapper depend on the specific version
>> of Python.
>
>
> As I and others have mentioned several times on this list, keeping the 
> Csound API dependent on a specific version of Python is not practical 
> from a user
> (as opposed to a developer clique) perspective.
> As I have mentioned several times on this list, there is a middle way:
>
> 1) It is not using SWIG to generate the wrapper that creates the 
> dependency. It is the way it is (not) used that creates the  dependency. 
> The build process needs to be made easy enough that the  user can download 
> the sources and use easy-install. Lots of complex  packages out there do 
> this. However it requires a
>
> 2) Change in the oligarchical 'priesthood' approach to developer  status. 
> (Notice how warmly Brian's recent offer to become involved in 
> OSX-oriented development was met? NOT!  I hope he's not holding his 
> breath!) This would mean that the whole idea of there not being a  version 
> build available would more likely to disappear. jp's recent  Adminstrivia 
> Message said:
>>  Newbies are
>> sometimes afraid to post because they read discussions about the
>> incomprehensible deep inner workings, and all they want to know is how
>> to get a sound to come out of their iBook.  Rest assured that your
>> question will be answered quickly, and (usually) in a helpful and
>> courteous manner.  We've all been there.  Please post.
>
>
> This could have come straight out of Hesse's The Glass Bead Game! Your 
> questions may be answered but your suggestions frequently ignored. 
> Afterall, the priests far to busy doing important things like  producing 
> the next version release, to fix "newbie problems. Get back  in your box 
> and genuflect,  genuflect,  genuflect!
>
> Michael recently said
>> I really don't understand the difficulty with the Windows installers.
>> I routinely test it at home and at work; and at work, i uninstall
>> Csound before installing it again. It always just runs out of the box.
>
> The difficulty is not a failure of the people trying to do the  install, 
> it a development process failure. We all know how hard it is  to do the 
> n'th correction of a text we've written, whereas fresh eyes  see the flaws 
> easily. Ditto SW development.
>
> On 03/07/2009, at 4:26 AM, Dr. Richard Boulanger wrote:
>
>> I can't agree more.
>>
>> We desperately need a simple *installable* Windows version of  Csound5 
>> with the QuteCsound front-end - as part of the package.
>>
>> I can't tell you how many Electronic Musicians, Synth Majors, Synth 
>> professor, and very skilled and
>> Experienced Computer Music/Electronic Music colleagues - just give  UP! 
>> When common sense fails,
>> when logic fails, when professional standards are not met... they  move 
>> on - to the TONS of other
>> great and powerful tools at their disposal.
>>
>> At least there is NOW a Macintosh version that simple installs in a 
>> clean and professional way, although
>> one has to find and know to install QuteCsound too... and even then, 
>> there is confusion about which version
>> will work with which version and platform.
>
> It is somewhat consoling to here your  build difficulty anecdotes. 
> Unfortunately the Mac version is not as up to the standard you think.
> As Victor said earlier in this thread
>> The Intel binaries I build are linked against MacPython 2.5. But it's
>> done in 10.4 (at the moment), so no guarantees for OSX 10.5.
>
> So around we go again. Problems mentioned, excuses (complexity, blah, 
> blah) offered. Solution: People disappear (back) to a more user- oriented 
> environment.
>
> And for the record... Csound may be fantastic, but it really is no  more 
> complex that Supercollider. Bigger, yes, more weighed down by its  own 
> history and self importance, yes, but not more complex.
>
> None of my posts on this are meant personally. I have considerable  regard 
> for the work of many on this list. But the elephant (and rhino)  in the 
> room need to be identified for what they are.
> In the meantime, when people as whether they should learn csound, I 
> continue to say "not yet, not yet".
>
> D.
> ...
>> -dB
>>
>>
>> On Jul 2, 2009, at 1:37 PM, Jacob Joaquin wrote:
>>
>>>
>>>
>>> Felipe Sateler wrote:
>>>>
>>>> I still wonder why regular users need to bother with building  csound.
>>>> There is *no* need for that.
>>>> Just to make it clear: you do *not* need to build csound to use the
>>>> API. Unless the binary packages for OSX and Windows don't install  the
>>>> headers (which I'd be surprised to learn they don't).
>>>>
>>>
>>> Python does not work with the Csound API on my system. So I have to 
>>> build it
>>> to use it.
>>>
>>>
>>> Felipe Sateler wrote:
>>>>
>>>> BTW, I do agree the csound build system is less than optimal, but it
>>>> is not easy to cater for all use cases. Anyways, it is not that hard
>>>> either: setup the appropriate environment (ie, install all needed
>>>> dependencies), setup your path and specific flags in custom.py and  run
>>>> scons with the wanted flags. If you have build errors, report them  so
>>>> that the minimum versions of dependencies are adjusted or the  problem
>>>> is fixed within csound.
>>>>
>>>
>>> Hard is a relative term.  Setting up the appropriate environment,
>>> dependencies, paths, flags, etc...  There  are lots of people who  have 
>>> no
>>> clue how to interact with these technical hurdles, who are still very
>>> capable of writing Csound and python code.  Generally speaking, for 
>>> every
>>> obstacle there is to get Csound up and running, we lose potential 
>>> Csounders.
>>> Unfortunately, Csound has more obstacles than just about anything  else 
>>> out
>>> in the wild.
>>>
>>> For all the time and hard work the developers and other put into  Csound
>>> (which I truly appreciate), much of it is wasted because of often
>>> unnecessary technical hurdles for newbies.  There are some  technical 
>>> issues
>>> that may never be eliminated, I understand this, but there is  certainly 
>>> much
>>> streamlining that can be done.  I'm willing to do my part.
>>>
>>> Plus, Csound isn't the only game in town, anymore;  It's hard  enough to 
>>> get
>>> people to give Csound a try with other great music tools such as 
>>> MaxMSP,
>>> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to  grow 
>>> the
>>> Csound community, we have knock off this technical elite attitude,  and 
>>> start
>>> looking at Csound through the eyes of newbies.
>>>
>>> My two cents.
>>> Jake
>>>
>> ...
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  "unsubscribe 
>> csound"
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia:   worrall.avatar.com.au
> - Sonification: www.sonifiction.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
>
>
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"
> 

On 03/07/2009, at 10:16 AM, michael.gogins@gmail.com wrote:

> I don't at all appreciate the tone in some of the posts to which I  
> am responding, and I would appreciate an apology.
>
If the cap fits, wear it. If not, it wasn't meant for you. No apology  
necessary. As I said, it isn't personal, so be careful imputing tone,  
especially in this forum format. Csound has this reputation, and  
denying it (especially from within the "inner circle") is not a valid  
reply to just criticism. I am not intentionally being uncivil, just  
direct. No need to take personal offence when none is implied.

> I do not view myself as a member of any sort of "priesthood," and  
> views that I do are contradicted by the extensive efforts that I  
> have made to enable other people easily to use Csound and CsoundAC.  
> I have contributed a build system that actually does build Csound on  
> all platforms, after other approaches failed to do so; I have  
> written a tutorial introduction to Csound that several have told me  
> is quite useful to beginners; and I have written two of the several  
> guides to building Csound, including the one in the Csound manual,  
> and a separate standalone guide to building on Windows.
>
If the mitre fits, wear it. If not, ignore it. I've always read and  
appreciated your contributions.
> I don't view any of the other committed Csound developers as a  
> "priesthood" either. But most of us are quite busy and Csound is one  
> part of what we do.
>
We differ wrt that, and we both speak from experience. Almost everyone  
is busy; that doesn't make the problem(s) disappear. If the "inner  
circle" is too busy, then expanding the "inner circle" is a more  
intelligent approach than appealing to their being overworked. What  
I'm saying is that csound dev. needs to sharpen its axes, not ignore  
the people who register that the trees are cut too roughly.

> Now, I would like to address some substantive points.
>
> I'm sorry, but it is indeed the use of SWIG that creates a  
> dependency on a specific version of Python, that is just how SWIG  
> works. I have looked through the SWIG documentation and mailing list  
> for pointers on this issue, and everybody just builds version- 
> specific wrappers. In fact, this is the case with most Python  
> extension modules -- not just ones built with SWIG.
>
> If anyone happens to know how to get SWIG to make a non-version- 
> specific wrapper, I will admit that I am wrong, I would be very glad  
> to hear about it, and I would definitely try to adopt it. Otherwise,  
> please do not repeat factual errors.
>
Let me assume you're not purposely misrepresenting my point....  I am  
not arguing for some unspecified version of "SWIG to make a non- 
version-specific wrapper":
- A User with machine X with OS version Y and Python version Z and  
wants to build csound for it.
- The User installs the version of SWIG etc appropriate for their X, Y  
and Z.
- The User downloads the csound sources and runs the SConstruct.
- If it doesn't build/install etc appropriate to The User's machine,  
then it is a csound problem, unless it originates as a "specific  
version of SWIG problem." Even then, it is a csound problem because,  
given people-power, communication with SWIG dev. team etc, it it  
likely to be solvable.

Of course, if one User is trying to use one version of SWIG/python and  
one particular (set of) X, Y, and Z ,to generate generic wrappers for  
all X, Y and Z,  then there's likely to be a problem. But as I said,  
this is not what I'm suggesting, so I am not repeating factual errors.
Or perhaps I'm misunderstanding what you're saying. Are you saying  
that is is not possible to write a SConstruct file that can be made  
appropriately sensitive to the version of SWIG/python that is running  
it? If so, then long live MAKE. However, my experience with csound's  
SConstruct file is that problems were caused by it having certain  
things (such as the location of the python framework) "hard-wired".

> The use of a specific version of Python does not prevent users from  
> using Csound with or without Python. You can have several versions  
> of Python installed on the same computer and they will happily co- 
> exist. You can use one version of Python to run one Python extension  
> module that is specific to that version, and you can use another  
> version of Python to run another Python extension module that is  
> specific to that version. You can do this by setting up different  
> "environments" for different versions of Python. You can do this in  
> a batch file that sets the appropriate PATH and other environment  
> variables for running Csound with its required version of python,  
> and another batch file for running other programs that need other  
> versions of Python.

I know about frameworks and different versions of python, as I've said  
before. And I've probably been using PATH variables longer than many  
on this list have been alive. But this doesn't solve the problem, as  
I've said before. If  A, B, C etc need to be done as part of a  
composition process and all the tools to do that except csound build  
to install for (one reasonable/the latest version of) python, how does  
having different versions available solve the problem? I do not accept  
the argument that it is good practice for the whole world to revolve  
around a particular version of python just because of csound. If the  
world marches to a particular step and csound is not instep, then it  
is csound, not the world. that is out-of-step.

> It also, of course, is possible to simply throw out annoying parts  
> of Csound, as Art Hunkins has so clearly explained.
>
As a user? Or are you suggesting the starting up a new project as a  
way of solving the current problem?
> In the meantime, be assured that I will make every reasonable effort  
> to make the installer, and Csound, easier to use. More information  
> about specific problems, including OS and Csound and Python  
> versions, and screen shots of error messages, would be most useful.
>
Thanks.
> I am considering creating two installers, one with a "cut-down"  
> release of Csound, and one with all bells and whistles including all  
> the language APIs. Then the installer with Python stuff wouldn't  
> have to try to figure out what is what on the installee's computer.
>
> I also will look into changing the build system to use Python  
> distutils to make the Python extension module, although I am not  
> sure that this will really be an improvement.
>
Lets discuss the options.
> Regards,
> Mike
in appreciation,

David
> ----- Original Message ----- From: "DavidW" 
> To: 
> Sent: Thursday, July 02, 2009 6:54 PM
> Subject: [Csnd] Re: Building Python API (was Re: : Score Alignment  
> Utility)
>
>
>> It is good to here that it is not just me banging on about these   
>> issue. It is simply not true - or a solution - to assume that  
>> build  difficulties mean "(dumb) newbie at work." In another  
>> current thread  (Sugar on a Stick - and OLPCsound) On 03/07/2009,  
>> at 7:01 AM, Michael  Gogins wrote:
>>
>>> As I have mentioned several times on this list, making the Csound  
>>> API
>>> independent of the Python version is not practical.
>>>
>>> We use SWIG to generate the Python wrapper, because it saves a  
>>> simply
>>> enormous amount of work to do so. Using SWIG also makes it easy to
>>> generate two of the other wrappers: the Lua API and the Java API  
>>> (the
>>> Lisp API is done with cffi, which is different).
>>>
>>> SWIG, however, makes the Python wrapper depend on the specific  
>>> version
>>> of Python.
>>
>>
>> As I and others have mentioned several times on this list, keeping  
>> the Csound API dependent on a specific version of Python is not  
>> practical from a user
>> (as opposed to a developer clique) perspective.
>> As I have mentioned several times on this list, there is a middle  
>> way:
>>
>> 1) It is not using SWIG to generate the wrapper that creates the  
>> dependency. It is the way it is (not) used that creates the   
>> dependency. The build process needs to be made easy enough that  
>> the  user can download the sources and use easy-install. Lots of  
>> complex  packages out there do this. However it requires a
>>
>> 2) Change in the oligarchical 'priesthood' approach to developer   
>> status. (Notice how warmly Brian's recent offer to become involved  
>> in OSX-oriented development was met? NOT!  I hope he's not holding  
>> his breath!) This would mean that the whole idea of there not being  
>> a  version build available would more likely to disappear. jp's  
>> recent  Adminstrivia Message said:
>>> Newbies are
>>> sometimes afraid to post because they read discussions about the
>>> incomprehensible deep inner workings, and all they want to know is  
>>> how
>>> to get a sound to come out of their iBook.  Rest assured that your
>>> question will be answered quickly, and (usually) in a helpful and
>>> courteous manner.  We've all been there.  Please post.
>>
>>
>> This could have come straight out of Hesse's The Glass Bead Game!  
>> Your questions may be answered but your suggestions frequently  
>> ignored. Afterall, the priests far to busy doing important things  
>> like  producing the next version release, to fix "newbie problems.  
>> Get back  in your box and genuflect,  genuflect,  genuflect!
>>
>> Michael recently said
>>> I really don't understand the difficulty with the Windows  
>>> installers.
>>> I routinely test it at home and at work; and at work, i uninstall
>>> Csound before installing it again. It always just runs out of the  
>>> box.
>>
>> The difficulty is not a failure of the people trying to do the   
>> install, it a development process failure. We all know how hard it  
>> is  to do the n'th correction of a text we've written, whereas  
>> fresh eyes  see the flaws easily. Ditto SW development.
>>
>> On 03/07/2009, at 4:26 AM, Dr. Richard Boulanger wrote:
>>
>>> I can't agree more.
>>>
>>> We desperately need a simple *installable* Windows version of   
>>> Csound5 with the QuteCsound front-end - as part of the package.
>>>
>>> I can't tell you how many Electronic Musicians, Synth Majors,  
>>> Synth professor, and very skilled and
>>> Experienced Computer Music/Electronic Music colleagues - just  
>>> give  UP! When common sense fails,
>>> when logic fails, when professional standards are not met... they   
>>> move on - to the TONS of other
>>> great and powerful tools at their disposal.
>>>
>>> At least there is NOW a Macintosh version that simple installs in  
>>> a clean and professional way, although
>>> one has to find and know to install QuteCsound too... and even  
>>> then, there is confusion about which version
>>> will work with which version and platform.
>>
>> It is somewhat consoling to here your  build difficulty anecdotes.  
>> Unfortunately the Mac version is not as up to the standard you think.
>> As Victor said earlier in this thread
>>> The Intel binaries I build are linked against MacPython 2.5. But  
>>> it's
>>> done in 10.4 (at the moment), so no guarantees for OSX 10.5.
>>
>> So around we go again. Problems mentioned, excuses (complexity,  
>> blah, blah) offered. Solution: People disappear (back) to a more  
>> user- oriented environment.
>>
>> And for the record... Csound may be fantastic, but it really is no   
>> more complex that Supercollider. Bigger, yes, more weighed down by  
>> its  own history and self importance, yes, but not more complex.
>>
>> None of my posts on this are meant personally. I have considerable   
>> regard for the work of many on this list. But the elephant (and  
>> rhino)  in the room need to be identified for what they are.
>> In the meantime, when people as whether they should learn csound, I  
>> continue to say "not yet, not yet".
>>
>> D.
>> ...
>>> -dB
>>>
>>>
>>> On Jul 2, 2009, at 1:37 PM, Jacob Joaquin wrote:
>>>
>>>>
>>>>
>>>> Felipe Sateler wrote:
>>>>>
>>>>> I still wonder why regular users need to bother with building   
>>>>> csound.
>>>>> There is *no* need for that.
>>>>> Just to make it clear: you do *not* need to build csound to use  
>>>>> the
>>>>> API. Unless the binary packages for OSX and Windows don't  
>>>>> install  the
>>>>> headers (which I'd be surprised to learn they don't).
>>>>>
>>>>
>>>> Python does not work with the Csound API on my system. So I have  
>>>> to build it
>>>> to use it.
>>>>
>>>>
>>>> Felipe Sateler wrote:
>>>>>
>>>>> BTW, I do agree the csound build system is less than optimal,  
>>>>> but it
>>>>> is not easy to cater for all use cases. Anyways, it is not that  
>>>>> hard
>>>>> either: setup the appropriate environment (ie, install all needed
>>>>> dependencies), setup your path and specific flags in custom.py  
>>>>> and  run
>>>>> scons with the wanted flags. If you have build errors, report  
>>>>> them  so
>>>>> that the minimum versions of dependencies are adjusted or the   
>>>>> problem
>>>>> is fixed within csound.
>>>>>
>>>>
>>>> Hard is a relative term.  Setting up the appropriate environment,
>>>> dependencies, paths, flags, etc...  There  are lots of people  
>>>> who  have no
>>>> clue how to interact with these technical hurdles, who are still  
>>>> very
>>>> capable of writing Csound and python code.  Generally speaking,  
>>>> for every
>>>> obstacle there is to get Csound up and running, we lose potential  
>>>> Csounders.
>>>> Unfortunately, Csound has more obstacles than just about  
>>>> anything  else out
>>>> in the wild.
>>>>
>>>> For all the time and hard work the developers and other put into   
>>>> Csound
>>>> (which I truly appreciate), much of it is wasted because of often
>>>> unnecessary technical hurdles for newbies.  There are some   
>>>> technical issues
>>>> that may never be eliminated, I understand this, but there is   
>>>> certainly much
>>>> streamlining that can be done.  I'm willing to do my part.
>>>>
>>>> Plus, Csound isn't the only game in town, anymore;  It's hard   
>>>> enough to get
>>>> people to give Csound a try with other great music tools such as  
>>>> MaxMSP,
>>>> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want  
>>>> to  grow the
>>>> Csound community, we have knock off this technical elite  
>>>> attitude,  and start
>>>> looking at Csound through the eyes of newbies.
>>>>
>>>> My two cents.
>>>> Jake
>>>>
>>> ...
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body   
>>> "unsubscribe csound"
>>



________________________________________________
David Worrall.
- Experimental Polymedia:	  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au