Pd-dev October 2011

pd-dev@lists.iem.at

22 participants
138 discussions

[ pure-data-Patches-3421072 ] Streamline s_utf8.c
by SourceForge.net 10 Oct '11

10 Oct '11

Patches item #3421072, was opened at 2011-10-10 03:03 Message generated for change (Comment added) made by eighthave 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: Open Resolution: None Priority: 5 Private: No Submitted By: Marvin Humphrey (creamygoodness) >Assigned to: Bryan Jurish (mukau) 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: Hans-Christoph Steiner (eighthave) Date: 2011-10-10 12: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-3421072 ] Streamline s_utf8.c
by SourceForge.net 10 Oct '11

10 Oct '11

Patches item #3421072, was opened at 2011-10-10 00:03 Message generated for change (Tracker Item Submitted) made by creamygoodness 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: Open Resolution: None Priority: 5 Private: No Submitted By: Marvin Humphrey (creamygoodness) Assigned to: Nobody/Anonymous (nobody) 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). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3421072&group_…

1 0

[ pure-data-Patches-3420484 ] Invalid memory access in s_utf8.c
by SourceForge.net 10 Oct '11

10 Oct '11

Patches item #3420484, was opened at 2011-10-07 23:10 Message generated for change (Comment added) made by eighthave 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: Open Resolution: None 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: Hans-Christoph Steiner (eighthave) Date: 2011-10-09 21:39 Message: I accepted this into Pd-extended. ---------------------------------------------------------------------- Comment By: Marvin Humphrey (creamygoodness) Date: 2011-10-09 16: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 12: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 20: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

Patch tracker usage
by Marvin Humphrey 10 Oct '11

10 Oct '11

