I would like to re-express my frustration with Csound's library names
on Windows.  I would like csound32.dll.5.2 and csound64.dll.5.2 to be
renamed to the standard csound32-5.2.dll and csound64-5.2.dll (or
something else ending in .dll, at least), and the different versions
of csnd.dll renamed to csnd32.dll and csnd64.dll so that I don't have
to keep messing with my PATH variable to be able to run both versions.
 I realize there are issues with renaming them but I am finding it
incredibly annoying dealing with them as they are and I would be
remiss to not say or do anything about it after all the cursing I've
done under my breath =)

>From what I gathered from the csnd.dll renaming issues raised the last
time I brought this up, it is do-able, and I will be happy to do it
myself if it's the only way it will get done.  Just point me in the
right direction and I'll start gathering info and putting a plan
together on how best to go about it.

Cheers,
~ andy.f

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Fri, Mar 12, 2010 at 20:55, andy fillebrown
 wrote:
> I would like to re-express my frustration with Csound's library names
> on Windows.  I would like csound32.dll.5.2 and csound64.dll.5.2 to be
> renamed to the standard csound32-5.2.dll and csound64-5.2.dll (or
> something else ending in .dll, at least), and the different versions
> of csnd.dll renamed to csnd32.dll and csnd64.dll so that I don't have
> to keep messing with my PATH variable to be able to run both versions.

I do not understand why do you need to change PATH and how changing
the difference from after .dll to before will help. Could you
elaborate please?

>  I realize there are issues with renaming them but I am finding it
> incredibly annoying dealing with them as they are and I would be
> remiss to not say or do anything about it after all the cursing I've
> done under my breath =)
>
> From what I gathered from the csnd.dll renaming issues raised the last
> time I brought this up, it is do-able, and I will be happy to do it
> myself if it's the only way it will get done.  Just point me in the
> right direction and I'll start gathering info and putting a plan
> together on how best to go about it.

I think it is most certainly doable, but probable it should wait until
an API bump to make the most out of the inconvenience.

-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound

On Fri, Mar 12, 2010 at 7:27 PM, Felipe Sateler  wrote:
> On Fri, Mar 12, 2010 at 20:55, andy fillebrown
>  wrote:
>> I would like to re-express my frustration with Csound's library names
>> on Windows.  I would like csound32.dll.5.2 and csound64.dll.5.2 to be
>> renamed to the standard csound32-5.2.dll and csound64-5.2.dll (or
>> something else ending in .dll, at least), and the different versions
>> of csnd.dll renamed to csnd32.dll and csnd64.dll so that I don't have
>> to keep messing with my PATH variable to be able to run both versions.
>
> I do not understand why do you need to change PATH and how changing
> the difference from after .dll to before will help. Could you
> elaborate please?

The PATH issue is encountered when both the single and double
precision versions of Csound are installed.  When both of their bin
directories are added to the PATH variable it makes getting to the
correct version of csnd.dll problematic.  If the floats version of
Csound appears in PATH first, it is that version of csnd.dll that gets
loaded regardless of whether or not it's the one you actually want.
Say, for example, Csound32, Csound64, QuteCsound32, and QuteCsound64
are installed in that order.  QuteCsound64 won't run because it will
find the csnd.dll from the Csound32 install first, assume it's the
correct csnd.dll, and choke on missing references when it tries to use
it.  The problem goes away if the two versions of csnd.dll are given
version-specific names.  As it is, in order for me to use QuteCsound64
after installing Csound32, I have to edit the PATH variable so that
the Csound64 installation is seen by it and not hidden by the Csound32
bin directory that precedes it.  I can either remove the Csound32 bin
directory from it, or reverse the order so that the Csound64 bin
directory comes before the Csound32 bin -- which is do-able but it is
an annoyance.  Regardless, it is impossible to run both QuteCsound32
and QuteCsound64 out of the box without editing the PATH variable
before starting one or the other.

The .dll extension issue is also just an annoyance.  With the .5.2 at
the end of the name, things like "g++ -lcsound32" fail when using
mingw due to the non-standard .5.2 extension, so the full path and
file name must be used instead.  It's ugly and it's not portable.  Why
does the .5.2 come after the .dll, anyway?  Is there some reason that
I'm unaware of?

Anyway, as I said, these are only annoyances.  They can be worked
around fairly easily with batch files, but they shouldn't have to be
worked around at all.  When things go wrong it's just "one more thing"
to have to check on, and it's bad enough I have to deal with all this
environment variable nonsense to begin with, never mind fiddling with
them constantly just to get things to work consistently

Death to environment variables, I say! =)

>>  I realize there are issues with renaming them but I am finding it
>> incredibly annoying dealing with them as they are and I would be
>> remiss to not say or do anything about it after all the cursing I've
>> done under my breath =)
>>
>> From what I gathered from the csnd.dll renaming issues raised the last
>> time I brought this up, it is do-able, and I will be happy to do it
>> myself if it's the only way it will get done.  Just point me in the
>> right direction and I'll start gathering info and putting a plan
>> together on how best to go about it.
>
> I think it is most certainly doable, but probable it should wait until
> an API bump to make the most out of the inconvenience.

Is there an API bump scheduled?

Cheers,
~ andy.f

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Sat, Mar 13, 2010 at 01:08, andy fillebrown
 wrote:
> On Fri, Mar 12, 2010 at 7:27 PM, Felipe Sateler  wrote:
>> On Fri, Mar 12, 2010 at 20:55, andy fillebrown
>>  wrote:
>>> I would like to re-express my frustration with Csound's library names
>>> on Windows.  I would like csound32.dll.5.2 and csound64.dll.5.2 to be
>>> renamed to the standard csound32-5.2.dll and csound64-5.2.dll (or
>>> something else ending in .dll, at least), and the different versions
>>> of csnd.dll renamed to csnd32.dll and csnd64.dll so that I don't have
>>> to keep messing with my PATH variable to be able to run both versions.
>>
>> I do not understand why do you need to change PATH and how changing
>> the difference from after .dll to before will help. Could you
>> elaborate please?
>
> The PATH issue is encountered when both the single and double
> precision versions of Csound are installed.  When both of their bin
> directories are added to the PATH variable it makes getting to the
> correct version of csnd.dll problematic.  If the floats version of
> Csound appears in PATH first, it is that version of csnd.dll that gets
> loaded regardless of whether or not it's the one you actually want.
> Say, for example, Csound32, Csound64, QuteCsound32, and QuteCsound64
> are installed in that order.  QuteCsound64 won't run because it will
> find the csnd.dll from the Csound32 install first, assume it's the
> correct csnd.dll, and choke on missing references when it tries to use
> it.  The problem goes away if the two versions of csnd.dll are given
> version-specific names.  As it is, in order for me to use QuteCsound64
> after installing Csound32, I have to edit the PATH variable so that
> the Csound64 installation is seen by it and not hidden by the Csound32
> bin directory that precedes it.  I can either remove the Csound32 bin
> directory from it, or reverse the order so that the Csound64 bin
> directory comes before the Csound32 bin -- which is do-able but it is
> an annoyance.  Regardless, it is impossible to run both QuteCsound32
> and QuteCsound64 out of the box without editing the PATH variable
> before starting one or the other.

Ah, so the runtime problem is mainly the untagged csnd.dll, not csound.dll.

>
> The .dll extension issue is also just an annoyance.  With the .5.2 at
> the end of the name, things like "g++ -lcsound32" fail when using
> mingw due to the non-standard .5.2 extension, so the full path and
> file name must be used instead.  It's ugly and it's not portable.  Why
> does the .5.2 come after the .dll, anyway?  Is there some reason that
> I'm unaware of?

In Unix, versions come after the name (so it is also csound.so.5.2),
and it is the runtime version of the library. At link time, one must
have a csound.so link pointing to the appropriate version of the
library one wants to use. I figure that the windows naming pattern
followed the unix one. I do not know if the symlink thing can be
ported to windows, though.

>
> Anyway, as I said, these are only annoyances.  They can be worked
> around fairly easily with batch files, but they shouldn't have to be
> worked around at all.  When things go wrong it's just "one more thing"
> to have to check on, and it's bad enough I have to deal with all this
> environment variable nonsense to begin with, never mind fiddling with
> them constantly just to get things to work consistently
>
> Death to environment variables, I say! =)

I say death to more than one version of csound, instead. Having floats
and doubles versions is just annoying. If we could just get an
agreement on which version should be the one supported, then the world
would be a much better place :p.

>
>>>  I realize there are issues with renaming them but I am finding it
>>> incredibly annoying dealing with them as they are and I would be
>>> remiss to not say or do anything about it after all the cursing I've
>>> done under my breath =)
>>>
>>> From what I gathered from the csnd.dll renaming issues raised the last
>>> time I brought this up, it is do-able, and I will be happy to do it
>>> myself if it's the only way it will get done.  Just point me in the
>>> right direction and I'll start gathering info and putting a plan
>>> together on how best to go about it.
>>
>> I think it is most certainly doable, but probable it should wait until
>> an API bump to make the most out of the inconvenience.
>
> Is there an API bump scheduled?

Not that I know of.


-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https

> In Unix, versions come after the name (so it is also csound.so.5.2),
> and it is the runtime version of the library. At link time, one must
> have a csound.so link pointing to the appropriate version of the
> library one wants to use. I figure that the windows naming pattern
> followed the unix one. I do not know if the symlink thing can be
> ported to windows, though.

That makes sense.  Unfortunately there is no Windows equivalent to
symlinks, afaik.


>> Death to environment variables, I say! =)
>
> I say death to more than one version of csound, instead. Having floats
> and doubles versions is just annoying. If we could just get an
> agreement on which version should be the one supported, then the world
> would be a much better place :p.

I would agree if both the single and double precision versions were
combined into one package, but I love the sound of the double
precision version and the speed of the single precision.  I'm not
willing to sacrifice either one if I can have them both, and if the
csnd.dll files weren't both the same name it would be easy (on
Windows, anyway).

>> Is there an API bump scheduled?
>
> Not that I know of.

Maybe this would be a good reason to schedule one, instead of tying in
unrelated changes into the beta?

~ andy.f

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The module names are difficult not only because of the operating
system but also because they must be as generated and used by SWIG for
the Python, Java, and Lua wrappers. Please do not change them or these
wrappers will simply break.

I whole-heartedly agree with Felipe about distributing only one
version of Csound. Because the double version does sound more precise
in double-blind listening tests with at least this listener, that
should be the supported version. Threading will make up for any
performance deficit (which is modest, anyway) -- distributing the
threaded code should be a priority.

