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
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_…
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_…
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_…
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
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_…
Patches item #3485013, was opened at 2012-02-06 08:28
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3485013&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: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: File->Save As..., Edit->Copy, Edit->Select All for Pd Window
Initial Comment:
I just implemented File->Save As..., Edit->Copy, and Edit->Select All for
the Pd window. Its not the whole list that you posted here, but I think
its the most commonly used ones. Its in Pd-extended, and I attached the
patch.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-02-16 14:08
Message:
x0V7jz <a href="http://iudhaaqllzhm.com/">iudhaaqllzhm</a>,
[url=http://yedimckrnkdq.com/]yedimckrnkdq[/url],
[link=http://aygazhtvcgyl.com/]aygazhtvcgyl[/link],
http://wxbunjrnpczw.com/
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3485013&group_…
Bugs item #3488333, was opened at 2012-02-16 13:45
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3488333&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Help menu searching not responding
Initial Comment:
i can use pd without issue except for when i want to access the Help menu. I'm unable to type anything into the search. cursor doesn't blink and pressing keys on the keyboard produce nothing.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3488333&group_…
Patches item #1502860, was opened at 2006-06-08 05:33
Message generated for change (Comment added) made by zmoelnig
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: 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_…
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-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_…