Pd-dev December 2012

pd-dev@lists.iem.at

14 participants
173 discussions

[ pure-data-Patches-3438338 ] change float to t_float in Pd 'extra'
by SourceForge.net 15 Dec '12

15 Dec '12

Patches item #3438338, was opened at 2011-11-15 07:17 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3438338&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Pending >Resolution: Accepted Priority: 7 Private: No Submitted By: Katja (katjav) Assigned to: Miller Puckette (millerpuckette) Summary: change float to t_float in Pd 'extra' Initial Comment: 0001-change-float-to-t_float-in-Pd-extra.patch converts instances of 'float' to 't_float' in all classes of vanilla Pd's 'extra'. Also, a few constants and literals are defined with more decimals, and some float suffixes removed. The patch is intended for Pd-043.1test5. Type 't_float' is already used in most of pd core code. The changes in the 'extra' classes would make them compliant with the core in this sense. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-12-15 13:56 Message: applied for 0.44 ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2011-11-16 02:28 Message: I've checked the case of bonk~ once more because the difference was remarkable there (that is, in terms of a test situation). It is fully due to a more precise definition of pi, 3.141592653589793 instead of 3.14159. Since a literal without float suffix is a double anyway, 3.14159 for pi is a waste of precision even when t_float is float. And even when this waste is considered unimportant, a more precise definition can not spoil the intended calculation result. So to answer IOhannes' question: the differences can be considered an improvement (albeit probably an unimportant one) of the situation. In practice, no one will be dependent on an exact output of bonk~, it is even quite hard to create a reproducible test situation. The same holds for fiddle~ and sigmund~. In this sense, the patch can be safely applied as is. By the way, the test patches can be opened to see results in detail, they're not dependent on a script to run them. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-16 00:41 Message: i guess the question is: are the differences an _improvment_ of the situation (e.g. because [bonk~] historically produced slightly "off" values and the patch now fixes that)? in this case i think one could argue, that your patch is fixing a minor bug, and should be applied, even if it breaks 100% compatibility (and then: if somebody relies on an exact value output in float-domain, they should re-think their patch anyhow) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-11-15 21:14 Message: That answers my somewhat stupid question: your unittest patch will show the differences. ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2011-11-15 11:50 Message: The more precise constants and removal of float suffixes originate from my attempts to make Pd work in single and double precision. Maybe I should make a patch file without these changes for the moment, till I've reviewed them better. Hans I do not understand your question 'how can we see what those differences are?' If you build a patched Pd-0.43.1test5 and run the tests which are also attached below, you'll see that the differences are in the analysis objects, notably bonk~. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-11-15 09:20 Message: These changes would complete the t_float/t_sample clean up that happened with the core back in 0.42 (I think). I think it should be included in 0.43 if possible. Katya, how can we see what those differences are? ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2011-11-15 07:36 Message: correction: the reference for the unit test patches was pd-0.43.0 vanilla release ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2011-11-15 07:33 Message: Accompanying the patch file, I've produced unit test patches. The reference was pd-043.1 vanilla release. The tests indicate slightly altered output for some of the classes, probably due to more precise constants and removal of float suffixes. See attached 'unittests-pdextras.zip'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3438338&group_…

1 0

[ pure-data-Patches-3432654 ] pkg-config improvement
by SourceForge.net 15 Dec '12

15 Dec '12

Patches item #3432654, was opened at 2011-11-03 02:53 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3432654&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata-dev Group: bugfix >Status: Pending >Resolution: Out of Date Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: pkg-config improvement Initial Comment: with the new autotools-based build system, Pd also generates a pkg-config [1] file (it's pd.pc, generated from pd.pc.in). the purpose of this file is to sease compilation of externals in a standardized way, by providing information on where to find header files (e.g. /usr/include/pd) and which libraries we need to link too (e.g. link against pd.lib" on w32, but not on other platforms) unfortunately i was a bit too eager, when i first created this file, adding lots of flags and bells and whistles, which have turned out to be more confusing than helping. attached patch therefore simplifies the generated pd.pc to only hold the relevant information (see in-patch description for more details) [1] ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-12-15 13:30 Message: Not sure what to do with this - it looks like it might still be useful but it doesn't apply cleanly and I don't know y way around configure.ac to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3432654&group_…

1 0

[ pure-data-Patches-3426630 ] Increasing maximum size of alsa midi input
by SourceForge.net 15 Dec '12

15 Dec '12

Patches item #3426630, was opened at 2011-10-20 19:30 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3426630&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: feature >Status: Pending >Resolution: Accepted Priority: 5 Private: No Submitted By: Alex Norman (alexnorman) Assigned to: Miller Puckette (millerpuckette) Summary: Increasing maximum size of alsa midi input Initial Comment: I've made the input size configurable and the default size larger so that we can accept much larger messages, very useful for sysex input. Essentially taken from desire data I think, quite a while ago. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-12-15 13:26 Message: No idea why 512... but sounds better than 20:) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-10-21 10:12 Message: looks good to me, included in Pd-extended 0.43 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3426630&group_…

1 0

[ pure-data-Patches-3529183 ] toggling editmode when canvas is not vised causes Tcl dumps
by SourceForge.net 15 Dec '12

15 Dec '12

Patches item #3529183, was opened at 2012-05-23 12:09 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3529183&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix >Status: Pending >Resolution: Accepted Priority: 5 Private: No Submitted By: Patrice Colet (patrco) Assigned to: Miller Puckette (millerpuckette) Summary: toggling editmode when canvas is not vised causes Tcl dumps Initial Comment: Many bugs are appearing in tcl, one is easy to reproduce, it's attached the console says in red "invalid command name: .xff8f58 while executing " .xff8f58 configure -cursor $cursor_run_mode_nothing" when clicking on toggle ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-12-15 13:23 Message: applied for 0.44 ---------------------------------------------------------------------- Comment By: Patrice Colet (patrco) Date: 2012-05-23 12:16 Message: Could you try a nightly build and report back whether the problem still exists? http://autobuild.puredata.info/auto-build/latest/ ---------------------------------------------------------------------- Comment By: Patrice Colet (patrco) Date: 2012-05-23 12:16 Message: Could you try a nightly build and report back whether the problem still exists? http://autobuild.puredata.info/auto-build/latest/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3529183&group_…

1 0

[ pure-data-Patches-3424988 ] add proper quoting of filenames to GUI prefs
by SourceForge.net 15 Dec '12

15 Dec '12

Patches item #3424988, was opened at 2011-10-17 13:35 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3424988&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 7 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: add proper quoting of filenames to GUI prefs Initial Comment: On Mac OS X, then GUI prefs system was not handling quoting of filenames at all. The first patch adds proper quoting, then the second patch brings pd_guiprefs.tcl inline with the coding style of the rest of the Pd GUI code (using namespaces, the 'else' keyword, etc). ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-12-15 13:20 Message: The first two appear to have been appplied already, but not the last one (and it doens't apply cleanly) - should I just aply 0003 by hand? Not sure it's still relevant but if so I'll put it in. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-12-14 17:22 Message: one more bugfix patch to include support for unicode chars and better quoting ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-11-04 21:45 Message: updated with a quoting bug fix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3424988&group_…

1 0

[ pure-data-Patches-3421335 ] Bug in bonk~ for Max/MSP
by SourceForge.net 15 Dec '12

15 Dec '12

Patches item #3421335, was opened at 2011-10-10 18:06 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421335&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix >Status: Pending >Resolution: Accepted Priority: 5 Private: No Submitted By: Anthony Lauzon (pfaffian) Assigned to: Miller Puckette (millerpuckette) Summary: Bug in bonk~ for Max/MSP Initial Comment: The file handle allocator was not allocating the right amount of memory for the input file. This patch fixes that. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-12-15 13:10 Message: appied... now I have to figure out how I really intend to be testing and distributing Max objects :) ---------------------------------------------------------------------- Comment By: Anthony Lauzon (pfaffian) Date: 2012-03-14 11:39 Message: bump ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421335&group_…

1 0

[ pure-data-Patches-3420484 ] Invalid memory access in s_utf8.c
by SourceForge.net 15 Dec '12

15 Dec '12

Patches item #3420484, was opened at 2011-10-07 20:10 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3420484&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Marvin Humphrey (creamygoodness) Assigned to: Miller Puckette (millerpuckette) Summary: Invalid memory access in s_utf8.c Initial Comment: After hearing on IRC that segfaults could be produced while editing text in an Object box under gdb, I tried running the Vanilla main git branch under Valgrind: valgrind ./src/pd Valgrind reported many "invalid read" memory errors, which on inspection, all arose from the same root cause: these strings are not NULL-terminated, but the UTF-8 handling code in s_utf8.c assumes NULL-termination and malfunctions in its absence. The attached patch suffices to eliminate the read errors. However, it does not address all the problems in s_utf8.c; other functions will require similar treatment. I have attempted make the new code as compatible with the old code as possible, for instance preserving its dubious algorithm for handling missing or excess continuation bytes. Hopefully I got everything right, though it is hard to be certain with bit-twiddling code like this in the absence of thorough unit tests. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-12-15 13:05 Message: this appears already to have been applied from somewhere else. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-10-09 18:39 Message: I accepted this into Pd-extended. ---------------------------------------------------------------------- Comment By: Marvin Humphrey (creamygoodness) Date: 2011-10-09 13:04 Message: I have uploaded a new version of the patch for s_utf8.c, and also a new version of the benchmarking app. Highlights: 1. The benchmarking app now handles four different functions. 2. All changed functions have been sped up since the last patch, especially u8_charnum(). u8_offset: 16% faster u8_charnum: 22% faster u8_inc: 10% faster ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-10-09 09:54 Message: This sounds great, I'll include it in Pd-extended and we'll see how it does there. The only problem is that there are two patches included in this tracker and they seem to have the same name. Could you delete the older one, so there is only one patch? ---------------------------------------------------------------------- Comment By: Marvin Humphrey (creamygoodness) Date: 2011-10-08 17:08 Message: In response to speed concerns raised in an IRC conversation ("well, its a realtime engine that communicates thru the utf8 stuff, so its good to have it efficient"), I have prepared a benchmark program to test the performance of u8_offset(). It reads a file into RAM, then traverses it with u8_offset() a user-specified number of iterations. Here are some results using the French wikipedia page on Pure Data as source material. Without patch: marvin@smokey:~/projects/pure-data $ cc -Wall -Wextra -std=gnu99 -O3 bench.c src/s_utf8.c -o bench marvin@smokey:~/projects/pure-data $ time ./bench pd.html 10000 pd.html (44683 bytes) 10000 iterations real 0m0.732s user 0m0.716s sys 0m0.003s Running the test 10 times produced a range of 0.724s to 0.733s, so the benchmark was pretty stable even on a Mac. :) With patch: marvin@smokey:~/projects/pure-data $ cc -Wall -Wextra -std=gnu99 -O3 bench.c src/s_utf8.c -o bench marvin@smokey:~/projects/pure-data $ time ./bench pd.html 10000 pd.html (44683 bytes) 10000 iterations real 0m0.618s user 0m0.612s sys 0m0.004s So, in addition to eliminating the Valgrind warnings, the patched version is actually faster. I speculate that this is because the current version of u8_offset() needlessly traverses at least one extra byte when the header byte of the sequence is plain ASCII. For what it's worth, if we remove the NUL-termination check from the loop condition... - while (charnum > 0 && str[offs]) { + while (charnum > 0) { We get even better: marvin@smokey:~/projects/pure-data $ time ./bench pd.html 10000 pd.html (44683 bytes) 10000 iterations real 0m0.514s user 0m0.507s sys 0m0.004s However, that could yield bogus results in the event that strlen(string) differs from the buffer length held in a separate integer. I would go that route in code which had been engineered to not need NUL-termination from the start, but wouldn't advocate for it here. As a further test, I tried an implementation based on u8_seqlen() which has the advantage of being easier to understand, and is the algorithm currently used by the Perl core among others: while (charnum-- > 0 && str[offs]) { offs += u8_seqlen(str + offs); } It performed substantially worse: marvin@smokey:~/projects/pure-data $ time ./bench pd.html 10000 pd.html (44683 bytes) 10000 iterations real 0m1.906s user 0m1.891s sys 0m0.003s In this case, I speculate that the lookup into the trailingBytesForUTF8 array is costly, even though it doubtless gets into the hottest CPU cache and stays there. The benchmarks were run on a 2007 Macbook Pro with a 2.4 GHz Core Duo chipset running OS X 10.6 (Snow Leopard). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3420484&group_…

1 0

[ pure-data-Patches-3421072 ] Streamline s_utf8.c
by SourceForge.net 15 Dec '12

15 Dec '12

