The Python API on OSX works as elsewhere, as far as I can see.
There are no specific bugs to it, AFAIK. As far as building it,
if you have SWIG (a reasonably recent version), it will build OK,
without any issues.
The major problem I see in building Csound is that there are lots
of dependencies; that's not a problem with Csound itself being
easy or not to build, but a question of having a reasonably
complete developer's system. On Linux, this is not an issue
as systems are generally complete and packages can be easily found
for everything. On OSX and Windows, you need to have a
developer's attitude to it.
Victor
----- Original Message -----
From: DavidW <vip@avatar.com.au>
Date: Sunday, June 28, 2009 5:20 pm
Subject: [Csnd] Re: Building Python API (was Re: : Score Alignment Utility)
To: csound@lists.bath.ac.uk
>
> On 29/06/2009, at 1:47 AM, Michael Gogins wrote:
> ..
> > Where Csound differs from other SWIG-based extensions,
> perhaps, is
> > that we do not currently produce multiple versions of the extension
> > modules targetted to different versions of Python. Feel free to
> > contribute this to Csound, if you think it important enough.
> >
> Its not just a matter of importance.
> I won't be contributing code to csound until the development
> process
> is made more inclusive.
>
> > The SWIG approach has worked extremely well for us to date.
>
> Maybe. Depends how you define "us". My last experience was is
> that it
> was mysteriously buggy under OSX.
> > It would
> > be possible to move to boost::python or to ctypes, but both would
> > involve considerably more work. I suspect the boost::python approach
> > also would be harder to build and maintain.
> >
> I was not recommending that. I was simply asking if anyone
> had
> developed an alternative to the problems exhibited by the
> SWIG/SCons
> process on OSX.
>
> > I have Csound working with Python 2.6 on Windows, and the next
> Windows> release will be targetted for Python 2.6.
> >
> lucky for 'doze users!
>
> D.
>
> > Regards,
> > Mike
> >
> > On 6/28/09, DavidW <vip@avatar.com.au> wrote:
> >> On 28/06/2009, at 9:23 AM, victor wrote:
> >>
> >>> What do you mean? Should we move to Python 2.6?
> >>
> >>
> >> Sorry if I wasn't clear. I'm not saying anything different to
> what I
> >> was saying on the dev-list for a couple of years. Maybe the
> issue is
> >> still discussed there; I don't know, I stopped reading it
> some time
> >> ago.
> >>
> >> Python APIs are useful for different reasons, including
> >> compositional/
> >> sonification/exhibtion etc etc (*), and in such application,
> csound
> >> is
> >> just another API whose explicit purpose is the
> synthesis/processing
> >> of
> >> sound. Other extensions include interfaces to 3 or 4 different
> >> database types, fast multidimensional array processing, graphical
> >> output, GUI, network applications, etc etc for all of
> which
> >> developers
> >> maintain versions that use eggs or at least easy_install
> that
> >> compile/
> >> install dependent on the _users_ version of python (within some
> >> backwards-compatibility window).
> >>
> >> Csound python API is a library _extension_ of python so in
> the
> >> general-
> >> to-specific usage model outlined above, it makes sense to
> ensure it
> >> independent of (or as easily compilable for) any particular
> version
> >> of
> >> python. At the moment the interaction between csound
> and SCons seems
> >> to require some 'hand nursing' to produce an API for particular
> >> version of python and so if you want to integrate csound into your
> >> work you're restricted to the use of versions of python for
> which
> >> that
> >> nursing has been effected. Or if you're using an older
> version of
> >> python, you don't have access to the latest csound additions.
> >>
> >> IMO, that limitation is a debilitating one and limits the potential
> >> user base of csound; most (serious) python users (a
> considerably>> larger user base than that of csound) simply will
> not entertain using
> >> csound while that limitation applied. Thankfully there are other
> >> alternatives, which, while they may not be as comprehensive
> as
> >> csound,
> >> are not dependent in the manner described.
> >>
> >> So, in short my answer to
> >>
> >>> Should we move to Python 2.6?
> >>
> >>
> >> is that it doesn't matter. Most python users who maintain a
> body of
> >> code are probably already testing against v3.
> >> The solution must lie in the domain of generalising the
> build
> >> process.
> >>
> >> D.
> >>
> >> (*) Limiting music with computers to _sound_, will ensure
> it
> >> continues
> >> to suffer from the same problems that all Cartesian models do.
> >>
> >>
> >> ________________________________________________
> >> 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"
> >>
> >
> >
> > --
> > Michael Gogins
> > Irreducible Productions
> > http://www.michael-gogins.com
> > Michael dot Gogins at gmail dot com
> >
> >
> > Send bugs reports to this list.
> > To unsubscribe, send email sympa@lists.bath.ac.uk with
> body
> > "unsubscribe csound"
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia: www.avatar.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
> Australian research affiliations:
> - Capital Markets Cooperative Research Centre: www.cmcrc.com
> - Sonic Communications Research Group: creative.canberra.edu.au/scrg
> - MARCS Auditory Laboratories: marcs.uws.edu.au
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body
> "unsubscribe csound"
Dr Victor Lazzarini, Senior Lecturer, Dept. of Music,
National University of Ireland, Maynooth