Re: Building both floats and doubles

> I propose that we simply move to support only one sample size. I would
> prefer double, but I can live with float.
>
> The motive for double was a hypothesis that audio precision would
> improve. It did improve, but the cases where the improvement is
> audible are few and subtle. Therefore, I believe we should standardize
> on the audio sample size whose performance is optimum.
>
> This fastest sample size seems to be different on different
> architectures, but I don't see why that is a problem. In a sense, it's
> even an advantage, as it would ensure that we continue to maintain the
> build for both sample sizes.
>
> I propose that we conduct tests of representative performance use
> cases on OS X, Windows, and Linux, and standardize packages for the
> best performing sample size on each platform. I also propose that we
> repeat my double blind tests of audio rendering precision with more
> formal use cases and on different platforms.
>
> Your use of 'R' shows that we could write Python scripts that can
> automate the builds and the performance testing, and analyze the
> results. We could do the same with ABX comparison if we write a little
> Python GUI for the ABX tests.
>
> Regards,
> Mike
>
> On 5/26/09, victor <Victor.Lazzarini@...> wrote:
>> My opinion on this matter is that we should perhaps start moving
>> towards support doubles only and have clear roadmap for that.
>> Eventually floats could still be built from sources, but not  
>> supported
>> in binary distributions.
>>
>> Victor
>> ----- Original Message -----
>> From: "Felipe Sateler" <fsateler@...>
>> To: "Developer discussions" <csound-devel@...>
>> Sent: Tuesday, May 26, 2009 2:52 AM
>> Subject: [Cs-dev] Building both floats and doubles
>>
>>
>>> I've been thinking about changing the csound Debian packaging to
>>> support both 32 and 64 bit builds. There is, however, one major
>>> problem. While the csound library itself has a different name for  
>>> each
>>> version, allowing both to be installed at the same time, none of the
>>> other libraries do. Plugins could be easily configured to install on
>>> separate paths and define appropriate OPCODEDIR/OPCODE64DIR.  
>>> However,
>>> the interface libraries do not encode the floating point size in  
>>> their
>>> names, thus making it impossible to install both at the same time.
>>> libcsnd.so would need to be renamed, and lua/python/java bindings
>>> would have to conflict with each other (because there is no  
>>> meaningful
>>> way in which this can be done without renaming the module, and I  
>>> think
>>> it doesn't make much sense to have both). Alternatively, I could  
>>> allow
>>> the csound library to be both sizes, but only allow a single version
>>> of libcsnd.so (and thus, all the bindings).
>>> The second option is clearly suboptimal, but it is simpler, and is
>>> better than the current situation (although, inside debian, nobody
>>> uses libcsound yet, and the only prospective package I know of is
>>> qutecsound, which wouldn't benefit since it uses libcsnd.so).  
>>> However,
>>> just supporting different versions of the same executable at the  
>>> same
>>> time is a significant pain, and I won't do it unless somebody  
>>> shows me
>>> it has some clear advantages.
>>> The first option is technically superior, but it would mean breaking
>>> existing users of libcsnd.so (how many of these are out there?
>>> qutecsound and CsoundAC are the only ones that I am aware of). Users
>>> of python/lua/java interfaces will not have a problem because those
>>> wrappers would be changed at the same time as csound. I think the
>>> safest way to do this (if there is need to) is to just change the  
>>> name
>>> and (unfortunately) requiring applications to change if they want to
>>> use the 64bit version.
>>>
>>> Do you people think it is worth it? I only use doubles version, but
>>> apparently some people have uses for floats due to its perceived
>>> performance benefit (which may not always exist, as we've seen). And
>>> by worth it, I mean breaking every user of the csnd C++ wrapper.
>>> Developers, do you think this increase in complexity is worthwile? I
>>> ask because I remember some talk about just dropping floats a while
>>> ago.
>>>
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>>> is a gathering of tech-side developers & brand creativity  
>>> professionals.
>>> Meet
>>> the minds behind Google Creative Lab, Visual Complexity,  
>>> Processing, &
>>> iPhoneDevCamp asthey present alongside digital heavyweights like  
>>> Barbarian
>>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity  
>> professionals.
>> Meet
>> the minds behind Google Creative Lab, Visual Complexity,  
>> Processing, &
>> iPhoneDevCamp asthey present alongside digital heavyweights like  
>> Barbarian
>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity  
> professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like  
> Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>