Patches item #3421072, was opened at 2011-10-10 00:03 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421072&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Pending >Resolution: Accepted Priority: 5 Private: No Submitted By: Marvin Humphrey (creamygoodness) Assigned to: Miller Puckette (millerpuckette) Summary: Streamline s_utf8.c Initial Comment: There are a number of UTF-8 manipulation routines which were included when the library was added with the justification that they might be used someday. However, time has passed, they are still unused, and some of them have bugs -- so it is time to delete them with a justification of YAGNI (You Ain't Gonna Need It). ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-12-15 13:04 Message: applied for 0.44 ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-10-10 13:31 Message: Ok, I say this is ready for Miller to accept, so I'm assigning it to him. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-10-10 13:25 Message: Bryan Jurish: > I didn't see any fix for the NUL-termination problems I saw suggested > on the #dataflow transcript though (and I never noticed any such > segfaults myself): has that problem been confirmed? The NUL-termination problems for u8_inc(), u8_charnum() and u8_offset() were fixed under a different issue: http://sourceforge.net/tracker/?func=detail&atid=478072&aid=3420484&group_i… Those functions were all capable of overrunning the end of a non-NUL-terminated string; u8_offset() could potentially return an incorrect answer depending on what it found there. I never duplicated the segfault myself using the steps that Matthieu described in #dataflow; however, it was very easy to detect the invalid reads by running Pd under Valgrind. If I tried hard I might be able to trigger a segfault consistently by carefully crafting bytes to trick u8_offset() into giving too big a number, resulting in a cursor location beyond the end of a string rather than at the end of a string. In any case, the patch both eliminated the invalid reads *and* sped things up, so I think it was justified even without a consistently segfaulting test case. I suspect that u8_inc_ptr() has problems similar to u8_inc() -- but since it does not seem to be used anywhere at present, I haven't put any time into diagnosing or fixing it. Instead, this patch removes it altogether. We can resurrect it from version control if a need arises in the future and vet it at that time. The patches attached to this issue should be low-risk, as all they do is remove functionality rather than change behaviors. The removed symbols are unused by Vanilla, and seem also to be unused by Pd-extended. The risk is that I missed some usage somewhere, resulting in link-time failure. ---------------------------------------------------------------------- Comment By: Bryan Jurish (mukau) Date: 2011-10-10 12:16 Message: Looks good to me. I can't test anything right now, but Martin's suggestions seem safe and clear. Give it a whirl... I didn't see any fix for the NUL-termination problems I saw suggested on the #dataflow transcript though (and I never noticed any such segfaults myself): has that problem been confirmed? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-10-10 09:37 Message: Makes sense to me. I'm assigning it to Bryan Jurish, the original author of the UTF-8 support, to see if he agrees. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421072&group_…

1 0

[ pure-data-Patches-3415092 ] add setup() function as final option when loading externals
by SourceForge.net 15 Dec '12

15 Dec '12

Patches item #3415092, was opened at 2011-09-28 11:18 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3415092&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Pending >Resolution: Accepted Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: add setup() function as final option when loading externals Initial Comment: With Pd-extended, I have added a pd/startup/ folder that allows Pd to auto-start things without prefs or flags. The idea is for loading things like the libdir or Lua loaders using ordered symlinks, like: startup/0.libdir.pd_linux startup/1.pdlua.pd_linux Having setup() would also provide an easy way to deal with hexloader characters in the object name. For people building a single object, they would only need to call it setup() and not have to calculate the hex codes for it. The patch adds two lines of code for _WIN32 and two for everything else. Its included in Pd-extended 0.43.1 ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-12-15 12:24 Message: appears already to have been applied ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3415092&group_…

1 0

[ pure-data-Patches-3413809 ] use Ctrl-< and Ctrl-> to cycle thru open windows
by SourceForge.net 15 Dec '12

15 Dec '12

Patches item #3413809, was opened at 2011-09-25 11:06 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3413809&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: use Ctrl-< and Ctrl-> to cycle thru open windows Initial Comment: This patch allows you to use Ctrl/Cmd < and > to cycle through all of the open windows in different directions. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-12-15 11:02 Message: I tried this and got funny behavior - ctrl < focussed the previous window OK, but also sent it to the back of the window stacking order.. Can this be what was intended??? ---------------------------------------------------------------------- Comment By: max (maxn) Date: 2011-09-26 05:01 Message: That's the standard on german keyboard layouts for cycling through the windows of the active application on OS X. I'd very much apprechiate if this would work in Pd. That said, i think it might actually be a bug in Tcl/Tk that it isn't working right now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3413809&group_…

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev December 2012