To pd dev
My default sort algorithm for merging pull requests is oldest to newest. I'm making a minor exception to this in taking on the Mac plist thing (I hate all things Mac and thus am gratefully taking on Mac-specific PRs with no testing) and then, for a wholly different reason, merging the netsend/ netreceive rewrite (as being something less expert about than the author) and thinking that getting up to date on network is an adaptation issue and not a design enhancement to Pd proper.
Let me know if one of your PRs is indeed just adaptation and not design and I'll consider jumping the queue on it like I did these. Otherwise I think I'll crawl through the 73 remaining PRs as best I can in chronological order.
Meanwhile I have changes I want to make - still agonizing over these.
cheers Miller
not sure I got what "adaptation" means here, but I've already mentioned this PR where I gave a huge cosmetic update to all of Pd's documentation. You mentioned in the Pd Weekend you should check it before other changes, so, well, here it is again: https://github.com/pure-data/pure-data/pull/608 :)
cheers
Em sex., 29 de nov. de 2019 às 23:08, Miller Puckette msp@ucsd.edu escreveu:
To pd dev
My default sort algorithm for merging pull requests is oldest to newest. I'm making a minor exception to this in taking on the Mac plist thing (I hate all things Mac and thus am gratefully taking on Mac-specific PRs with no testing) and then, for a wholly different reason, merging the netsend/ netreceive rewrite (as being something less expert about than the author) and thinking that getting up to date on network is an adaptation issue and not a design enhancement to Pd proper.
Let me know if one of your PRs is indeed just adaptation and not design and I'll consider jumping the queue on it like I did these. Otherwise I think I'll crawl through the 73 remaining PRs as best I can in chronological order.
Meanwhile I have changes I want to make - still agonizing over these.
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Em sáb., 30 de nov. de 2019 às 00:30, Alexandre Torres Porres < porres@gmail.com> escreveu:
not sure I got what "adaptation" means here, but I've already mentioned this PR where I gave a huge cosmetic update to all of Pd's documentation. You mentioned in the Pd Weekend you should check it before other changes, so, well, here it is again: https://github.com/pure-data/pure-data/pull/608 :)
Hi, sorry to insist, but IOhannes called to my attention that the PR started to conflict because it hadn't been merged. So I went ahead and fixed the conflicts and also worked again on the files that have been updated. I guess you're almost getting to this PR anyway, and maybe other PRs won't conflict to it, but getting to it first would be safer and wouldn't hurt :)
cheers
Am 30. November 2019 01:54:59 MEZ schrieb Miller Puckette msp@ucsd.edu:
Let me know if one of your PRs is indeed just adaptation and not design and I'll consider jumping the queue on it like I did these.
i have no idea about the current status of the release (being practically "afk"), but here's the PR's i care about:
- update/0.50 [722] is the usual, long-running bugfix PR. i'm amazed that this is still not merged. no "design" involved here.
- double-precision [807] another round of fixes to make Pd double precision ready. the PR mainly fixes real bugs when compiling Pd for 64bit-floats (like crashes, broken soundfiles,...). i deliberately left two "design" thingies (in-patch number representation and the high-performance phase-wrapping algorithm) for Pd 0.52 (although we should make sure to have everything ready by Pd-0.64)
- libpd [519] a couple of weeks ago this has already been merged, but was stalled by the wish to fix a couple of things on the libpd side first. i think it's now ready to go, but the formal "ok" from dan is still missing
mfg.hft.fsl IOhannes
Personally I would be happy to have the "trackable print" PR ( https://github.com/pure-data/pure-data/pull/464) merged in one of the next releases! It's a minor addition but could often be helpful.
My other PR ("gpointer for table objects" [667], "threaded soundfiler" [655] and "flag-less declare" [440]) are more research-oriented...
Cheers
Ant1
Em sex., 20 de dez. de 2019 às 11:39, Antoine Rousseau antoine@metalu.net escreveu:
Personally I would be happy to have the "trackable print" PR ( https://github.com/pure-data/pure-data/pull/464) merged in one of the next releases! It's a minor addition but could often be helpful.
My other PR ("gpointer for table objects" [667], "threaded soundfiler" [655] and "flag-less declare" [440]) are more research-oriented...
I have high expectations on "threaded soundfiler", I think it's really really useful
Cheers
Ant1 _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Hi,
On 19/12/2019 20:01, IOhannes m zmölnig wrote:
the high-performance phase-wrapping algorithm
For reference: https://github.com/pure-data/pure-data/blob/e3a78da5b7d825bf8b9f5d313e4ea55e... (current master at time of writing)
Using a [phasor~] with x -= floor(x); for wrapping is about twice as slow as the built-in tabfudge version, provided I compile with -march=native on my AMD Ryzen 7 2700X Eight-Core Processor. When compiled with pd-lib-builder's default -march=core2, the floor version is over five times slower. I can run tests on other hardware in early January if more data points are desired.
Benchmark methodology: time how long running 1000 copies of [phasor~ 440] takes in pd -batch, with a timeout.pd that quits pd after 1 minute of logical time. The tabfudge version finishes in 3 seconds. I used the /usr/bin/pd in 0.49.0-3 (Debian Buster).
I suppose it's not so hard to load a custom phasor~ library (source attached), if you need the extra accuracy of the floor version, and can live with the slowdown. I did this already in one project for a vcf~ with internal double precision feedback state.
Claude
Am 22. Dezember 2019 01:10:47 MEZ schrieb Claude Heiland-Allen claude@mathr.co.uk:
Hi,
On 19/12/2019 20:01, IOhannes m zmölnig wrote:
the high-performance phase-wrapping algorithm
For reference: https://github.com/pure-data/pure-data/blob/e3a78da5b7d825bf8b9f5d313e4ea55e...
(current master at time of writing)
Using a [phasor~] with x -= floor(x); for wrapping is about twice as slow as the built-in tabfudge version, provided I compile with -march=native on my AMD Ryzen 7 2700X Eight-Core Processor. When compiled with pd-lib-builder's default -march=core2, the floor version is over five times slower. I can run tests on other hardware in early January if more data points are desired.
Benchmark methodology: time how long running 1000 copies of [phasor~ 440]
thanks for the benchmarks.
as katja pointed out, due to branch-prediction the actual frequency of `[phasor~]` might have an impact as well.
I suppose it's not so hard to load a custom phasor~ library (source attached), if you need the extra accuracy of the floor version, and can
live with the slowdown.
i think this is a good (intermediate?) solution. as long as the core framework works with double-precision and no internal object produces actual garbage when compiled with double-precision (as is the case right now), Pd-dbl might be ready to fly...
mfg.hft.fsl IOhannes
-
Alexandre Torres Porres -
Antoine Rousseau -
Claude Heiland-Allen -
IOhannes m zmölnig -
Miller Puckette