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