Building both floats and doubles

[Felipe Sateler]

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

[Victor Lazzarini]

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-2]

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

[Felipe Sateler]

Actually I do have such a script, and my tests were run by it. It is a bash
shell script, though, and is still quite ad-hoc. I have attached it, but I
think it still requires more work to make it a general benchmarking tool.

I did not use python because the program doesn't really do any work, but just
schedules other programs to do theirs, and this is a task sh is very good at.
If someone is interested enough they could rewrite it as python, but the heavy
use of external programs will probably not make it worthwhile.

Code for parsing the GNU R data is missing, though. Plotting should be pretty
easy to add by invoking gnuplot. In fact, I just added it.

The script needs bash, sed, awk, bc, gnuplot and gnu r. It takes as parameters
the build options to try, then cleans, builds and runs csound a number of
times, and finally creates the files useful for GNU R and gnuplot and invokes
them. Everything is stored in files called bench.*
Note that the script is very ad-hoc, and can definitely be improved, but at
least works.


El martes 26 de mayo, Michael Gogins escribió:

> 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

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

[joachim heintz]

I do not agree that the performance criterium is more important than  
the audio precision, in the case which is discussed. I think one of  
the advantages of Csound is its goal to have the best quality  
possible. If there are some situations where "the improvement is  
audible" though they are "few and subtle", as you say, I'd prefer to  
have these improvements, even if the performance is 10% slower.  
Perhaps this will not be relevant then with the next generation of  
processors, but the precision will.
I've heard that SuperCollider uses doubles - is that true?

        joachim


Am 26.05.2009 um 14:03 schrieb Michael Gogins:

> 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
>

------------------------------------------------------------------------------
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 as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Michael Gogins-2]

I do not know about SuperCollider, but I will check and let you know.
I do think this is an important issue.

Personally, I agree with you about precision, but there are a number
of Csound users who are quite clear that they find Csound's float
precision adequate, and prefer the extra performance.

I urge you, do the ABX comparisons yourself and see how important the
precision differences are to you. For me, they are not big enough to
outweigh the preferences of a number of other Csound users.

On some platforms, anyway, it is clear that doubles will in fact be
faster than floats. On those platforms, which I suspect includes all
64 bit operating systems and thus all future computing, you get to
have both precision and efficiency.

Regards,
Mike

On 5/26/09, joachim heintz <jh@...> wrote:

> I do not agree that the performance criterium is more important than
> the audio precision, in the case which is discussed. I think one of
> the advantages of Csound is its goal to have the best quality
> possible. If there are some situations where "the improvement is
> audible" though they are "few and subtle", as you say, I'd prefer to
> have these improvements, even if the performance is 10% slower.
> Perhaps this will not be relevant then with the next generation of
> processors, but the precision will.
> I've heard that SuperCollider uses doubles - is that true?
>
> joachim
>
>
> Am 26.05.2009 um 14:03 schrieb Michael Gogins:
>
>> 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
>>
>
>
> ------------------------------------------------------------------------------
> 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 as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/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 as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Michael Gogins-2]

I found that in SuperCollider SVN, unit generator samples are always
declared as "float."

I do not know about the SuperCollider language, but it is the unit
generator architecture that is important for this discussion.

Regards,
Mike

On 5/26/09, joachim heintz <jh@...> wrote:

> I do not agree that the performance criterium is more important than
> the audio precision, in the case which is discussed. I think one of
> the advantages of Csound is its goal to have the best quality
> possible. If there are some situations where "the improvement is
> audible" though they are "few and subtle", as you say, I'd prefer to
> have these improvements, even if the performance is 10% slower.
> Perhaps this will not be relevant then with the next generation of
> processors, but the precision will.
> I've heard that SuperCollider uses doubles - is that true?
>
> joachim
>
>
> Am 26.05.2009 um 14:03 schrieb Michael Gogins:
>
>> 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
>>
>
>
> ------------------------------------------------------------------------------
> 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 as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/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 as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[joachim heintz]

Thanks for your investigation. This is good to know.
        joachim


Am 27.05.2009 um 15:28 schrieb Michael Gogins:

> I found that in SuperCollider SVN, unit generator samples are always
> declared as "float."
>
> I do not know about the SuperCollider language, but it is the unit
> generator architecture that is important for this discussion.
>
> Regards,
> Mike
>
> On 5/26/09, joachim heintz <jh@...> wrote:
>> I do not agree that the performance criterium is more important than
>> the audio precision, in the case which is discussed. I think one of
>> the advantages of Csound is its goal to have the best quality
>> possible. If there are some situations where "the improvement is
>> audible" though they are "few and subtle", as you say, I'd prefer to
>> have these improvements, even if the performance is 10% slower.
>> Perhaps this will not be relevant then with the next generation of
>> processors, but the precision will.
>> I've heard that SuperCollider uses doubles - is that true?
>>
>> joachim
>>
>>
>> Am 26.05.2009 um 14:03 schrieb Michael Gogins:
>>
>>> 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
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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 as they present alongside digital heavyweights like  
>> Barbarian
>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/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 as they present alongside digital heavyweights like  
> Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/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 as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel