Ok, I just tested the Mac OS X 64-bit build of Pd-double and it is indeed double precision. I say we start announcing it and spreading the word to get people testing it, and maybe fixing up their code and/ or contributing to fixing things.
Katya, do you want to post such an announcement to pd-announce? I think we should also try to get it posted on the Create Digital Music blog. It would nice to have example patches of what double precision enables. I'll do one that uses 32-bit int timestamps.
.hc
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-dev List pd-dev@iem.at Cc: Sent: Sunday, October 9, 2011 3:43 PM Subject: [PD-dev] pd-double builds are actually double now
Ok, I just tested the Mac OS X 64-bit build of Pd-double and it is indeed double precision. I say we start announcing it and spreading the word to get people testing it, and maybe fixing up their code and/or contributing to fixing things.
Katya, do you want to post such an announcement to pd-announce? I think we should also try to get it posted on the Create Digital Music blog. It would nice to have example patches of what double precision enables. I'll do one that uses 32-bit int timestamps.
That sounds great. I'd be interested in clear example patches for my own edification.
-Jonathan
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Sun, Oct 9, 2011 at 9:43 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Ok, I just tested the Mac OS X 64-bit build of Pd-double and it is indeed double precision. I say we start announcing it and spreading the word to get people testing it, and maybe fixing up their code and/or contributing to fixing things.
Katya, do you want to post such an announcement to pd-announce? I think we should also try to get it posted on the Create Digital Music blog. It would nice to have example patches of what double precision enables. I'll do one that uses 32-bit int timestamps.
Yeah it's now the right time to announce things and at the same time be clear about what to expect and what to not (yet) expect from pd double extended. Tomorrow I'll have time to do some detailed announcements. Could we collect tests patches somewhere? I have a lot of testpatches already in the original set on:
http://www.katjaas.nl/doubleprecision/doubleprecision.html (page bottom)
Most of these are functional tests and performance tests, but there's also a directory 'precision-tests' with examples, some of which are also shown on mentioned page.
Katja
On Oct 9, 2011, at 5:14 PM, katja wrote:
On Sun, Oct 9, 2011 at 9:43 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Ok, I just tested the Mac OS X 64-bit build of Pd-double and it is indeed double precision. I say we start announcing it and spreading the word to get people testing it, and maybe fixing up their code and/or contributing to fixing things.
Katya, do you want to post such an announcement to pd-announce? I think we should also try to get it posted on the Create Digital Music blog. It would nice to have example patches of what double precision enables. I'll do one that uses 32-bit int timestamps.
Yeah it's now the right time to announce things and at the same time be clear about what to expect and what to not (yet) expect from pd double extended. Tomorrow I'll have time to do some detailed announcements. Could we collect tests patches somewhere? I have a lot of testpatches already in the original set on:
http://www.katjaas.nl/doubleprecision/doubleprecision.html (page bottom)
Most of these are functional tests and performance tests, but there's also a directory 'precision-tests' with examples, some of which are also shown on mentioned page.
I was thinking it would be nice to have examples of what double precision enables with audio. I guess its pretty subtle for the most part, but your examples are good on your site. I like the idea of Pd- double now becomes useful for general purpose math. And the IR measurement example is a good one too. Perhaps this doesn't really exist, but I was thinking it would be great to have a patch where you could hear the difference between single and double precision.
.hc
----------------------------------------------------------------------------
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
On Mon, Oct 10, 2011 at 6:56 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I was thinking it would be nice to have examples of what double precision enables with audio. I guess its pretty subtle for the most part, but your examples are good on your site. I like the idea of Pd-double now becomes useful for general purpose math. And the IR measurement example is a good one too. Perhaps this doesn't really exist, but I was thinking it would be great to have a patch where you could hear the difference between single and double precision.
As the examples on the site suggest, you have to go to extremes before single precision becomes insufficient. The attached patch long-audio-buffer.pd illustrates what happens if a ~ 15 minutes soundfile is played at fractional speed in Pd. Double precision can handle that, single precision can't. At this length, the difference is not subtle. Let me know if this example works for you as a demo.
Katja
Starting on October 20, nightly builds tagged as pd-double are really built in double precision. All earlier builds were single precision or a mix of single and double.
In double precision, only Linux builds succeed, partly. From the logs, you can see gcc exiting with an error when compiling creb. The package contains everything which was built before creb: the Pd core and a few external libs. On OSX, no package is produced at all. It will take considerable time before all libs will even compile in double precision, since all fixes have to be properly tested before commit.
In the meantime, double precision Pd builds were prematurely announced on puredata.info on Otober 4. We have two weeks of wrecked pd-double builds on the autobuild pages, but the pd-double announcement is already leading it's own viral life, see for example an aside in this thread (Pd forum):
http://puredata.hurleur.com/sujet-6287-filter-object-bug-iemlib
I am now looking for a way to better manage info and support on this topic. The double-readiness of pd core code is a modest achievement, a seed from which double-precision-enabled Pd / Pd-extended will hopefully grow. This perspective may be easily be overshadowed by reports of disappointment when pd users can not find executables, or even worse, test the wrecked builds. An early conclusion will be that double-precision Pd is a pathetic failure, and this may in turn discourage further development.
Would it be possible to have double-precision vanilla Pd builds produced for all OS'ses, and make them available via puredata.info? I can include test- and demo-patches, and we could set up a place to collect such patches from users. This would be a positive way to get a taste of double-precision Pd. The nightly pd-double builds instead, are at the moment only useful for hardcore testers, devs and maintainers, they can not help in promoting the topic among pd users.
Katja
On Oct 21, 2011, at 7:43 AM, katja wrote:
Starting on October 20, nightly builds tagged as pd-double are really built in double precision. All earlier builds were single precision or a mix of single and double.
In double precision, only Linux builds succeed, partly. From the logs, you can see gcc exiting with an error when compiling creb. The package contains everything which was built before creb: the Pd core and a few external libs. On OSX, no package is produced at all. It will take considerable time before all libs will even compile in double precision, since all fixes have to be properly tested before commit.
As long as you are willing to follow up on issues as they are found, I think it works best to commit much more frequently. That allows others to see, test, and fix your code. The one thing that a commit must do is build. Always make sure it builds before committing (I know I know, sometimes I forget too ;). You don't need to guarantee that you've fixed every bug before committing. Committing more frequently means that we can share the development more.
I think I a good workflow for Pd-double would be to commit things that fix the build, you think will work, and have tested somewhat. Make a note of those, and as we get a testing framework in place, we can start putting automatic tests in place. We can always revert changes in SVN, if need be.
In the meantime, double precision Pd builds were prematurely announced on puredata.info on Otober 4. We have two weeks of wrecked pd-double builds on the autobuild pages, but the pd-double announcement is already leading it's own viral life, see for example an aside in this thread (Pd forum):
http://puredata.hurleur.com/sujet-6287-filter-object-bug-iemlib
I am now looking for a way to better manage info and support on this topic. The double-readiness of pd core code is a modest achievement, a seed from which double-precision-enabled Pd / Pd-extended will hopefully grow. This perspective may be easily be overshadowed by reports of disappointment when pd users can not find executables, or even worse, test the wrecked builds. An early conclusion will be that double-precision Pd is a pathetic failure, and this may in turn discourage further development.
I think the key is getting as much info out as possible, and letting people know what they are getting involved in. I agree, we should not call the pd-double builds anything like a release, far from it. They are development builds, just like the nightly builds of Pd-extended. As long as that is clear, then it is good to publish as much as possible to anyone who wants to get easily get involved in testing and development. Also known as "release early, release often".
Would it be possible to have double-precision vanilla Pd builds produced for all OS'ses, and make them available via puredata.info? I can include test- and demo-patches, and we could set up a place to collect such patches from users. This would be a positive way to get a taste of double-precision Pd. The nightly pd-double builds instead, are at the moment only useful for hardcore testers, devs and maintainers, they can not help in promoting the topic among pd users.
Its definitely possible. For GNU/Linux, just release a tarball of the git, or just tell people to 'git clone'. For Mac OS X, you can do:
cd packages/darwin_app make install
And you'll have a build/Pd-double.app that is only the core, no libs. Then zip that up and post it. For Windows it would be possible to add a target in packages/win32_inno/Makefile to make a core-only .zip.
.hc
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
-
Hans-Christoph Steiner -
Jonathan Wilkes -
katja