Pd-dev February 2012

pd-dev@lists.iem.at

18 participants
102 discussions

[ pure-data-Patches-3481846 ] [bugfix] on start, the Pd window doesn't always show msgs
by SourceForge.net 20 Feb '12

20 Feb '12

Patches item #3481846, was opened at 2012-01-30 17:41 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3481846&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: 8 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: [bugfix] on start, the Pd window doesn't always show msgs Initial Comment: Sometimes, when Pd starts, it only writes a portion of the stored ::pdwindow::logbuffer to the Pd Window. This tiny patch fixes that by waiting for the event loop before printing the logbuffer to the Pd window. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-02-19 17:57 Message: Hmm, the attached file doesn't look loke a patch file (some HTM trash instead)??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3481846&group_…

1 0

[ pure-data-Bugs-3489433 ] Excesive Spacing Between Logs In PD Window
by SourceForge.net 19 Feb '12

19 Feb '12

Bugs item #3489433, was opened at 2012-02-19 11:38 Message generated for change (Tracker Item Submitted) made by megrimm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489433&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: pd-extended Group: v0.43 Status: Open Resolution: None Priority: 5 Private: No Submitted By: megrimm (megrimm) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Excesive Spacing Between Logs In PD Window Initial Comment: Pd-Extended 0.43.1 - most recent 10.5 autobuild osx 10.7 When changing "Log" numbers from the drop down Log window there is either excessive spacing between items or not enough spacing. For example, If Log 2 is chosen and there are several "...couldn't create"'s there is no spacing between items. If Log 2 is chosen there is excessive spacing between log items. If for example log 4 is then chosen, those spaces are filled in. I guess this is not detrimental to functionality but more of an aesthetic bug. Ideally no matter what log mode is chosen the viewable items should all be single spaced, no? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489433&group_…

1 0

[ pure-data-Bugs-3489348 ] cputime not working
by SourceForge.net 19 Feb '12

19 Feb '12

Bugs item #3489348, was opened at 2012-02-19 02:17 Message generated for change (Tracker Item Submitted) made by angelfaraldo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489348&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: pd-extended Group: v0.43 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ángel faraldo (angelfaraldo) Assigned to: Hans-Christoph Steiner (eighthave) Summary: cputime not working Initial Comment: Pd version pd-0.43.1-extended-20120218-macosx105-i386 Mac OSX 10.6.8/Intel [cputime] doesn't produce any output, although it doesn't report an error in the pd window. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489348&group_…

1 0

[ pure-data-Bugs-3489062 ] problem with audio (asio?)
by SourceForge.net 18 Feb '12

18 Feb '12

Bugs item #3489062, was opened at 2012-02-18 10:10 Message generated for change (Tracker Item Submitted) made by jmmmp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489062&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: pd-extended Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: João Pais (jmmmp) Assigned to: Hans-Christoph Steiner (eighthave) Summary: problem with audio (asio?) Initial Comment: In XP pd-ext 0.43 (build from yesterday), I get audio problems: trying to run with asio (as I always do with 0.42), the audio is very noisy. It sounds as if the audio isn't synced to the system card, or something. The sinus in the audio test patch has lots of irregular clicks, almost as if they would be dropouts. This is with asio. With standard audio (MMIO) the result is much worse, but similar. Sometimes it sends messages as "can't synch audio". Audio options are -asio -audioindev 2 -audiooutdev 2 -channels 2 -midiindev 1 -midioutdev 1 -audiobuf 40, and they always worked with previous versions of pd-ext. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489062&group_…

1 0

Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
by Charles Henry 18 Feb '12

18 Feb '12

On Wed, Jan 25, 2012 at 11:46 AM, Peter Brinkmann <peter.brinkmann(a)googlemail.com> wrote: > > Hi Chuck, > Check out the early bits of this thread --- various use cases already came > up along the way: > http://lists.puredata.info/pipermail/pd-dev/2012-01/017992.html. The short > version is that libpd is being used in such a wide range of settings that > you can come up with legitimate use cases for pretty much anything (single > Pd instance shared between several threads, multiple Pd instances in one > thread, and anything in between). At the level of the audio library, it's > impossible to make good assumptions about threading. Hi Peter That's the part I really don't understand, and I don't really have a clear picture of how you want to be able to control/choose between those cases. I can also see how there could be more capabilities tied to having multiple threads generally. But specifically, I can't say. I have no clue. >> I remember a conversation with IOhannes in August about >> multi-threading audio via sub-canvas user interface object (propose >> thread~ akin to block~). If all you're after is audio >> multi-threading--there's no need for multiple instances of Pd. >> Threads could be used to start a portion of the dsp chain, running >> asynchronously, and then join/synchronize with Pd when finished. > > > I don't think a patch is the place where decisions about threading should be > made. Threading is an implementation detail that users shouldn't have to > worry about, and besides, whether you have anything to gain from threading > will depend on a number of factors that users won't necessarily be able to > control or even know about. I have a different view. Every sort of use for Pd is like writing a program--you should assume Pd users are writing programs with every sort of tool you give them--the flipside to having to control threading explicitly is that you get to control how finely grained the threading is. Putting it on the patching level is just the user interface--and it can work out nicely for grouping. Even if you have some automatic tools, you may still want to have explicit control through another available interface (e.g. for debugging). >> What this would look like: Add a thread_prolog, thread_epilog, and >> thread_sync function. The thread_prolog function that occurs before >> block_prolog, starts a thread running the portion of dsp chain >> cointained within, and returns the pointer to the function following >> the thread_epilog. The thread_epilog function that occurs after >> block_epilog--waits for synchronization and returns. >> >> >> What's the difficult part: You would need to have a good ordering of >> the dsp chain to take advantage of concurrency--each subcanvas having >> a thread~ object needs to kick off as early as possible, followed by >> objects that have no dependence on its output. Secondly, you'd need >> to put thread_sync on the dsp chain immediately before you will >> encounter functions with data dependencies. > > > I believe it's much simpler than that. It should be enough to just do a > topological sort of the signal processing graph; that'll tell you which > objects are ready to run at any given time, and then you can parallelize the > invocation of their perform functions (or not, depending on how many > processors are available). I don't think there's any need to explicitly > synchronize much; tools like OpenMP should be able to handle this > implicitly. > Cheers, > Peter For that--the dspchain (an array of int*) makes a very bad structure. So, you'll want to re-write a handful of functions and data structures around having multiple concurrent branches of computations. I actually really like this problem :D I can picture a linked list of dspchains to do this. But... the description of the sort algorithm really will determine what the data structure ought to be. Re-writing dsp_tick() is nearly sacrilege to me... beautiful bit of code there, but that would have to be done according to whatever you do to dspchain. Chuck

5 12

[ pure-data-Bugs-3488995 ] playlist crash with "location" message
by SourceForge.net 18 Feb '12

18 Feb '12