Regards,
Mike



On Fri, Mar 12, 2010 at 11:57 PM, Felipe Sateler  wrote:
> On Sat, Mar 13, 2010 at 01:08, andy fillebrown
>  wrote:
>> On Fri, Mar 12, 2010 at 7:27 PM, Felipe Sateler  wrote:
>>> On Fri, Mar 12, 2010 at 20:55, andy fillebrown
>>>  wrote:
>>>> I would like to re-express my frustration with Csound's library names
>>>> on Windows.  I would like csound32.dll.5.2 and csound64.dll.5.2 to be
>>>> renamed to the standard csound32-5.2.dll and csound64-5.2.dll (or
>>>> something else ending in .dll, at least), and the different versions
>>>> of csnd.dll renamed to csnd32.dll and csnd64.dll so that I don't have
>>>> to keep messing with my PATH variable to be able to run both versions.
>>>
>>> I do not understand why do you need to change PATH and how changing
>>> the difference from after .dll to before will help. Could you
>>> elaborate please?
>>
>> The PATH issue is encountered when both the single and double
>> precision versions of Csound are installed.  When both of their bin
>> directories are added to the PATH variable it makes getting to the
>> correct version of csnd.dll problematic.  If the floats version of
>> Csound appears in PATH first, it is that version of csnd.dll that gets
>> loaded regardless of whether or not it's the one you actually want.
>> Say, for example, Csound32, Csound64, QuteCsound32, and QuteCsound64
>> are installed in that order.  QuteCsound64 won't run because it will
>> find the csnd.dll from the Csound32 install first, assume it's the
>> correct csnd.dll, and choke on missing references when it tries to use
>> it.  The problem goes away if the two versions of csnd.dll are given
>> version-specific names.  As it is, in order for me to use QuteCsound64
>> after installing Csound32, I have to edit the PATH variable so that
>> the Csound64 installation is seen by it and not hidden by the Csound32
>> bin directory that precedes it.  I can either remove the Csound32 bin
>> directory from it, or reverse the order so that the Csound64 bin
>> directory comes before the Csound32 bin -- which is do-able but it is
>> an annoyance.  Regardless, it is impossible to run both QuteCsound32
>> and QuteCsound64 out of the box without editing the PATH variable
>> before starting one or the other.
>
> Ah, so the runtime problem is mainly the untagged csnd.dll, not csound.dll.
>
>>
>> The .dll extension issue is also just an annoyance.  With the .5.2 at
>> the end of the name, things like "g++ -lcsound32" fail when using
>> mingw due to the non-standard .5.2 extension, so the full path and
>> file name must be used instead.  It's ugly and it's not portable.  Why
>> does the .5.2 come after the .dll, anyway?  Is there some reason that
>> I'm unaware of?
>
> In Unix, versions come after the name (so it is also csound.so.5.2),
> and it is the runtime version of the library. At link time, one must
> have a csound.so link pointing to the appropriate version of the
> library one wants to use. I figure that the windows naming pattern
> followed the unix one. I do not know if the symlink thing can be
> ported to windows, though.
>
>>
>> Anyway, as I said, these are only annoyances.  They can be worked
>> around fairly easily with batch files, but they shouldn't have to be
>> worked around at all.  When things go wrong it's just "one more thing"
>> to have to check on, and it's bad enough I have to deal with all this
>> environment variable nonsense to begin with, never mind fiddling with
>> them constantly just to get things to work consistently
>>
>> Death to environment variables, I say! =)
>
> I say death to more than one version of csound, instead. Having floats
> and doubles versions is just annoying. If we could just get an
> agreement on which version should be the one supported, then the world
> would be a much better place :p.
>
>>
>>>>  I realize there are issues with renaming them but I am finding it
>>>> incredibly annoying dealing with them as they are and I would be
>>>> remiss to not say or do anything about it after all the cursing I've
>>>> done under my breath =)
>>>>
>>>> From what I gathered from the csnd.dll renaming issues raised the last
>>>> time I brought this up, it is do-able, and I will be happy to do it
>>>> myself if it's the only way it will get done.  Just point me in the
>>>> right direction and I'll start gathering info and putting a plan
>>>> together on how best to go about it.
>>>
>>> I think it is most certainly doable, but probable it should wait until
>>> an API bump to make the most out of the inconvenience.
>>
>> Is there an API bump scheduled?
>
> Not that I know of.
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think Victor has done a wonderful job in packaging for OSX in
supporting both float and doubles in the same installer.  It comes
with a "csound" and "csound64" commandline executable and the
frameworks are separated with and with out 64.

I know some 8 or 9 years ago that Csound on linux was being
built/distributed with the same naming of csound and csound64.  I
don't remember if Windows ever had that.

I'd really prefer just doubles from this point on myself. Since we
have legacy pieces using file formats that are dependent on float or
doubles (I think this applies for the older convolution opcodes,
perhaps some of the other analysis/resynthesis formats), it seems we
need to have some means for users to be able to have access to a float
build.

I think having doubles as the standard for all package managers and
installers is a good thing.  From an API perspective, I'd prefer clear
naming for float or double build so that linking doesn't depend on if
a user happens to have installed one or the other that happens to have
the same name.

