|
Csound's viability on Windows for non-technical users...
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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
|
|
Re: Csound's viability on Windows for non-technical users...
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I just reread my post and it sounds a bit on the critical side now -- so I want to emphasize again how awesome it is to have a highly optimized score and synth engine freely available, regardless of perceived issues. Thanks again! -andy.f ----- Original Message ----- From: "Andy Fillebrown" < andy@...> To: "Csound List" < csound@...> Sent: Sunday, June 28, 2009 8:52:31 PM (GMT-0500) America/New_York Subject: [Csnd] Csound's viability on Windows for non-technical users... 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
|
|
Re: Csound's viability on Windows for non-technical users...
>
> 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.
>
> 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...
>
> 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.
>
> 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.
Victor
Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"
|
|
Re: Csound's viability on Windows for non-technical users...
Some parts of this message have been removed.
Learn more about Nabble's security policy.
At this time the only build system for Csound that
is supported in CVS is SCons. There is a reason for this -- experience showed it
was much easier to use and maintain. If for some reason you had to use another
build system, I would recommend CodeBlocks, which is cross platform on Windows
and Linux. You would have to figure out the right options, macros, and so on
from SConstruct but, with enough patience, I am certain you could get it to
work, although I can't imagine why you would want to unless you are a
masochist.
The standard version of MinGW is and has always
been sjlj. This is simply the technical term for how GCC implements C++
exception handling. I think what you really want to know is whether you can
build with version 3.4.5 from the MinGW web site installer program, instead
of version 4 something from Twilight Dragon Media. And you should be
able to, since this is what we all used to use. Csound just won't run quite as
fast.
What is "core?" Depends on who you ask. You should
look at SConstruct and figure out what you really need to do what you want to
do. But your assumptions are correct, especially since you don't actually
need PortMidi or PortAudio (which in fact are NOT easy to build) on Windows, but
can use native Windows libraries (that is, unless you need LOW LATENCY real-time
audio, in which case you really do need to build PortAudio).
If you are going to create a standalone product
with Csound built in, then you will probably want to create your own installer.
This is not as hard as you might think, especially because you can just take the
Csound nullsoft installer script and add your own stuff to it and remove the
stuff you don't want.
Hope this helps,
Mike
----- Original Message -----
Sent: Sunday, June 28, 2009 8:52 PM
Subject: [Csnd] Csound's viability on
Windows for non-technical users...
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
|
|
Re: Re: Csound's viability on Windows for non-technical users...
I responded to most of these questions in my previous email.
About Python and the Windows Csound installer, as far as I know the problem
has been solved... but this email may result on my finding out that it has
not been solved after all!
Regards,
Mike
----- Original Message -----
From: < Victor.Lazzarini@...>
To: < csound@...>
Sent: Monday, June 29, 2009 3:47 AM
Subject: [Csnd] Re: Csound's viability on Windows for non-technical users...
>
> 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.
>
> 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...
>
> 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.
>
> 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.
Victor
Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe
csound"
Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"
|
|
Re: Re: Re: Csound's viability on Windows for non-technical users...
Sorry Mike but the last time I installed the latest version of Csound
on a fresh machine Csound still complained about python2.whatever
missing. I guess this is because the python opcodes are still in the
opcode and bin directory even if users wish not to install python
first.
Rory.
2009/6/29 < michael.gogins@...>:
> I responded to most of these questions in my previous email.
>
> About Python and the Windows Csound installer, as far as I know the problem
> has been solved... but this email may result on my finding out that it has
> not been solved after all!
>
> Regards,
> Mike
>
> ----- Original Message ----- From: < Victor.Lazzarini@...>
> To: < csound@...>
> Sent: Monday, June 29, 2009 3:47 AM
> Subject: [Csnd] Re: Csound's viability on Windows for non-technical users...
>
>
>
>>
>> 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.
>
>>
>> 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...
>
>>
>> 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.
>
>>
>> 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.
>
>
> Victor
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"
>
Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"
|
|
Re: Re: Csound's viability on Windows for non-technical users...
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@... with body "unsubscribe csound"
|
|
Re: Re: Re: Re: Csound's viability on Windows for non-technical users...
The installer puts them in a different place if you don't opt for
Python. Are you sure you didn't install over an older installation and
still had these files in place from that?
Regards,
Mike
On 6/29/09, Rory Walsh < rorywalsh@...> wrote:
> Sorry Mike but the last time I installed the latest version of Csound
> on a fresh machine Csound still complained about python2.whatever
> missing. I guess this is because the python opcodes are still in the
> opcode and bin directory even if users wish not to install python
> first.
>
> Rory.
>
>
> 2009/6/29 < michael.gogins@...>:
>> I responded to most of these questions in my previous email.
>>
>> About Python and the Windows Csound installer, as far as I know the
>> problem
>> has been solved... but this email may result on my finding out that it has
>> not been solved after all!
>>
>> Regards,
>> Mike
>>
>> ----- Original Message ----- From: < Victor.Lazzarini@...>
>> To: < csound@...>
>> Sent: Monday, June 29, 2009 3:47 AM
>> Subject: [Csnd] Re: Csound's viability on Windows for non-technical
>> users...
>>
>>
>>
>>>
>>> 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.
>>
>>>
>>> 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...
>>
>>>
>>> 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.
>>
>>>
>>> 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.
>>
>>
>> Victor
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe
>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"
>
--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.comMichael dot Gogins at gmail dot com
Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"
|
|
Re: Re: Re: Re: Re: Csound's viability on Windows for non-technical users...
It was on a students computer. Saying that, he might well have had an
earlier install that he didn't mention to me. I have no more fresh
machines to try it out on. Maybe I'll head down to PC world and start
installing Csound on all their display models. On second thoughts I
better not. They'd probably start charging extra for the laptops with
Csound on them!
Rory.
2009/6/29 Michael Gogins < michael.gogins@...>:
> The installer puts them in a different place if you don't opt for
> Python. Are you sure you didn't install over an older installation and
> still had these files in place from that?
Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"
|
|
Re: Re: Csound's viability on Windows for non-technical users...
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Thanks Michael, That definitely helps. I'm sticking to mingw 3.4.5 for now but Csound runs so fast I don't think I'll need the performance boost from Twilight just yet... and thinking more about my roadmap for AudioCarver I'm realizing I'm going to need Python eventually anyway, so it'd be pointless to build it out of Csound now, then build it back in for version 2.0, lol. Scratch that idea. I'm not sure where I got the idea that the sjlj issue was crashing builds, now, but thank you for clearing it up for me. --- Is there anything I can do to help you work out the installation issues on Windows? ...this being priority number one for me. I'll have time to help after the show in July is over, if needed (although I've promised code to Andres for QuteCsound, too, and I'm much delayed -- sry Andres, I'll get to it eventually). Cheers, -andy.f ----- Original Message ----- From: "michael gogins" < michael.gogins@...> To: csound@...Sent: Monday, June 29, 2009 7:28:13 AM (GMT-0500) America/New_York Subject: [Csnd] Re: Csound's viability on Windows for non-technical users...
At this time the only build system for Csound that
is supported in CVS is SCons. There is a reason for this -- experience showed it
was much easier to use and maintain. If for some reason you had to use another
build system, I would recommend CodeBlocks, which is cross platform on Windows
and Linux. You would have to figure out the right options, macros, and so on
from SConstruct but, with enough patience, I am certain you could get it to
work, although I can't imagine why you would want to unless you are a
masochist.
The standard version of MinGW is and has always
been sjlj. This is simply the technical term for how GCC implements C++
exception handling. I think what you really want to know is whether you can
build with version 3.4.5 from the MinGW web site installer program, instead
of version 4 something from Twilight Dragon Media. And you should be
able to, since this is what we all used to use. Csound just won't run quite as
fast.
What is "core?" Depends on who you ask. You should
look at SConstruct and figure out what you really need to do what you want to
do. But your assumptions are correct, especially since you don't actually
need PortMidi or PortAudio (which in fact are NOT easy to build) on Windows, but
can use native Windows libraries (that is, unless you need LOW LATENCY real-time
audio, in which case you really do need to build PortAudio).
If you are going to create a standalone product
with Csound built in, then you will probably want to create your own installer.
This is not as hard as you might think, especially because you can just take the
Csound nullsoft installer script and add your own stuff to it and remove the
stuff you don't want.
Hope this helps,
Mike
----- Original Message -----
Sent: Sunday, June 28, 2009 8:52 PM
Subject: [Csnd] Csound's viability on
Windows for non-technical users...
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
|
|
Re: Re: Re: Csound's viability on Windows for non-technical users...
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Ok, well posts are flying all over the place on this and it seems I need to get a hold of a fresh machine and try a Csound install on it before I do anything else, since all the problems I had when starting to use Csound last year just magically disappeared =) Apparently my perceived "issues" were based on last years news. I feel much better about using Csound in my apps now. Thank you for the responses. Cheers, -andy.f ----- Original Message ----- From: "Andy Fillebrown" < andy@...> To: csound@...Sent: Monday, June 29, 2009 8:32:42 AM (GMT-0500) America/New_York Subject: [Csnd] Re: Re: Csound's viability on Windows for non-technical users... Thanks Michael, That definitely helps. I'm sticking to mingw 3.4.5 for now but Csound runs so fast I don't think I'll need the performance boost from Twilight just yet... and thinking more about my roadmap for AudioCarver I'm realizing I'm going to need Python eventually anyway, so it'd be pointless to build it out of Csound now, then build it back in for version 2.0, lol. Scratch that idea. I'm not sure where I got the idea that the sjlj issue was crashing builds, now, but thank you for clearing it up for me. --- Is there anything I can do to help you work out the installation issues on Windows? ...this being priority number one for me. I'll have time to help after the show in July is over, if needed (although I've promised code to Andres for QuteCsound, too, and I'm much delayed -- sry Andres, I'll get to it eventually). Cheers, -andy.f ----- Original Message ----- From: "michael gogins" < michael.gogins@...> To: csound@...Sent: Monday, June 29, 2009 7:28:13 AM (GMT-0500) America/New_York Subject: [Csnd] Re: Csound's viability on Windows for non-technical users...
At this time the only build system for Csound that
is supported in CVS is SCons. There is a reason for this -- experience showed it
was much easier to use and maintain. If for some reason you had to use another
build system, I would recommend CodeBlocks, which is cross platform on Windows
and Linux. You would have to figure out the right options, macros, and so on
from SConstruct but, with enough patience, I am certain you could get it to
work, although I can't imagine why you would want to unless you are a
masochist.
The standard version of MinGW is and has always
been sjlj. This is simply the technical term for how GCC implements C++
exception handling. I think what you really want to know is whether you can
build with version 3.4.5 from the MinGW web site installer program, instead
of version 4 something from Twilight Dragon Media. And you should be
able to, since this is what we all used to use. Csound just won't run quite as
fast.
What is "core?" Depends on who you ask. You should
look at SConstruct and figure out what you really need to do what you want to
do. But your assumptions are correct, especially since you don't actually
need PortMidi or PortAudio (which in fact are NOT easy to build) on Windows, but
can use native Windows libraries (that is, unless you need LOW LATENCY real-time
audio, in which case you really do need to build PortAudio).
If you are going to create a standalone product
with Csound built in, then you will probably want to create your own installer.
This is not as hard as you might think, especially because you can just take the
Csound nullsoft installer script and add your own stuff to it and remove the
stuff you don't want.
Hope this helps,
Mike
----- Original Message -----
Sent: Sunday, June 28, 2009 8:52 PM
Subject: [Csnd] Csound's viability on
Windows for non-technical users...
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
|
|
Re: Re: Re: Csound's viability on Windows for non-technical users...
builds and runs. No unexpected issues. ----- Original Message ----- From: Andy Fillebrown < andy@...> Date: Monday, June 29, 2009 12:51 pm Subject: [Csnd] Re: Re: Csound's viability on Windows for non-technical users... To: csound@...> > 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@... with body > "unsubscribe csound" Dr Victor Lazzarini, Senior Lecturer, Dept. of Music,National University of Ireland, Maynooth
|
|
Re: Re: Re: Csound's viability on Windows for non-technical users...
If you are planning to support a new build system for Csound, it might be worth 1) joining the csound developer team 2) adding your build scripts to csound cvs sources. ----- Original Message ----- From: Andy Fillebrown < andy@...> Date: Monday, June 29, 2009 12:51 pm Subject: [Csnd] Re: Re: Csound's viability on Windows for non-technical users... To: csound@...> > 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@... with body > "unsubscribe csound" Dr Victor Lazzarini, Senior Lecturer, Dept. of Music,National University of Ireland, Maynooth
|
|
Re: Re: Re: Re: Csound's viability on Windows for non-technical users...
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I'm going with the nsis route for now, and if I ever need to build from source I'll give scons another try since Python is good to know anyway. Knowing it's possible to build Csound with only mingw-3.4.5 and libsndfile makes me much more comfortable using it, even if I haven't built it locally. I can just limit what I use at the moment to those dependencies. ----- Original Message ----- From: "Victor Lazzarini" < Victor.Lazzarini@...> To: csound@...Sent: Monday, June 29, 2009 9:48:12 AM (GMT-0500) America/New_York Subject: [Csnd] Re: Re: Re: Csound's viability on Windows for non-technical users... If you are planning to support a new build system for Csound, it might be worth 1) joining the csound developer team 2) adding your build scripts to csound cvs sources. ----- Original Message ----- From: Andy Fillebrown < andy@...> Date: Monday, June 29, 2009 12:51 pm Subject: [Csnd] Re: Re: Csound's viability on Windows for non-technical users... To: csound@...> > 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@... with body > "unsubscribe csound" Dr Victor Lazzarini, Senior Lecturer, Dept. of Music,National University of Ireland, Maynooth
|
|
Re: Re: Csound's viability on Windows for non-technical users...
OK, I'll jump in here. (After all, I've been the lead complainer about the
Windows Python popup.)
Yes, the problem popup still lives - at least on Windows XP with the 5.10
float installer.
I've just done a thorough test, uninstalling all versions of Csound and
clearing out all Csound-related environment variables. (I also searched for
any other files with "python" in their names. Nothing. I can vouch that
Python is *not* installed.)
I did a clean install of the float installer, specifying to continue without
Python2.5.
Running a realtime .csd from the commandline:
1) I get the "can't find Python2.5.dll" popup window. Clicking OK allows me
to continue normally.
2) There is an additional warning message inline only: "could not open
library Csound\plugins\csnd.dll. (I really wish this message would disappear
as well.)
3) The .csd performs normally except for one problem:
4) CTRL-C does not exit cleanly; CTRL-ALT-DEL is required (which returns to
Windows, in turn requiring a return to the appropriate commandline
directory).
Mike, IMO it would be really helpful if you had a Windows system without
Csound on which you could try out new installs (at least float versions)
with a simple realtime csd. (I'd be happy to come up with the latter: no
MIDI, just an ASCII key to turn a note on and off for testing purposes.) I
think this could save us all a portion of grief.
And - thanks for all your wonderful, tireless work.
Art Hunkins
----- Original Message -----
From: "Rory Walsh" < rorywalsh@...>
To: < csound@...>
Sent: Monday, June 29, 2009 7:43 AM
Subject: [Csnd] Re: Re: Re: Csound's viability on Windows for non-technical
users...
> Sorry Mike but the last time I installed the latest version of Csound
> on a fresh machine Csound still complained about python2.whatever
> missing. I guess this is because the python opcodes are still in the
> opcode and bin directory even if users wish not to install python
> first.
>
> Rory.
>
>
> 2009/6/29 < michael.gogins@...>:
>> I responded to most of these questions in my previous email.
>>
>> About Python and the Windows Csound installer, as far as I know the
>> problem
>> has been solved... but this email may result on my finding out that it
>> has
>> not been solved after all!
>>
>> Regards,
>> Mike
>>
>> ----- Original Message ----- From: < Victor.Lazzarini@...>
>> To: < csound@...>
>> Sent: Monday, June 29, 2009 3:47 AM
>> Subject: [Csnd] Re: Csound's viability on Windows for non-technical
>> users...
>>
>>
>>
>>>
>>> 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.
>>
>>>
>>> 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...
>>
>>>
>>> 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.
>>
>>>
>>> 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.
>>
>>
>> Victor
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe
>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"
Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"
|
|
Re: Re: Re: Csound's viability on Windows for non-technical users...
Thanks for the information. I will make every effort to fix this, I
know it is annoying.
For your information, to test this, I remove Csound and Python from
my computer, and then I install Csound. There were no annoying popups
for me last time I tried this.
I'd be interested to hear if anyone has installed and not had the
popup appear AND they didn't have Python....
In theory you should not see the popup if Csound can't find any plugin
opcode that is linked to the Python library and if Csound can't find
_csnd or _CsoundAC.
Regards,
Mike
On 6/30/09, Art Hunkins < abhunkin@...> wrote:
> OK, I'll jump in here. (After all, I've been the lead complainer about the
> Windows Python popup.)
>
> Yes, the problem popup still lives - at least on Windows XP with the 5.10
> float installer.
>
> I've just done a thorough test, uninstalling all versions of Csound and
> clearing out all Csound-related environment variables. (I also searched for
> any other files with "python" in their names. Nothing. I can vouch that
> Python is *not* installed.)
>
> I did a clean install of the float installer, specifying to continue without
> Python2.5.
>
> Running a realtime .csd from the commandline:
>
> 1) I get the "can't find Python2.5.dll" popup window. Clicking OK allows me
> to continue normally.
> 2) There is an additional warning message inline only: "could not open
> library Csound\plugins\csnd.dll. (I really wish this message would disappear
> as well.)
> 3) The .csd performs normally except for one problem:
> 4) CTRL-C does not exit cleanly; CTRL-ALT-DEL is required (which returns to
> Windows, in turn requiring a return to the appropriate commandline
> directory).
>
> Mike, IMO it would be really helpful if you had a Windows system without
> Csound on which you could try out new installs (at least float versions)
> with a simple realtime csd. (I'd be happy to come up with the latter: no
> MIDI, just an ASCII key to turn a note on and off for testing purposes.) I
> think this could save us all a portion of grief.
>
> And - thanks for all your wonderful, tireless work.
>
> Art Hunkins
>
> ----- Original Message -----
> From: "Rory Walsh" < rorywalsh@...>
> To: < csound@...>
> Sent: Monday, June 29, 2009 7:43 AM
> Subject: [Csnd] Re: Re: Re: Csound's viability on Windows for non-technical
> users...
>
>
>> Sorry Mike but the last time I installed the latest version of Csound
>> on a fresh machine Csound still complained about python2.whatever
>> missing. I guess this is because the python opcodes are still in the
>> opcode and bin directory even if users wish not to install python
>> first.
>>
>> Rory.
>>
>>
>> 2009/6/29 < michael.gogins@...>:
>>> I responded to most of these questions in my previous email.
>>>
>>> About Python and the Windows Csound installer, as far as I know the
>>> problem
>>> has been solved... but this email may result on my finding out that it
>>> has
>>> not been solved after all!
>>>
>>> Regards,
>>> Mike
>>>
>>> ----- Original Message ----- From: < Victor.Lazzarini@...>
>>> To: < csound@...>
>>> Sent: Monday, June 29, 2009 3:47 AM
>>> Subject: [Csnd] Re: Csound's viability on Windows for non-technical
>>> users...
>>>
>>>
>>>
>>>>
>>>> 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.
>>>
>>>>
>>>> 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...
>>>
>>>>
>>>> 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.
>>>
>>>>
>>>> 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.
>>>
>>>
>>> Victor
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@... with body "unsubscribe
>>> csound"
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@... with body "unsubscribe
>>> csound"
>>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe
>> csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"
>
--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.comMichael dot Gogins at gmail dot com
Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"
|