> >Comment By: Hans-Christoph Steiner (eighthave) > Date: 2011-10-09 12: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? I've done as you asked, though I don't see the reason it was necessary to do so. Files seem to be listed in reverse chronological order of upload, so it's always apparent what the most recent version of a file is from the page layout. If in doubt, you can snoop the URLs and look for the attachment ids, though I'd just grab the topmost link. (The JIRA install at Apache works the same way, and that's how we handle multiple uploads with the same name.) Is there something I've missed? Since the preferred method of patch submission is "git format-patch", the filename doesn't change unless either the first line of the commit changes or the submitter manually appends a version to it. I can do that, but it's an extra step. Marvin Humphrey

2 2

pd source - trying to understand m_mainloop() and sched_tick()
by Rich E 10 Oct '11

10 Oct '11

Hi all, I've been stepping through the pd source and trying to understand the scheduling system, would anyone who knows mind helping me to this effect? There are two options that m_mainloop() has for scheduling, m_pollingscheduler() and m_callbackscheduler(). On OS X, I am only getting a hit on m_pollingscheduler, since sched_useaudio = SCHED_AUDIO_POLL. Does sched_useaudio ever equal SCHED_AUDIO_CALLBACK, which would then cause m_callbackscheduler() to be used instead? I'm wondering if sched_tick() is ever called from a non-main thread. Cheers, Rich

2 2

[ pure-data-Patches-3420484 ] Invalid memory access in s_utf8.c
by SourceForge.net 09 Oct '11

09 Oct '11

Patches item #3420484, was opened at 2011-10-07 20:10 Message generated for change (Comment added) made by creamygoodness 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: Open Resolution: None Priority: 5 Private: No Submitted By: Marvin Humphrey (creamygoodness) Assigned to: Nobody/Anonymous (nobody) 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: 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

pd double autobuilds
by katja 09 Oct '11

09 Oct '11

On Sat, Oct 8, 2011 at 12:08 AM, Hans-Christoph Steiner <hans(a)at.or.at> wrote: > I think this is caused by using the 10.6 build on 10.5. It is only > partially compatible. Pd-0.43.1-extended-20111002.app, an x86_64 build, tries to load libs from Pd-extended.app which is an i386 build. That's where the message 'wrong architecture' comes from. In Pd-0.43.1-double-20111007.app, objects from iemlib and other libs can be perfectly instantiated with namespaces. There's no compatibility problem, the extended objects are working as usual. Because it's all single precision still..... It's compiled with PD_FLOAT_PRECISION 32, the core code as well. Shall we not better start another repo with a clone of the full pd-extended.git to work on? Katja

2 2

[ pure-data-Patches-3420484 ] Invalid memory access in s_utf8.c
by SourceForge.net 09 Oct '11

09 Oct '11

Patches item #3420484, was opened at 2011-10-07 23:10 Message generated for change (Comment added) made by eighthave 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: Open Resolution: None Priority: 5 Private: No Submitted By: Marvin Humphrey (creamygoodness) Assigned to: Nobody/Anonymous (nobody) 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: Hans-Christoph Steiner (eighthave) Date: 2011-10-09 12: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 20: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

tclpd works!
by Hans-Christoph Steiner 09 Oct '11

09 Oct '11

Hey Federico, Tclpd is working on Mac OS X, very exciting. I was just going through your examples, and I wanted to report some errors, some minor, some major. Which reminds me, do you know about logpost()? It allows you to post at different levels, like normal, debug, error, etc. For the "Tcl loader" message that shows with file was loaded, that is debug info, so it should be posted like: logpost(NULL, 3, "Tcl loader: %", filename); If you have a t_class pointer, i.e. t_dynreceive *x, you can add that instead of NULL, and it'll be a traceable message, i.e. Find menu -> Find last error... ---------------------------------------- dynreceive-help.pd Tcl loader: loaded /Applications/Pd-0.43.1-extended-20111009.app/ Contents/Resources/extra/tclpd/examples/dynreceive.tcl out: loadbang ---------------------------------------- dynroute-help.pd Tcl loader: loaded /Applications/Pd-0.43.1-extended-20111009.app/ Contents/Resources/extra/tclpd/examples/dynroute.tcl Tcl class dynroute: inlet 0: no such method: loadbang ---------------------------------------- list_change-help.pd Tcl loader: loaded /Applications/Pd-0.43.1-extended-20111009.app/ Contents/Resources/extra/tclpd/examples/list_change.tcl Tcl class list_change: inlet 0: no such method: loadbang ---------------------------------------- bitmap-help.pd Tcl class bitmap: inlet 0: no such method: loadbang Tcl class bitmap: inlet 0: no such method: loadbang Tcl class bitmap: inlet 0: no such method: loadbang ---------------------------------------- bitmap-madness.pd tclpd error: unknown option '8.0' (see stderr for details) bitmap 8 32 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ... couldn't create ---------------------------------------- slider2-help.pd tclpd error: invalid command name "tclpd_get_instance_text" (see stderr for details) slider2 -width 130 -height 15 -headsz 3 -rangebottom 0 -rangetop 127 -init 0 -initvalue 95 -jumponclick 0 -label norm -labelpos top -orient horizontal -sendsymbol empty -receivesymbol empty -fgcolor #000000 - bgcolor #ffffff -lblcolor #000000 ... couldn't create tclpd error: invalid command name "tclpd_get_instance_text" (see stderr for details) slider2 -width 130 -height 15 -headsz 3 -rangebottom 127 -rangetop 0 -init 0 -initvalue 70 -jumponclick 0 -label rev -labelpos top -orient horizontal -sendsymbol empty -receivesymbol empty -fgcolor #000000 - bgcolor #ffffff -lblcolor #000000 ... couldn't create tclpd error: invalid command name "tclpd_get_instance_text" (see stderr for details) slider2 -width 130 -height 15 -headsz 3 -rangebottom 0 -rangetop 255 -init 0 -initvalue 202.795 -jumponclick 0 -label empty -labelpos top - orient horizontal -sendsymbol $0.sl-out -receivesymbol $0.sl-in - fgcolor #000000 -bgcolor #20ca34 -lblcolor #000000 ... couldn't create ---------------------------------------------------------------------------- The arc of history bends towards justice. - Dr. Martin Luther King, Jr.

1 0

Fwd: pd double autobuilds
by katja 09 Oct '11

09 Oct '11

On Sat, Oct 8, 2011 at 4:51 PM, Hans-Christoph Steiner <hans(a)at.or.at> wrote: > And yes, vanilla/ is an experiment in splitting out the internals into a > library. This allows people to write highly optimized versions of it for > specific situations, like specific CPUs, and then use and distribute them > easily. Ah, I see. If loaded, vanilla/ takes precedence over the corresponding core class definitions. I noticed classes like sqrt~ which have double-incompatible definitions so vanilla/ requires some modifications. Further I would like to work on cyclone as there are Hoeldrich style routines in it. I'll send an SVN write access request to the dev list, for these modules to start with. Katja

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
14
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 October 2011