I think it'd be nice if we make "csound" be the double build and the
default and "csound32" be used for legacy purposes and those who
specifically want the little speed boost.  Reasoning for this is that
new users by default would get the higher-quality build. I think it's
better to start with higher-quality and really push it until it
becomes a performance issue then move over to floats, as I think with
computers these days most people won't hit processing limits anyways.

I think Andy's comments though are completely valid, and library
naming is an issue.  If the names change, what are the impacts?  If
the default is to doubles and 32 is added, I would imagine most API
users would not be too affected for those that go through a secondary
interface like Python and Java.  For those directly linking to the
library, I imagine it may cause an issue.

I know it would be sort of a pain for API users as I think we'd all
have to upgrade in some way (plus bump the API version) and issue new
builds, but I think if this is clearly worked out then it would set
things up for the future.

Thoughts?
steven


On Sat, Mar 13, 2010 at 11:09 AM, Michael Gogins
 wrote:
> The module names are difficult not only because of the operating
> system but also because they must be as generated and used by SWIG for
> the Python, Java, and Lua wrappers. Please do not change them or these
> wrappers will simply break.
>
> I whole-heartedly agree with Felipe about distributing only one
> version of Csound. Because the double version does sound more precise
> in double-blind listening tests with at least this listener, that
> should be the supported version. Threading will make up for any
> performance deficit (which is modest, anyway) -- distributing the
> threaded code should be a priority.
>
> Regards,
> Mike
>
>
>
> On Fri, Mar 12, 2010 at 11:57 PM, Felipe Sateler  wrote:
>> On Sat, Mar 13, 2010 at 01:08, andy fillebrown
>>  wrote:
>>> On Fri, Mar 12, 2010 at 7:27 PM, Felipe Sateler  wrote:
>>>> On Fri, Mar 12, 2010 at 20:55, andy fillebrown
>>>>  wrote:
>>>>> I would like to re-express my frustration with Csound's library names
>>>>> on Windows.  I would like csound32.dll.5.2 and csound64.dll.5.2 to be
>>>>> renamed to the standard csound32-5.2.dll and csound64-5.2.dll (or
>>>>> something else ending in .dll, at least), and the different versions
>>>>> of csnd.dll renamed to csnd32.dll and csnd64.dll so that I don't have
>>>>> to keep messing with my PATH variable to be able to run both versions.
>>>>
>>>> I do not understand why do you need to change PATH and how changing
>>>> the difference from after .dll to before will help. Could you
>>>> elaborate please?
>>>
>>> The PATH issue is encountered when both the single and double
>>> precision versions of Csound are installed.  When both of their bin
>>> directories are added to the PATH variable it makes getting to the
>>> correct version of csnd.dll problematic.  If the floats version of
>>> Csound appears in PATH first, it is that version of csnd.dll that gets
>>> loaded regardless of whether or not it's the one you actually want.
>>> Say, for example, Csound32, Csound64, QuteCsound32, and QuteCsound64
>>> are installed in that order.  QuteCsound64 won't run because it will
>>> find the csnd.dll from the Csound32 install first, assume it's the
>>> correct csnd.dll, and choke on missing references when it tries to use
>>> it.  The problem goes away if the two versions of csnd.dll are given
>>> version-specific names.  As it is, in order for me to use QuteCsound64
>>> after installing Csound32, I have to edit the PATH variable so that
>>> the Csound64 installation is seen by it and not hidden by the Csound32
>>> bin directory that precedes it.  I can either remove the Csound32 bin
>>> directory from it, or reverse the order so that the Csound64 bin
>>> directory comes before the Csound32 bin -- which is do-able but it is
>>> an annoyance.  Regardless, it is impossible to run both QuteCsound32
>>> and QuteCsound64 out of the box without editing the PATH variable
>>> before starting one or the other.
>>
>> Ah, so the runtime problem is mainly the untagged csnd.dll, not csound.dll.
>>
>>>
>>> The .dll extension issue is also just an annoyance.  With the .5.2 at
>>> the end of the name, things like "g++ -lcsound32" fail when using
>>> mingw due to the non-standard .5.2 extension, so the full path and
>>> file name must be used instead.  It's ugly and it's not portable.  Why
>>> does the .5.2 come after the .dll, anyway?  Is there some reason that
>>> I'm unaware of?
>>
>> In Unix, versions come after the name (so it is also csound.so.5.2),
>> and it is the runtime version of the library. At link time, one must
>> have a csound.so link pointing to the appropriate version of the
>> library one wants to use. I figure that the windows naming pattern
>> followed the unix one. I do not know if the symlink thing can be
>> ported to windows, though.
>>
>>>
>>> Anyway, as I said, these are only annoyances.  They can be worked
>>> around fairly easily with batch files, but they shouldn't have to be
>>> worked around at all.  When things go wrong it's just "one more thing"
>>> to have to check on, and it's bad enough I have to deal with all this
>>> environment variable nonsense to begin with, never mind fiddling with
>>> them constantly just to get things to work consistently
>>>
>>> Death to environment variables, I say! =)
>>
>> I say death to more than one version of csound, instead. Having floats
>> and doubles versions is just annoying. If we could just get an
>> agreement on which version should be the one supported, then the world
>> would be a much better place :p.
>>
>>>
>>>>>  I realize there are issues with renaming them but I am finding it
>>>>> incredibly annoying dealing with them as they are and I would be
>>>>> remiss to not say or do anything about it after all the cursing I've
>>>>> done under my breath =)
>>>>>
>>>>> From what I gathered from the csnd.dll renaming issues raised the last
>>>>> time I brought this up, it is do-able, and I will be happy to do it
>>>>> myself if it's the only way it will get done.  Just point me in the
>>>>> right direction and I'll start gathering info and putting a plan
>>>>> together on how best to go about it.
>>>>
>>>> I think it is most certainly doable, but probable it should wait until
>>>> an API bump to make the most out of the inconvenience.
>>>
>>> Is there an API bump scheduled?
>>
>> Not that I know of.
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I agree with your suggestions.

The only issue is Python scripts, Java programs, etc. can only be used
with one build (or the other) of Csound. Currrently, you can use the
same Python script with either the 32 bit or the 64 bit build. This
will not be possible if we follow your suggestion. But I think the
advantages far outweigh this. The only change most people would need
to make, assuming that anyone besides me ever does this anyway, is to
change "import csnd" to "import csnd32" or something. And this can be
handled by a try/except block in Python anyway.

So again, I agree with your suggestions.

Best,
Mike

On Sat, Mar 13, 2010 at 11:37 AM, Steven Yi  wrote:
> I think Victor has done a wonderful job in packaging for OSX in
> supporting both float and doubles in the same installer.  It comes
> with a "csound" and "csound64" commandline executable and the
> frameworks are separated with and with out 64.
>
> I know some 8 or 9 years ago that Csound on linux was being
> built/distributed with the same naming of csound and csound64.  I
> don't remember if Windows ever had that.
>
> I'd really prefer just doubles from this point on myself. Since we
> have legacy pieces using file formats that are dependent on float or
> doubles (I think this applies for the older convolution opcodes,
> perhaps some of the other analysis/resynthesis formats), it seems we
> need to have some means for users to be able to have access to a float
> build.
>
> I think having doubles as the standard for all package managers and
> installers is a good thing.  From an API perspective, I'd prefer clear
> naming for float or double build so that linking doesn't depend on if
> a user happens to have installed one or the other that happens to have
> the same name.
>
> I think it'd be nice if we make "csound" be the double build and the
> default and "csound32" be used for legacy purposes and those who
> specifically want the little speed boost.  Reasoning for this is that
> new users by default would get the higher-quality build. I think it's
> better to start with higher-quality and really push it until it
> becomes a performance issue then move over to floats, as I think with
> computers these days most people won't hit processing limits anyways.
>
> I think Andy's comments though are completely valid, and library
> naming is an issue.  If the names change, what are the impacts?  If
> the default is to doubles and 32 is added, I would imagine most API
> users would not be too affected for those that go through a secondary
> interface like Python and Java.  For those directly linking to the
> library, I imagine it may cause an issue.
>
> I know it would be sort of a pain for API users as I think we'd all
> have to upgrade in some way (plus bump the API version) and issue new
> builds, but I think if this is clearly worked out then it would set
> things up for the future.
>
> Thoughts?
> steven
>
>
> On Sat, Mar 13, 2010 at 11:09 AM, Michael Gogins
>  wrote:
>> The module names are difficult not only because of the operating
>> system but also because they must be as generated and used by SWIG for
>> the Python, Java, and Lua wrappers. Please do not change them or these
>> wrappers will simply break.
>>
>> I whole-heartedly agree with Felipe about distributing only one
>> version of Csound. Because the double version does sound more precise
>> in double-blind listening tests with at least this listener, that
>> should be the supported version. Threading will make up for any
>> performance deficit (which is modest, anyway) -- distributing the
>> threaded code should be a priority.
>>
>> Regards,
>> Mike
>>
>>
>>
>> On Fri, Mar 12, 2010 at 11:57 PM, Felipe Sateler  wrote:
>>> On Sat, Mar 13, 2010 at 01:08, andy fillebrown
>>>  wrote:
>>>> On Fri, Mar 12, 2010 at 7:27 PM, Felipe Sateler  wrote:
>>>>> On Fri, Mar 12, 2010 at 20:55, andy fillebrown
>>>>>  wrote:
>>>>>> I would like to re-express my frustration with Csound's library names
>>>>>> on Windows.  I would like csound32.dll.5.2 and csound64.dll.5.2 to be
>>>>>> renamed to the standard csound32-5.2.dll and csound64-5.2.dll (or
>>>>>> something else ending in .dll, at least), and the different versions
>>>>>> of csnd.dll renamed to csnd32.dll and csnd64.dll so that I don't have
>>>>>> to keep messing with my PATH variable to be able to run both versions.
>>>>>
>>>>> I do not understand why do you need to change PATH and how changing
>>>>> the difference from after .dll to before will help. Could you
>>>>> elaborate please?
>>>>
>>>> The PATH issue is encountered when both the single and double
>>>> precision versions of Csound are installed.  When both of their bin
>>>> directories are added to the PATH variable it makes getting to the
>>>> correct version of csnd.dll problematic.  If the floats version of
>>>> Csound appears in PATH first, it is that version of csnd.dll that gets
>>>> loaded regardless of whether or not it's the one you actually want.
>>>> Say, for example, Csound32, Csound64, QuteCsound32, and QuteCsound64
>>>> are installed in that order.  QuteCsound64 won't run because it will
>>>> find the csnd.dll from the Csound32 install first, assume it's the
>>>> correct csnd.dll, and choke on missing references when it tries to use
>>>> it.  The problem goes away if the two versions of csnd.dll are given
>>>> version-specific names.  As it is, in order for me to use QuteCsound64
>>>> after installing Csound32, I have to edit the PATH variable so that
>>>> the Csound64 installation is seen by it and not hidden by the Csound32
>>>> bin directory that precedes it.  I can either remove the Csound32 bin
>>>> directory from it, or reverse the order so that the Csound64 bin
>>>> directory comes before the Csound32 bin -- which is do-able but it is
>>>> an annoyance.  Regardless, it is impossible to run both QuteCsound32
>>>> and QuteCsound64 out of the box without editing the PATH variable
>>>> before starting one or the other.
>>>
>>> Ah, so the runtime problem is mainly the untagged csnd.dll, not csound.dll.
>>>
>>>>
>>>> The .dll extension issue is also just an annoyance.  With the .5.2 at
>>>> the end of the name, things like "g++ -lcsound32" fail when using
>>>> mingw due to the non-standard .5.2 extension, so the full path and
>>>> file name must be used instead.  It's ugly and it's not portable.  Why
>>>> does the .5.2 come after the .dll, anyway?  Is there some reason that
>>>> I'm unaware of?
>>>
>>> In Unix, versions come after the name (so it is also csound.so.5.2),
>>> and it is the runtime version of the library. At link time, one must
>>> have a csound.so link pointing to the appropriate version of the
>>> library one wants to use. I figure that the windows naming pattern
>>> followed the unix one. I do not know if the symlink thing can be
>>> ported to windows, though.
>>>
>>>>
>>>> Anyway, as I said, these are only annoyances.  They can be worked
>>>> around fairly easily with batch files, but they shouldn't have to be
>>>> worked around at all.  When things go wrong it's just "one more thing"
>>>> to have to check on, and it's bad enough I have to deal with all this
>>>> environment variable nonsense to begin with, never mind fiddling with
>>>> them constantly just to get things to work consistently
>>>>
>>>> Death to environment variables, I say! =)
>>>
>>> I say death to more than one version of csound, instead. Having floats
>>> and doubles versions is just annoying. If we could just get an
>>> agreement on which version should be the one supported, then the world
>>> would be a much better place :p.
>>>
>>>>
>>>>>>  I realize there are issues with renaming them but I am finding it
>>>>>> incredibly annoying dealing with them as they are and I would be
>>>>>> remiss to not say or do anything about it after all the cursing I've
>>>>>> done under my breath =)
>>>>>>
>>>>>> From what I gathered from the csnd.dll renaming issues raised the last
>>>>>> time I brought this up, it is do-able, and I will be happy to do it
>>>>>> myself if it's the only way it will get done.  Just point me in the
>>>>>> right direction and I'll start gathering info and putting a plan
>>>>>> together on how best to go about it.
>>>>>
>>>>> I think it is most certainly doable, but probable it should wait until
>>>>> an API bump to make the most out of the inconvenience.
>>>>
>>>> Is there an API bump scheduled?
>>>
>>> Not that I know of.
>>>
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I don't think dropping the single precision version of csound from the
packages is a good idea.  For many users the speed difference is
significant.  Perhaps a Csound-6 that includes csound32-6 and
csound64-6 in the same bin directory is in order?  Maybe they could be
differentiated by "single" and "double" instead of "float" and
"double", or maybe "1x" and "2x" instead of "32" and "64" -- to make
it clearer to non-programmers that the precision of one is greater
than the other, while at the same time avoiding confusion with 32 and
64 bit operating systems?