Bugs item #3488995, was opened at 2012-02-18 04:34 Message generated for change (Tracker Item Submitted) made by deme-x You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3488995&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: externals Group: v0.43 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Santi (deme-x) Assigned to: Nobody/Anonymous (nobody) Summary: playlist crash with "location" message Initial Comment: Pd-extended crash with segmentation fault when i send a "location" message to playlist. Using pd-extended 0.43.1~cvs20120217-1 build night in Debian Wheezy i386. My machine is a Dell XPS L502X: Intel Core i7-2630QM processor 2.00 GHz, 8GB RAM, 2GB NVIDIA GeForce GT 540M Graphics card This is the output from valgrind: root@video:/home/santi# valgrind pd-extended playlist-help.pd ==8095== Memcheck, a memory error detector ==8095== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==8095== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==8095== Command: pd-extended playlist-help.pd ==8095== ==8095== Invalid read of size 1 ==8095== at 0x4315AA6: vfprintf (vfprintf.c:1620) ==8095== by 0x433833B: vsprintf (iovsprintf.c:43) ==8095== by 0x431E28A: sprintf (sprintf.c:34) ==8095== by 0x80B0FF5: alsa_getdevs (s_audio_alsa.c:876) ==8095== Address 0x4530370 is 40 bytes inside a block of size 376 free'd ==8095== at 0x402421C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x40929EA: snd_ctl_card_info_free (in /usr/lib/i386-linux-gnu/libasound.so.2.0.0) ==8095== ==8095== Invalid read of size 1 ==8095== at 0x4343760: _IO_default_xsputn (genops.c:480) ==8095== by 0x4315971: vfprintf (vfprintf.c:1620) ==8095== by 0x433833B: vsprintf (iovsprintf.c:43) ==8095== by 0x431E28A: sprintf (sprintf.c:34) ==8095== by 0x80B0FF5: alsa_getdevs (s_audio_alsa.c:876) ==8095== Address 0x4530370 is 40 bytes inside a block of size 376 free'd ==8095== at 0x402421C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x40929EA: snd_ctl_card_info_free (in /usr/lib/i386-linux-gnu/libasound.so.2.0.0) ==8095== ==8095== Invalid read of size 1 ==8095== at 0x434376D: _IO_default_xsputn (genops.c:479) ==8095== by 0x4315971: vfprintf (vfprintf.c:1620) ==8095== by 0x433833B: vsprintf (iovsprintf.c:43) ==8095== by 0x431E28A: sprintf (sprintf.c:34) ==8095== by 0x80B0FF5: alsa_getdevs (s_audio_alsa.c:876) ==8095== Address 0x4530372 is 42 bytes inside a block of size 376 free'd ==8095== at 0x402421C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x40929EA: snd_ctl_card_info_free (in /usr/lib/i386-linux-gnu/libasound.so.2.0.0) ==8095== ==8095== Invalid read of size 1 ==8095== at 0x4315AA6: vfprintf (vfprintf.c:1620) ==8095== by 0x433833B: vsprintf (iovsprintf.c:43) ==8095== by 0x431E28A: sprintf (sprintf.c:34) ==8095== by 0x80B100F: alsa_getdevs (s_audio_alsa.c:877) ==8095== by 0x65746E48: ??? ==8095== Address 0x4530370 is 40 bytes inside a block of size 376 free'd ==8095== at 0x402421C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x40929EA: snd_ctl_card_info_free (in /usr/lib/i386-linux-gnu/libasound.so.2.0.0) ==8095== ==8095== Invalid read of size 1 ==8095== at 0x4315AA6: vfprintf (vfprintf.c:1620) ==8095== by 0x433833B: vsprintf (iovsprintf.c:43) ==8095== by 0x431E28A: sprintf (sprintf.c:34) ==8095== by 0x80B1023: alsa_getdevs (s_audio_alsa.c:878) ==8095== by 0x65746E48: ??? ==8095== Address 0x4530370 is 40 bytes inside a block of size 376 free'd ==8095== at 0x402421C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x40929EA: snd_ctl_card_info_free (in /usr/lib/i386-linux-gnu/libasound.so.2.0.0) ==8095== ==8095== Invalid read of size 1 ==8095== at 0x4315AA6: vfprintf (vfprintf.c:1620) ==8095== by 0x433833B: vsprintf (iovsprintf.c:43) ==8095== by 0x431E28A: sprintf (sprintf.c:34) ==8095== by 0x80B103F: alsa_getdevs (s_audio_alsa.c:879) ==8095== by 0x65746E48: ??? ==8095== Address 0x4530370 is 40 bytes inside a block of size 376 free'd ==8095== at 0x402421C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x40929EA: snd_ctl_card_info_free (in /usr/lib/i386-linux-gnu/libasound.so.2.0.0) ==8095== Pd-0.43.1 ("extended-20120217") compiled 12:26:24 Feb 17 2012 port 5401 TCL_LIBRARY="/usr/lib/pd-extended/lib/tcl/library" TK_LIBRARY="/usr/lib/pd-extended/lib/tk/library" wish "/usr/lib/pd-extended/tcl//pd-gui.tcl" 5401 priority 6 scheduling enabled. Waiting for connection request... priority 8 scheduling enabled. /usr/lib/pd-extended/bin/pd-watchdog ... connected snd_pcm_open (input): Device or resource busy snd_pcm_open (output): Device or resource busy open: /etc/pd/gem.conf: No such file or directory open: /root/.pd/gem.conf: No such file or directory open: ./gem.conf: No such file or directory ==8095== Invalid write of size 1 ==8095== at 0x7091D54: playlist_new (playlist.c:893) ==8095== by 0x8082425: pd_typedmess (m_class.c:714) ==8095== by 0x80824EA: new_anything (m_class.c:571) ==8095== by 0x8081F3C: pd_typedmess (m_class.c:812) ==8095== by 0x80626B4: canvas_objtext (g_text.c:96) ==8095== by 0x8063A54: canvas_obj (g_text.c:193) ==8095== by 0x8082079: pd_typedmess (m_class.c:715) ==8095== by 0x8088C31: binbuf_evalfile (m_binbuf.c:1529) ==8095== by 0x8088CD2: glob_evalfile (m_binbuf.c:1545) ==8095== by 0x808AE59: openit (s_main.c:195) ==8095== by 0x808B1C1: glob_initfromgui (s_main.c:254) ==8095== by 0x8082079: pd_typedmess (m_class.c:715) ==8095== Address 0x703c957 is 0 bytes after a block of size 39 alloc'd ==8095== at 0x4023796: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x808419C: getbytes (m_memory.c:24) ==8095== by 0x8082425: pd_typedmess (m_class.c:714) ==8095== by 0x80824EA: new_anything (m_class.c:571) ==8095== by 0x8081F3C: pd_typedmess (m_class.c:812) ==8095== by 0x80626B4: canvas_objtext (g_text.c:96) ==8095== by 0x8063A54: canvas_obj (g_text.c:193) ==8095== by 0x8082079: pd_typedmess (m_class.c:715) ==8095== by 0x8088C31: binbuf_evalfile (m_binbuf.c:1529) ==8095== by 0x8088CD2: glob_evalfile (m_binbuf.c:1545) ==8095== by 0x808AE59: openit (s_main.c:195) ==8095== by 0x808B1C1: glob_initfromgui (s_main.c:254) ==8095== ==8095== Invalid read of size 1 ==8095== at 0x4315AA6: vfprintf (vfprintf.c:1620) ==8095== by 0x433A0EF: vsnprintf (vsnprintf.c:120) ==8095== by 0x808CE51: sys_vgui (s_inter.c:661) ==8095== by 0x708FB7D: playlist_draw_new (playlist.c:355) ==8095== by 0x7090E33: playlist_graphics (playlist.c:616) ==8095== by 0x8082311: pd_typedmess (m_class.c:791) ==8095== Address 0x703c957 is 0 bytes after a block of size 39 alloc'd ==8095== at 0x4023796: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x808419C: getbytes (m_memory.c:24) ==8095== by 0x8082425: pd_typedmess (m_class.c:714) ==8095== by 0x80824EA: new_anything (m_class.c:571) ==8095== by 0x8081F3C: pd_typedmess (m_class.c:812) ==8095== by 0x80626B4: canvas_objtext (g_text.c:96) ==8095== by 0x8063A54: canvas_obj (g_text.c:193) ==8095== by 0x8082079: pd_typedmess (m_class.c:715) ==8095== by 0x8088C31: binbuf_evalfile (m_binbuf.c:1529) ==8095== by 0x8088CD2: glob_evalfile (m_binbuf.c:1545) ==8095== by 0x808AE59: openit (s_main.c:195) ==8095== by 0x808B1C1: glob_initfromgui (s_main.c:254) ==8095== ==8095== Syscall param open(filename) points to unaddressable byte(s) ==8095== at 0x4397993: __open_nocancel (syscall-template.S:82) ==8095== by 0x436DAC1: scandir (scandir.c:62) ==8095== by 0x708EFF0: playlist_update_dir (playlist.c:215) ==8095== by 0x708FB7D: playlist_draw_new (playlist.c:355) ==8095== by 0x7090E33: playlist_graphics (playlist.c:616) ==8095== by 0x8082311: pd_typedmess (m_class.c:791) ==8095== Address 0x703c957 is 0 bytes after a block of size 39 alloc'd ==8095== at 0x4023796: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x808419C: getbytes (m_memory.c:24) ==8095== by 0x8082425: pd_typedmess (m_class.c:714) ==8095== by 0x80824EA: new_anything (m_class.c:571) ==8095== by 0x8081F3C: pd_typedmess (m_class.c:812) ==8095== by 0x80626B4: canvas_objtext (g_text.c:96) ==8095== by 0x8063A54: canvas_obj (g_text.c:193) ==8095== by 0x8082079: pd_typedmess (m_class.c:715) ==8095== by 0x8088C31: binbuf_evalfile (m_binbuf.c:1529) ==8095== by 0x8088CD2: glob_evalfile (m_binbuf.c:1545) ==8095== by 0x808AE59: openit (s_main.c:195) ==8095== by 0x808B1C1: glob_initfromgui (s_main.c:254) ==8095== ==8095== Invalid read of size 1 ==8095== at 0x40259B5: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x7092042: playlist_location (playlist.c:970) ==8095== by 0x80822DA: pd_typedmess (m_class.c:793) ==8095== Address 0x703c957 is 0 bytes after a block of size 39 alloc'd ==8095== at 0x4023796: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x808419C: getbytes (m_memory.c:24) ==8095== by 0x8082425: pd_typedmess (m_class.c:714) ==8095== by 0x80824EA: new_anything (m_class.c:571) ==8095== by 0x8081F3C: pd_typedmess (m_class.c:812) ==8095== by 0x80626B4: canvas_objtext (g_text.c:96) ==8095== by 0x8063A54: canvas_obj (g_text.c:193) ==8095== by 0x8082079: pd_typedmess (m_class.c:715) ==8095== by 0x8088C31: binbuf_evalfile (m_binbuf.c:1529) ==8095== by 0x8088CD2: glob_evalfile (m_binbuf.c:1545) ==8095== by 0x808AE59: openit (s_main.c:195) ==8095== by 0x808B1C1: glob_initfromgui (s_main.c:254) ==8095== ==8095== Invalid write of size 1 ==8095== at 0x4025C03: strncpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x709212B: playlist_location (playlist.c:993) ==8095== by 0x80822DA: pd_typedmess (m_class.c:793) ==8095== Address 0x703c957 is 0 bytes after a block of size 39 alloc'd ==8095== at 0x4023796: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x808419C: getbytes (m_memory.c:24) ==8095== by 0x8082425: pd_typedmess (m_class.c:714) ==8095== by 0x80824EA: new_anything (m_class.c:571) ==8095== by 0x8081F3C: pd_typedmess (m_class.c:812) ==8095== by 0x80626B4: canvas_objtext (g_text.c:96) ==8095== by 0x8063A54: canvas_obj (g_text.c:193) ==8095== by 0x8082079: pd_typedmess (m_class.c:715) ==8095== by 0x8088C31: binbuf_evalfile (m_binbuf.c:1529) ==8095== by 0x8088CD2: glob_evalfile (m_binbuf.c:1545) ==8095== by 0x808AE59: openit (s_main.c:195) ==8095== by 0x808B1C1: glob_initfromgui (s_main.c:254) ==8095== ==8095== Invalid write of size 1 ==8095== at 0x4025BF8: strncpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x709212B: playlist_location (playlist.c:993) ==8095== by 0x80822DA: pd_typedmess (m_class.c:793) ==8095== Address 0x703c959 is 2 bytes after a block of size 39 alloc'd ==8095== at 0x4023796: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x808419C: getbytes (m_memory.c:24) ==8095== by 0x8082425: pd_typedmess (m_class.c:714) ==8095== by 0x80824EA: new_anything (m_class.c:571) ==8095== by 0x8081F3C: pd_typedmess (m_class.c:812) ==8095== by 0x80626B4: canvas_objtext (g_text.c:96) ==8095== by 0x8063A54: canvas_obj (g_text.c:193) ==8095== by 0x8082079: pd_typedmess (m_class.c:715) ==8095== by 0x8088C31: binbuf_evalfile (m_binbuf.c:1529) ==8095== by 0x8088CD2: glob_evalfile (m_binbuf.c:1545) ==8095== by 0x808AE59: openit (s_main.c:195) ==8095== by 0x808B1C1: glob_initfromgui (s_main.c:254) ==8095== ==8095== ==8095== Process terminating with default action of signal 11 (SIGSEGV) ==8095== Bad permissions for mapped region at address 0x703D000 ==8095== at 0x4025C03: strncpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8095== by 0x709212B: playlist_location (playlist.c:993) ==8095== by 0x80822DA: pd_typedmess (m_class.c:793) ==8095== ==8095== HEAP SUMMARY: ==8095== in use at exit: 1,362,981 bytes in 8,042 blocks ==8095== total heap usage: 13,707 allocs, 5,665 frees, 21,424,473 bytes allocated ==8095== ==8095== LEAK SUMMARY: ==8095== definitely lost: 1,556 bytes in 24 blocks ==8095== indirectly lost: 4,573 bytes in 167 blocks ==8095== possibly lost: 452,642 bytes in 1,283 blocks ==8095== still reachable: 904,210 bytes in 6,568 blocks ==8095== suppressed: 0 bytes in 0 blocks ==8095== Rerun with --leak-check=full to see details of leaked memory ==8095== ==8095== For counts of detected and suppressed errors, rerun with: -v ==8095== ERROR SUMMARY: 1415 errors from 12 contexts (suppressed: 287 from 12) Terminado (killed) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3488995&group_…

1 0

[ pure-data-Bugs-3488694 ] rtc help patches broken objects ... again
by SourceForge.net 17 Feb '12

17 Feb '12

Bugs item #3488694, was opened at 2012-02-17 14:36 Message generated for change (Tracker Item Submitted) made by megrimm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3488694&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: pd-extended Group: v0.43 Status: Open Resolution: None Priority: 5 Private: No Submitted By: megrimm (megrimm) Assigned to: Hans-Christoph Steiner (eighthave) Summary: rtc help patches broken objects ... again Initial Comment: Pd version 0.43.1-extended Mac OS X 10.7.2/Intel built-in sound sorry I'm submitting this again because the original got closed and I never responded... and im running into the same problem. The problem here is specifically in extended which is packaged with both list-abs and rtc. Many of the help patches break (also the abs) because there is no pointer to the list-abs (import, declare, [list-abs/list-whatever]).... Right now in extended rtc is pretty useless because an rtc abstraction can not be used because many depend on list-abs yet the list-abs library is not declared. I suggest all abs be changes so anything using [list-abs] is written [list-abs/list-whatever] attached is screenshot from fresh pd-extended install....help-browser->rtc->serial-help.pd (for example) thanks! mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3488694&group_…

1 0

[ pure-data-Patches-1502860 ] class-destructor (free-method) not called when quitting pd
by SourceForge.net 17 Feb '12

17 Feb '12

Patches item #1502860, was opened at 2006-06-08 05:33 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1502860&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: Open Resolution: None Priority: 7 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: class-destructor (free-method) not called when quitting pd Initial Comment: when an object is destroyed (either directly deleted or by closing the patch containing it) the "free" method (a "destructor" in c++-speak) for this object is called. however, when pd is "quit" (e.g. "Ctrl-Q"), this destructor does not get called, which potentially leaves the system in a bad state. the attached patch fixes this by adding a "glob_closeall()" function to g_editor.c (which closes all root canvases) and calling it from within glob_quit() in s_inter.c ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-02-17 12:20 Message: Ok, I just included this patch in pd-extended.git, tomorrow's builds should have it. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-02-16 10:57 Message: i can't think of any. iirc, miller mentioned something along the lines, that calling all those destructors during an emergency shutdown might just take too long during a performance. (otoh, if a network port is blocked due to not properly cleaning up, this might take even longer) hopefully, if the inclusion in Pd-extended can show that there is no problem (which i believe), we could get it into Pd-proper. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-02-16 10:45 Message: What are the risks or downsides to this patch? I am thinking it should be in Pd-extended ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-18 09:18 Message: updated the patch so it applies to Pd-0.43 (and incorporated thomas' suggestion) ---------------------------------------------------------------------- Comment By: Thomas Grill (xovo) Date: 2006-08-02 09:20 Message: Logged In: YES user_id=350252 I think there's a problem in this patch when traversing the canvas list with canvases vanishing meanwhile. It should be more like: void glob_closeall(void*dummy, t_floatarg fforce) { t_canvas*x,*y; for (x = canvas_list; x; ) { y = x->gl_next; canvas_menuclose(x, fforce); /* forced closing of this root canvas */ x = y; } } Still, this assumes that PD doesn't do more than removing that one entry from the canvas list, which is not very clean. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-07-26 02:43 Message: Logged In: YES user_id=564396 actually i think this is rather important when objects interface with the system - so i raised the priority ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1502860&group_…

