Hello again,

There's been a bit of discussion regarding Csound and Python lately and its got me thinking again about building Csound from source -- which leads me to a pose a few of the nagging questions I have regarding whether I will use it in my apps or not (keep in mind that I'm very much an amateur with Csound and I'm at a critical junction as to whether I will use it)...

---

1) How difficult would it be to build Csound without Python (i.e. no Scons/Python needed from build to end-use)?

2) Can I build Csound with the standard version of mingw (not the setjmp longjmp version -- or whatever it's called).  If not, then how hard would it be to recode the "jumps" so it can be built on the normal version of mingw (I haven't delved into the code deeply but as far as I can tell the "jumps" are error and return related so it would seem that they could be removed).

3) How many "core" dependencies does Csound really have?  It seems like  most of the dependencies are gui and binding related and that the basic table, opcode, and soundfile code use a small set of libraries that are easy to build.

4) My main user-group will be on Windows and I'd like to make the use of Csound as transparent as possible but I'm concerned about Csound's installer for it.  Last I knew it was leaving users with an unresolved Python library message box issue during Csound startup.  Is this still the case?

---

I'm absolutely loving using Csound now that I've been able to sort out the api funkiness, but I've only tried building it once -- which was a nightmare... I realize a lot of free work has gone into it so please don't take offense, but it's how I see it -- the build system is unnecessarily complicated and is not something I'm willing to deal with.  I'll write my own build system for qmake before I try and get Csound built with Scons again -- which leads me to think I'm better off making an entire fork instead of trying to work with the main dev tree, especially since I code in C++ with Qt.  All I need is a Csound api that is super-lean and uses nothing but C.  To me the whole Python thing is a fly in the ointment.

---

Hopefully, I am coming to the end of the research stage for my current and future apps.  Qt is wonderful and I've committed to it.  Coin3d is workable and I've committed to it (at least until Qt does more with 3d and scene-graphs) -- which brings me to Csound... I'm very happy with it for my own use but it's not something I want to subject users and developers to when working with my apps -- and the questions above make me wonder if there isn't a better api out there for synthesis, or whether or not it would be a better use of time to start looking into other api's or build a stripped down version of Csound.  In 3 weeks my time is freeing up and I may start working on a C only Csound so I'm very interested in discussing the pros and cons of doing something like this and what some of the major issues will be if it is attempted.  I suspect it will be less difficult than it appears and with my limited knowledge of the Csound source I can see no insurmountable hurdles at the moment.  As always, though, there may be gotchas waiting for the last pieces to try and fit together so if this is a really really bad idea please let me know.

I will probably stick with Csound regardless since I've invested over a year into learning it, but I'm very concerned about question #4.  Before I will feel good about committing to using Csound in my deployed apps I need an installer that installs a functional version of Csound on Windows XP without things like error message boxes popping up every time -- because if things like this happen in my app after it's installed then I won't hear from the person trying it out -- they'll just not use it and write it off as another crappy open-source offering.  I mean, all the new and upcoming stuff in Csound is definitely cool, but with a shaky build system I'm having a hard time convincing myself that using Csound isn't going to be a huge headache for my non-technical users due to my inability to build it as-is.

---

I have several apps in mind based on 3d scene graphs and audio composition/synthesis, and I suspect the "branding" of open-source may bring a lot of exposure to the good apps out there, but there are also a lot of bad open-source apps out there that are going to make the typical Windows user run for cover when they encounter them.  I do NOT want my apps associated with those bad apps, but I suspect using Csound will do exactly that if I don't build it myself.  Maybe I'm wrong...

Regards,
-andy.f

might be worth 1) joining the csound developer team 2) adding your

build scripts to csound cvs sources.

----- Original Message -----
From: Andy Fillebrown <andy@audiosculptures.com>
Date: Monday, June 29, 2009 12:51 pm
Subject: [Csnd] Re: Re: Csound's viability on Windows for non-technical users...
To: csound@lists.bath.ac.uk

>
> Thanks again Victor!
>
> > >
> > > 1) How difficult would it be to build Csound without Python
> (i.e. no
> > > Scons/Python needed from build to end-use)?
> >
> >
> > You will need to write a new Makefile for each platform. Or, worse,
> > write an autoconf script etc.
> >
>
> If I do this then I'll be using QMake or CMake since they're the
> only cross
> platform build systems I'm familiar with.  I haven't used
> CMake in a while but
> from what I hear CMake is getting very good and it's supported
> in QtCreator
> along side QMake, which leads me to believe Qt may be planning
> to abandon QMake
> and move everything to CMake, too.
>
>
> > >
> > > 2) Can I build Csound with the standard version of mingw
> (not the
> > > setjmp longjmp version -- or whatever it's called).  If
> not, then how
> > > hard would it be to recode the "jumps" so it can be built on the
> > > normal version of mingw (I haven't delved into the code
> deeply but as
> > > far as I can tell the "jumps" are error and return related
> so it would
> > > seem that they could be removed).
> >
> > I'm not sure about this. I have installed the standard version of
> > MinGW (as far as I can remember) a
> > couple of months ago in this vista computer I have at home and it
> > builds Csound for me alright.
> > Not sure about this requirement now. Mike Gogins will tell you
> more...>
>
> Did it just build ok (do you actually use that build?)... I only
> ask because
> IIRC it would build fine then crash during run-time with few
> clues as to why.
>
>
> > >
> > > 3) How many "core" dependencies does Csound really
> have?  It seems
> > > like  most of the dependencies are gui and binding
> related and that
> > > the basic table, opcode, and soundfile code use a small set of
> > > libraries that are easy to build.
> >
> > The only core dependency is libsndfile. Everything else is optional.
> > With libsndfile only you
> > get a functional system on all platforms. However on Windows
> RT IO is
> > bad because it
> > will use the MME IO module. So in this platform I would
> recommend at
> > least adding portaudio
> > to the list for ASIO.
> >
>
> This is great news!  I like those libraries.
>
>
> > >
> > > 4) My main user-group will be on Windows and I'd like to
> make the
> > > use of Csound as transparent as possible but I'm concerned about
> > > Csound's installer for it.  Last I knew it was leaving
> users with an
> > > unresolved Python library message box issue during Csound
> startup.  Is
> > > this still the case?
> >
> > Mike Gogins is your man on this one.
> >
>
> I may be too excited to wait...  I'm tempted to try and
> slap together a quick
> QMake build today, just to see if it'll work.
>
>
> Cheers,
> -andy.f
>
>
>
> 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