~ andy.f

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

As discussed before in this list, different naming schemes can be
worked around in python by a ~10 lines script (that is, the csnd
module would be a wrapper around the 32 or 64 bit versions). I do not
believe Java can have this flexibility, though. In static-typing
languages this cannot be avoided. In others I believe it is (like the
python case).

Another advantage of renaming csnd.dll is that mismatches between
applications and library will be catched at application start time
instead of a possibly hard to debug crash elsewhere.

On Sat, Mar 13, 2010 at 12:50, Michael Gogins  wrote:
> I agree with your suggestions.
>
> The only issue is Python scripts, Java programs, etc. can only be used
> with one build (or the other) of Csound. Currrently, you can use the
> same Python script with either the 32 bit or the 64 bit build. This
> will not be possible if we follow your suggestion. But I think the
> advantages far outweigh this. The only change most people would need
> to make, assuming that anyone besides me ever does this anyway, is to
> change "import csnd" to "import csnd32" or something. And this can be
> handled by a try/except block in Python anyway.
>
> So again, I agree with your suggestions.
>
> Best,
> Mike
>
> On Sat, Mar 13, 2010 at 11:37 AM, Steven Yi  wrote:
>> I think Victor has done a wonderful job in packaging for OSX in
>> supporting both float and doubles in the same installer.  It comes
>> with a "csound" and "csound64" commandline executable and the
>> frameworks are separated with and with out 64.
>>
>> I know some 8 or 9 years ago that Csound on linux was being
>> built/distributed with the same naming of csound and csound64.  I
>> don't remember if Windows ever had that.
>>
>> I'd really prefer just doubles from this point on myself. Since we
>> have legacy pieces using file formats that are dependent on float or
>> doubles (I think this applies for the older convolution opcodes,
>> perhaps some of the other analysis/resynthesis formats), it seems we
>> need to have some means for users to be able to have access to a float
>> build.
>>
>> I think having doubles as the standard for all package managers and
>> installers is a good thing.  From an API perspective, I'd prefer clear
>> naming for float or double build so that linking doesn't depend on if
>> a user happens to have installed one or the other that happens to have
>> the same name.
>>
>> I think it'd be nice if we make "csound" be the double build and the
>> default and "csound32" be used for legacy purposes and those who
>> specifically want the little speed boost.  Reasoning for this is that
>> new users by default would get the higher-quality build. I think it's
>> better to start with higher-quality and really push it until it
>> becomes a performance issue then move over to floats, as I think with
>> computers these days most people won't hit processing limits anyways.
>>
>> I think Andy's comments though are completely valid, and library
>> naming is an issue.  If the names change, what are the impacts?  If
>> the default is to doubles and 32 is added, I would imagine most API
>> users would not be too affected for those that go through a secondary
>> interface like Python and Java.  For those directly linking to the
>> library, I imagine it may cause an issue.
>>
>> I know it would be sort of a pain for API users as I think we'd all
>> have to upgrade in some way (plus bump the API version) and issue new
>> builds, but I think if this is clearly worked out then it would set
>> things up for the future.
>>
>> Thoughts?
>> steven
>>
>>
>> On Sat, Mar 13, 2010 at 11:09 AM, Michael Gogins
>>  wrote:
>>> The module names are difficult not only because of the operating
>>> system but also because they must be as generated and used by SWIG for
>>> the Python, Java, and Lua wrappers. Please do not change them or these
>>> wrappers will simply break.
>>>
>>> I whole-heartedly agree with Felipe about distributing only one
>>> version of Csound. Because the double version does sound more precise
>>> in double-blind listening tests with at least this listener, that
>>> should be the supported version. Threading will make up for any
>>> performance deficit (which is modest, anyway) -- distributing the
>>> threaded code should be a priority.
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>>
>>> On Fri, Mar 12, 2010 at 11:57 PM, Felipe Sateler  wrote:
>>>> On Sat, Mar 13, 2010 at 01:08, andy fillebrown
>>>>  wrote:
>>>>> On Fri, Mar 12, 2010 at 7:27 PM, Felipe Sateler  wrote:
>>>>>> On Fri, Mar 12, 2010 at 20:55, andy fillebrown
>>>>>>  wrote:
>>>>>>> I would like to re-express my frustration with Csound's library names
>>>>>>> on Windows.  I would like csound32.dll.5.2 and csound64.dll.5.2 to be
>>>>>>> renamed to the standard csound32-5.2.dll and csound64-5.2.dll (or
>>>>>>> something else ending in .dll, at least), and the different versions
>>>>>>> of csnd.dll renamed to csnd32.dll and csnd64.dll so that I don't have
>>>>>>> to keep messing with my PATH variable to be able to run both versions.
>>>>>>
>>>>>> I do not understand why do you need to change PATH and how changing
>>>>>> the difference from after .dll to before will help. Could you
>>>>>> elaborate please?
>>>>>
>>>>> The PATH issue is encountered when both the single and double
>>>>> precision versions of Csound are installed.  When both of their bin
>>>>> directories are added to the PATH variable it makes getting to the
>>>>> correct version of csnd.dll problematic.  If the floats version of
>>>>> Csound appears in PATH first, it is that version of csnd.dll that gets
>>>>> loaded regardless of whether or not it's the one you actually want.
>>>>> Say, for example, Csound32, Csound64, QuteCsound32, and QuteCsound64
>>>>> are installed in that order.  QuteCsound64 won't run because it will
>>>>> find the csnd.dll from the Csound32 install first, assume it's the
>>>>> correct csnd.dll, and choke on missing references when it tries to use
>>>>> it.  The problem goes away if the two versions of csnd.dll are given
>>>>> version-specific names.  As it is, in order for me to use QuteCsound64
>>>>> after installing Csound32, I have to edit the PATH variable so that
>>>>> the Csound64 installation is seen by it and not hidden by the Csound32
>>>>> bin directory that precedes it.  I can either remove the Csound32 bin
>>>>> directory from it, or reverse the order so that the Csound64 bin
>>>>> directory comes before the Csound32 bin -- which is do-able but it is
>>>>> an annoyance.  Regardless, it is impossible to run both QuteCsound32
>>>>> and QuteCsound64 out of the box without editing the PATH variable
>>>>> before starting one or the other.
>>>>
>>>> Ah, so the runtime problem is mainly the untagged csnd.dll, not csound.dll.
>>>>
>>>>>
>>>>> The .dll extension issue is also just an annoyance.  With the .5.2 at
>>>>> the end of the name, things like "g++ -lcsound32" fail when using
>>>>> mingw due to the non-standard .5.2 extension, so the full path and
>>>>> file name must be used instead.  It's ugly and it's not portable.  Why
>>>>> does the .5.2 come after the .dll, anyway?  Is there some reason that
>>>>> I'm unaware of?
>>>>
>>>> In Unix, versions come after the name (so it is also csound.so.5.2),
>>>> and it is the runtime version of the library. At link time, one must
>>>> have a csound.so link pointing to the appropriate version of the
>>>> library one wants to use. I figure that the windows naming pattern
>>>> followed the unix one. I do not know if the symlink thing can be
>>>> ported to windows, though.
>>>>
>>>>>
>>>>> Anyway, as I said, these are only annoyances.  They can be worked
>>>>> around fairly easily with batch files, but they shouldn't have to be
>>>>> worked around at all.  When things go wrong it's just "one more thing"
>>>>> to have to check on, and it's bad enough I have to deal with all this
>>>>> environment variable nonsense to begin with, never mind fiddling with
>>>>> them constantly just to get things to work consistently
>>>>>
>>>>> Death to environment variables, I say! =)
>>>>
>>>> I say death to more than one version of csound, instead. Having floats
>>>> and doubles versions is just annoying. If we could just get an
>>>> agreement on which version should be the one supported, then the world
>>>> would be a much better place :p.
>>>>
>>>>>
>>>>>>>  I realize there are issues with renaming them but I am finding it
>>>>>>> incredibly annoying dealing with them as they are and I would be
>>>>>>> remiss to not say or do anything about it after all the cursing I've
>>>>>>> done under my breath =)
>>>>>>>
>>>>>>> From what I gathered from the csnd.dll renaming issues raised the last
>>>>>>> time I brought this up, it is do-able, and I will be happy to do it
>>>>>>> myself if it's the only way it will get done.  Just point me in the
>>>>>>> right direction and I'll start gathering info and putting a plan
>>>>>>> together on how best to go about it.
>>>>>>
>>>>>> I think it is most certainly doable, but probable it should wait until
>>>>>> an API bump to make the most out of the inconvenience.
>>>>>
>>>>> Is there an API bump scheduled?
>>>>
>>>> Not that I know of.
>>>>
>>>>
>>>> --
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourc

Another thing I'd like to do is create a build package for making it
easy to build Csound, the idea being that all the tools needed to
build Csound could be found in one place.  Maybe even setup a
directory structure that made it such that Csound would build out of
the box after downloading the build package.

~ andy.f



On Sat, Mar 13, 2010 at 3:09 PM, andy fillebrown
 wrote:
> I don't think dropping the single precision version of csound from the
> packages is a good idea.  For many users the speed difference is
> significant.  Perhaps a Csound-6 that includes csound32-6 and
> csound64-6 in the same bin directory is in order?  Maybe they could be
> differentiated by "single" and "double" instead of "float" and
> "double", or maybe "1x" and "2x" instead of "32" and "64" -- to make
> it clearer to non-programmers that the precision of one is greater
> than the other, while at the same time avoiding confusion with 32 and
> 64 bit operating systems?
>
> ~ andy.f
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That would be nice. I'm also thinking it would take a lot of maintaining?

On 16 March 2010 06:58, andy fillebrown  wrote:
> Another thing I'd like to do is create a build package for making it
> easy to build Csound, the idea being that all the tools needed to
> build Csound could be found in one place.  Maybe even setup a
> directory structure that made it such that Csound would build out of
> the box after downloading the build package.
>
> ~ andy.f
>
>
>
> On Sat, Mar 13, 2010 at 3:09 PM, andy fillebrown
>  wrote:
>> I don't think dropping the single precision version of csound from the
>> packages is a good idea.  For many users the speed difference is
>> significant.  Perhaps a Csound-6 that includes csound32-6 and
>> csound64-6 in the same bin directory is in order?  Maybe they could be
>> differentiated by "single" and "double" instead of "float" and
>> "double", or maybe "1x" and "2x" instead of "32" and "64" -- to make
>> it clearer to non-programmers that the precision of one is greater
>> than the other, while at the same time avoiding confusion with 32 and
>> 64 bit operating systems?
>>
>> ~ andy.f
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Maintaining? hmm, maintenance even, it's still kind of early for me...