1 0

Re: [PD-dev] libname-meta.pd
by Hans-Christoph Steiner 17 Feb '12

17 Feb '12

Let's keep this kind of stuff on the list, I cc'ed pd-dev. Fixed with this commit: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revisio… Using this regexp: sed -i 's|\([^\\]\),|\1 \\,|g' */*-meta.pd .hc On Feb 16, 2012, at 10:38 PM, Jonathan Wilkes wrote: > Hi Hans, > Did you autocreate all those libname-meta.pd patches? I think you must have, because for example you have bare commas inside one of the comments in boids-meta.pd. > > Can you autocorrect them? > > Thanks, > Jonathan > ---------------------------------------------------------------------------- As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin

2 1

[ pure-data-Bugs-3488357 ] plugin~ does not work with -nogui parameter
by SourceForge.net 17 Feb '12

17 Feb '12

Bugs item #3488357, was opened at 2012-02-16 15:19 Message generated for change (Tracker Item Submitted) made by ailo-at You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3488357&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: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ailo (ailo-at) Assigned to: Nobody/Anonymous (nobody) Summary: plugin~ does not work with -nogui parameter Initial Comment: When starting pd-extended on Linux with -nogui and a patch containing a plugin~ external, pd-extended fails to start with this error message: "pd-extended: plugin~.c:553: plugin_tilde_ladspa_open_plugin: Assertion `sample_rate != 0' failed. Pd: signal 6" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3488357&group_…

1 0

← Newer
1
2
3
4
5
6
7
...
11
Older →

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