On 16 March 2010 09:41, Rory Walsh  wrote:
> That would be nice. I'm also thinking it would take a lot of maintaining?
>
> On 16 March 2010 06:58, andy fillebrown  wrote:
>> Another thing I'd like to do is create a build package for making it
>> easy to build Csound, the idea being that all the tools needed to
>> build Csound could be found in one place.  Maybe even setup a
>> directory structure that made it such that Csound would build out of
>> the box after downloading the build package.
>>
>> ~ andy.f
>>
>>
>>
>> On Sat, Mar 13, 2010 at 3:09 PM, andy fillebrown
>>  wrote:
>>> I don't think dropping the single precision version of csound from the
>>> packages is a good idea.  For many users the speed difference is
>>> significant.  Perhaps a Csound-6 that includes csound32-6 and
>>> csound64-6 in the same bin directory is in order?  Maybe they could be
>>> differentiated by "single" and "double" instead of "float" and
>>> "double", or maybe "1x" and "2x" instead of "32" and "64" -- to make
>>> it clearer to non-programmers that the precision of one is greater
>>> than the other, while at the same time avoiding confusion with 32 and
>>> 64 bit operating systems?
>>>
>>> ~ andy.f
>>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Tue, Mar 16, 2010 at 5:41 AM, Rory Walsh  wrote:
> That would be nice. I'm also thinking it would take a lot of maintaining?

Yeah, you're probably right.  I'll just keep working on the stuff I'm
already working on and hope for the best, I guess.

Cheers,
~ andy.f

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net