Re: [PD] abstraction penalty benchmarks
On Fri, Aug 9, 2013 at 5:27 AM, Miller Puckette m...@ucsd.edu wrote: Here's a guess - I think each copy of the abstraction binds itself to a symbol, pd-name. Binding is fast bt unbinding is linear-time in the number of things bound to the symbol... ouch. There's a good reason to bind toplevels and named sub-patches to ther names, but I think there's little reason to do it for abstractions - perhaps I can take this out, but I'd have to leave it as an option for compatibility (ouch!) Miller Hi Miller, Just very generally BTW: Do you mean binary compatibility or patch compatibility? Either way, what are your thoughts about the possibility of a future Pd-1.0 which would break (some kind of) compatibility for the sake of revolutionary progress? András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Benefits of using an external soundcard?
El 08/08/13 17:50, Charles Z Henry escribió: Hi Mario The number one reason for having an external sound card is noise isolation. The card's proximity to the power supply and motherboard are bad for EM noise. Also, a computer power supply and a good audio power supply for recording have much the same relationship--there's more noise in switching electronics. Next, there's the size constraints. You'd have a hard time adding all the connectors for a large number of channels on a card which plugs in to your PCI(e) slots. It's ok, I have a notebook: 1 plug out, 1 plug in. Third: there's not as great a need for bandwidth for audio as there is with video. Video cards need all that PCI(e) bandwidth. Audio doesn't. It's a relatively small amount of data. Of course--I think USB and firewire really don't have enough bandwidth for good scalability, but that's another discussion. But... what are you doing with it? You have different requirements for recording and for live sound. Live sound: just do it up. No one will likely notice. Live sound is my purpose. Mic-in looping-station and multieffects system (following the steps of Beardyman and his Beardytron_5000). But, sorry about not understanding your expresion (english is not my native language) What do you mean with just do it up, no one will likely notice? Should I buy it or no one will notice the difference? I think you mean I should... If you're planning on recording something on just 2 channels on the built-in sound card, keep in mind that your dynamic range will be pretty bad, even if you get a good pre-amp in the middle to take the most advantage of your range. You'd much rather have an external sound card with some adjustable analog pre-amps in the box. About the soundcard I post, the Encore 7.1 ENMAB-8CM (http://www.encore-usa.com/ar/support/ENMAB-8CM)... it's really a china generic useless card... or it's good for starting? It has no analog pot. Chuck Thanks so much for your time. On Thu, Aug 8, 2013 at 3:30 PM, Mario Mey mario...@gmail.com mailto:mario...@gmail.com wrote: I'm using my integrated soundcard: 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40). I know that Pd is processing on CPU and I don't need more than 2 inputs and 2 outputs channels. So... I think that there's no need to buy an external one. Is there any benefit of using one? I know that this USB soundcard is not a very good one... but maybe it's good for my economy. What's your opinion? http://www.encore-usa.com/ar/support/ENMAB-8CM ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Benefits of using an external soundcard?
Is there a specific type of microphone you will be using? I've seen some videos of Beardyman recently using some type of hands-free lavalier microphone. This and other condenser microphones require Phantom Power, which is provided by many audio interfaces and mixers but generally not built in to an internal soundcard. See how far you can get with what you have; there's no point in buying something that you don't need. But you might find that you do need one eventually. Keep in mind that you'll need very low latency (less than 20 miliseconds) for your application. I'm not sure if this is affected by the sound card or not. All of the audio processing happens on the CPU, but maybe the buffering stages for the sound card add enough delay to add latency... could somebody with more familiarity chime in here? On Fri, Aug 9, 2013 at 7:28 AM, Mario Mey mario...@gmail.com wrote: El 08/08/13 17:50, Charles Z Henry escribió: Hi Mario The number one reason for having an external sound card is noise isolation. The card's proximity to the power supply and motherboard are bad for EM noise. Also, a computer power supply and a good audio power supply for recording have much the same relationship--there's more noise in switching electronics. Next, there's the size constraints. You'd have a hard time adding all the connectors for a large number of channels on a card which plugs in to your PCI(e) slots. It's ok, I have a notebook: 1 plug out, 1 plug in. Third: there's not as great a need for bandwidth for audio as there is with video. Video cards need all that PCI(e) bandwidth. Audio doesn't. It's a relatively small amount of data. Of course--I think USB and firewire really don't have enough bandwidth for good scalability, but that's another discussion. But... what are you doing with it? You have different requirements for recording and for live sound. Live sound: just do it up. No one will likely notice. Live sound is my purpose. Mic-in looping-station and multieffects system (following the steps of Beardyman and his Beardytron_5000). But, sorry about not understanding your expresion (english is not my native language) What do you mean with just do it up, no one will likely notice? Should I buy it or no one will notice the difference? I think you mean I should... If you're planning on recording something on just 2 channels on the built-in sound card, keep in mind that your dynamic range will be pretty bad, even if you get a good pre-amp in the middle to take the most advantage of your range. You'd much rather have an external sound card with some adjustable analog pre-amps in the box. About the soundcard I post, the Encore 7.1 ENMAB-8CM ( http://www.encore-usa.com/ar/support/ENMAB-8CM)... it's really a china generic useless card... or it's good for starting? It has no analog pot. Chuck Thanks so much for your time. On Thu, Aug 8, 2013 at 3:30 PM, Mario Mey mario...@gmail.com wrote: I'm using my integrated soundcard: 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40). I know that Pd is processing on CPU and I don't need more than 2 inputs and 2 outputs channels. So... I think that there's no need to buy an external one. Is there any benefit of using one? I know that this USB soundcard is not a very good one... but maybe it's good for my economy. What's your opinion? http://www.encore-usa.com/ar/support/ENMAB-8CM ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] routeOSC - dynamic routing?
Quoting Dan Wilcox danomat...@gmail.com: As far as I know, you can't match multiple levels at once, you'd need to do: [routeOSC /*] | [routeOSC /ID] yep. iirc, the OSC-specification only talks about pattern-matching on a per-path element. with that in mind and since OSC is really very herarchically thought, the above solution is not that bad. fgamrd\ IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
Hi,
On 09/08/13 04:27, Miller Puckette wrote:
Here's a guess - I think each copy of the abstraction binds itself to
a symbol, pd-name. Binding is fast bt unbinding is linear-time in the
number of things bound to the symbol... ouch.
Yes, I think that's it:
git master from yesterday
Pd-0.45.0 (test) compiled 17:10:02 Aug 8 2013
patch bench opendsp saveclose
small 4.6e-05 38.775 1.34085 44.326 4.012
medium 5.2e-05 314.812 10.2582 715.956 144.512
large 4.7e-05 2639.28 85.3561 78711.5 35918
git master, lightly patched with the attached
Pd-0.45.0 (test) compiled 14:36:39 Aug 9 2013
patch bench opendsp saveclose
small 4.3e-05 36.167 1.31707 39.657 3.447
medium 4.4e-05 291.52 9.8958 327.389 18.067
large 4.3e-05 2443.07 82.0808 3628.66 224.972
There's a good reason to bind toplevels and named sub-patches to ther names,
but I think there's little reason to do it for abstractions - perhaps I can
take this out, but I'd have to leave it as an option for compatibility (ouch!)
The attached patch doesn't do this, but it should be easy to add a
global compatibility flag to the new canvas_should_bind() function.
Toplevel patches are still bound to pd-name.pd and subpatches [pd
name] are still bound to pd-name; it's just abstraction instances
that no longer have the automatic binding.
On Thu, Aug 08, 2013 at 10:46:24PM -0400, Jonathan Wilkes wrote:
On 08/08/2013 04:57 PM, Claude Heiland-Allen wrote:
[snip]
The killer in the bottom right corner: with 8x as many abstractions, it
takes 100x as long to save an instance, and 200x as long to close the patch.
[snip]
Any idea why save is so much greater than close + open?
I think Miller had the answer.
Also, any idea what pd is doing for the bulk of that time when
I haven't profiled yet (I had trouble even getting debug symbols into an
installed Pd with the autoconf system, no success yet..), so the
following are just guesses:
saving
searching for copies of the abstraction to reload, then reloading them
via some select/cut/undo method (which preserves connections). also
unbinding symbols...
closing
calling all the destructors. also unbinding symbols...
opening
refinding/reloading/reparsing/reinstantiating all the abstractions (I
need to relocate my abstraction cache patches and update them to current Pd)
dsp'ing?
traversing each canvas to topologically sort its dsp objects and build
the dsp chain - which gets resizebytes() each time something is added,
could make it O(log(N)) count of resizes (doubling the size each time)
but I tried it and it saved about 9 microseconds, not worth the extra
complexity...
Claude
--
http://mathr.co.uk
From 16fd46b3abe83dba956b78385d01ad19737b6c76 Mon Sep 17 00:00:00 2001
From: Claude Heiland-Allen cla...@mathr.co.uk
Date: Fri, 9 Aug 2013 14:57:14 +0100
Subject: [PATCH] don't bind abstraction instances to pd-filename
---
src/g_canvas.c | 39 +--
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/src/g_canvas.c b/src/g_canvas.c
index 804ac57..c7a22d6 100644
--- a/src/g_canvas.c
+++ b/src/g_canvas.c
@@ -55,6 +55,9 @@ void canvas_reflecttitle(t_canvas *x);
static void canvas_addtolist(t_canvas *x);
static void canvas_takeofflist(t_canvas *x);
static void canvas_pop(t_canvas *x, t_floatarg fvis);
+static int canvas_should_bind(t_canvas *x);
+static void canvas_bind(t_canvas *x);
+static void canvas_unbind(t_canvas *x);
/* - functions to handle the canvas environment --- */
@@ -205,11 +208,9 @@ void canvas_makefilename(t_canvas *x, char *file, char *result, int resultsize)
void canvas_rename(t_canvas *x, t_symbol *s, t_symbol *dir)
{
-if (strcmp(x-gl_name-s_name, Pd))
-pd_unbind(x-gl_pd, canvas_makebindsym(x-gl_name));
+canvas_unbind(x);
x-gl_name = s;
-if (strcmp(x-gl_name-s_name, Pd))
-pd_bind(x-gl_pd, canvas_makebindsym(x-gl_name));
+canvas_bind(x);
if (x-gl_havewindow)
canvas_reflecttitle(x);
if (dir dir != s_)
@@ -379,8 +380,7 @@ t_canvas *canvas_new(void *dummy, t_symbol *sel, int argc, t_atom *argv)
x-gl_owner = owner;
x-gl_name = (*s-s_name ? s :
(canvas_newfilename ? canvas_newfilename : gensym(Pd)));
-if (strcmp(x-gl_name-s_name, Pd))
-pd_bind(x-gl_pd, canvas_makebindsym(x-gl_name));
+canvas_bind(x);
x-gl_loading = 1;
x-gl_goprect = 0; /* no GOP rectangle unless it's turned on later */
/* cancel vis flag if we're a subpatch of an
@@ -479,9 +479,8 @@ t_glist *glist_addglist(t_glist *g, t_symbol *sym,
x-gl_screeny1 = GLIST_DEFCANVASYLOC;
x-gl_screenx2 = 450;
x-gl_screeny2 = 300;
-if (strcmp(x-gl_name-s_name, Pd))
-pd_bind(x-gl_pd, canvas_makebindsym(x-gl_name));
x-gl_owner = g;
+canvas_bind(x);
x-gl_isgraph = 1;
x-gl_goprect = 0;
x-gl_obj.te_binbuf = binbuf_new();
@@ -723,8 +722,7 @@ void canvas_free(t_canvas
Re: [PD] Benefits of using an external soundcard?
On Fri, Aug 9, 2013 at 6:28 AM, Mario Mey mario...@gmail.com wrote: El 08/08/13 17:50, Charles Z Henry escribió: Hi Mario The number one reason for having an external sound card is noise isolation. The card's proximity to the power supply and motherboard are bad for EM noise. Also, a computer power supply and a good audio power supply for recording have much the same relationship--there's more noise in switching electronics. Next, there's the size constraints. You'd have a hard time adding all the connectors for a large number of channels on a card which plugs in to your PCI(e) slots. It's ok, I have a notebook: 1 plug out, 1 plug in. Third: there's not as great a need for bandwidth for audio as there is with video. Video cards need all that PCI(e) bandwidth. Audio doesn't. It's a relatively small amount of data. Of course--I think USB and firewire really don't have enough bandwidth for good scalability, but that's another discussion. But... what are you doing with it? You have different requirements for recording and for live sound. Live sound: just do it up. No one will likely notice. Live sound is my purpose. Mic-in looping-station and multieffects system (following the steps of Beardyman and his Beardytron_5000). But, sorry about not understanding your expresion (english is not my native language) What do you mean with just do it up, no one will likely notice? Should I buy it or no one will notice the difference? I think you mean I should... Just use the onboard sound. Live performance or installations can be much more tolerant of noise. You may have to tune your patches for the hardware, but don't give it too much thought and just do it up (a recommendation). I'm not familiar with Beardyman/tron_5000. That sounds cool. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
Hi Miller, Just very generally BTW: Do you mean binary compatibility or patch compatibility? Either way, what are your thoughts about the possibility of a future Pd-1.0 which would break (some kind of) compatibility for the sake of revolutionary progress? András I'm unwilling to break either patch or binary compatibility - Pd's original purpose is for interactive music and art and there is a big repertory now depending on Pd to remain runnable. I'm willing to make minor compatibility changes protected by compatibility switches. Pd now maintains a global compatibility version number to try to facilitate this. (It was necessitated by two bugs in DSP objects, one rather serious, that I wanted to fix without breaking old patches that might depend on the buggy behavior.) On a side note, the reason I'm so slow to add fetures to Pd is that I want to be sure that everything I do is something I'm willing to maintain for as long as I can. cheers Miller ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
There still could be situations where an abstraction has a sub-patch (pd foo
for instance) - I'm not clear as to whether those namings should be supressed
as well. It seems like a tricky problem - lots of people seem to use
abstractions with only one instance and might be depending on the bindings.
Maybe the rule should be that before a canvas binds itself to the symbol
it checks to see if anyone else already did and if so silently refuses
(protected with a compatibility flag as usual).
cheers
M
On Fri, Aug 09, 2013 at 03:15:52PM +0100, Claude Heiland-Allen wrote:
Hi,
On 09/08/13 04:27, Miller Puckette wrote:
Here's a guess - I think each copy of the abstraction binds itself to
a symbol, pd-name. Binding is fast bt unbinding is linear-time in the
number of things bound to the symbol... ouch.
Yes, I think that's it:
git master from yesterday
Pd-0.45.0 (test) compiled 17:10:02 Aug 8 2013
patch bench opendsp saveclose
small 4.6e-05 38.775 1.34085 44.326 4.012
medium 5.2e-05 314.812 10.2582 715.956 144.512
large 4.7e-05 2639.28 85.3561 78711.5 35918
git master, lightly patched with the attached
Pd-0.45.0 (test) compiled 14:36:39 Aug 9 2013
patch bench opendsp saveclose
small 4.3e-05 36.167 1.31707 39.657 3.447
medium 4.4e-05 291.52 9.8958 327.389 18.067
large 4.3e-05 2443.07 82.0808 3628.66 224.972
There's a good reason to bind toplevels and named sub-patches to ther names,
but I think there's little reason to do it for abstractions - perhaps I can
take this out, but I'd have to leave it as an option for compatibility
(ouch!)
The attached patch doesn't do this, but it should be easy to add a
global compatibility flag to the new canvas_should_bind() function.
Toplevel patches are still bound to pd-name.pd and subpatches [pd
name] are still bound to pd-name; it's just abstraction instances
that no longer have the automatic binding.
On Thu, Aug 08, 2013 at 10:46:24PM -0400, Jonathan Wilkes wrote:
On 08/08/2013 04:57 PM, Claude Heiland-Allen wrote:
[snip]
The killer in the bottom right corner: with 8x as many abstractions, it
takes 100x as long to save an instance, and 200x as long to close the
patch.
[snip]
Any idea why save is so much greater than close + open?
I think Miller had the answer.
Also, any idea what pd is doing for the bulk of that time when
I haven't profiled yet (I had trouble even getting debug symbols into an
installed Pd with the autoconf system, no success yet..), so the
following are just guesses:
saving
searching for copies of the abstraction to reload, then reloading them
via some select/cut/undo method (which preserves connections). also
unbinding symbols...
closing
calling all the destructors. also unbinding symbols...
opening
refinding/reloading/reparsing/reinstantiating all the abstractions (I
need to relocate my abstraction cache patches and update them to current Pd)
dsp'ing?
traversing each canvas to topologically sort its dsp objects and build
the dsp chain - which gets resizebytes() each time something is added,
could make it O(log(N)) count of resizes (doubling the size each time)
but I tried it and it saved about 9 microseconds, not worth the extra
complexity...
Claude
--
http://mathr.co.uk
From 16fd46b3abe83dba956b78385d01ad19737b6c76 Mon Sep 17 00:00:00 2001
From: Claude Heiland-Allen cla...@mathr.co.uk
Date: Fri, 9 Aug 2013 14:57:14 +0100
Subject: [PATCH] don't bind abstraction instances to pd-filename
---
src/g_canvas.c | 39 +--
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/src/g_canvas.c b/src/g_canvas.c
index 804ac57..c7a22d6 100644
--- a/src/g_canvas.c
+++ b/src/g_canvas.c
@@ -55,6 +55,9 @@ void canvas_reflecttitle(t_canvas *x);
static void canvas_addtolist(t_canvas *x);
static void canvas_takeofflist(t_canvas *x);
static void canvas_pop(t_canvas *x, t_floatarg fvis);
+static int canvas_should_bind(t_canvas *x);
+static void canvas_bind(t_canvas *x);
+static void canvas_unbind(t_canvas *x);
/* - functions to handle the canvas environment --- */
@@ -205,11 +208,9 @@ void canvas_makefilename(t_canvas *x, char *file, char
*result, int resultsize)
void canvas_rename(t_canvas *x, t_symbol *s, t_symbol *dir)
{
-if (strcmp(x-gl_name-s_name, Pd))
-pd_unbind(x-gl_pd, canvas_makebindsym(x-gl_name));
+canvas_unbind(x);
x-gl_name = s;
-if (strcmp(x-gl_name-s_name, Pd))
-pd_bind(x-gl_pd, canvas_makebindsym(x-gl_name));
+canvas_bind(x);
if (x-gl_havewindow)
canvas_reflecttitle(x);
if (dir dir != s_)
@@ -379,8 +380,7 @@ t_canvas *canvas_new(void *dummy, t_symbol *sel, int
argc, t_atom *argv)
x-gl_owner = owner;
x-gl_name = (*s-s_name ? s :
(canvas_newfilename ? canvas_newfilename : gensym(Pd)));
-
Re: [PD] abstraction penalty benchmarks
On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares). cheers M On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote: On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] eowave ribbon
Hey listers, I've been thinking a lot about the Ondes Martenot and wondering what it would be like to use for MIDI-style control. Have any of you used the Eowave Ribbon controller with Pd? How well does the tactile pad pressure sensor work? I wish for an envelop controller like the Ondes Martenot has. Has anyone seen controllers like this? http://huebnerie.de/blog/wp-content/uploads/2011/01/om5_touche.jpg Samuel Burt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
On 08/09/2013 04:31 PM, Miller Puckette wrote: Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares). What happens to Claude's test if you a) patch Pd to stop binding pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd] inside the abstraction that's getting massively replicated? I'd hypothesize that you end up with the same or closely similar problem, no? If so then messing with the abstraction name binding risks introducing bugs or breaking some strange but interesting patches, and doesn't solve the larger problem which becomes anxiety about [s]/[r] pairs or any other nonlocal connection objects inside abstractions. -Jonathan cheers M On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote: On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
Well, if ia user really wants 32K receives of the same name, (s)he can have them - but most people won't want to do that. In contrast, you can't have 32K copies of an abstraction without hitting this problem - and the business of binding patches to names is only rarely actually used. So (I'm now thinking) Pd should make it easy to defeat that useless behavior. cheers M On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote: On 08/09/2013 04:31 PM, Miller Puckette wrote: Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares). What happens to Claude's test if you a) patch Pd to stop binding pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd] inside the abstraction that's getting massively replicated? I'd hypothesize that you end up with the same or closely similar problem, no? If so then messing with the abstraction name binding risks introducing bugs or breaking some strange but interesting patches, and doesn't solve the larger problem which becomes anxiety about [s]/[r] pairs or any other nonlocal connection objects inside abstractions. -Jonathan cheers M On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote: On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
When and if such patch is implemented please do let us know as I would like to implement it in pd-l2ork as well. Best wishes, Ico On Aug 9, 2013 8:03 PM, Miller Puckette m...@ucsd.edu wrote: Well, if ia user really wants 32K receives of the same name, (s)he can have them - but most people won't want to do that. In contrast, you can't have 32K copies of an abstraction without hitting this problem - and the business of binding patches to names is only rarely actually used. So (I'm now thinking) Pd should make it easy to defeat that useless behavior. cheers M On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote: On 08/09/2013 04:31 PM, Miller Puckette wrote: Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares). What happens to Claude's test if you a) patch Pd to stop binding pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd] inside the abstraction that's getting massively replicated? I'd hypothesize that you end up with the same or closely similar problem, no? If so then messing with the abstraction name binding risks introducing bugs or breaking some strange but interesting patches, and doesn't solve the larger problem which becomes anxiety about [s]/[r] pairs or any other nonlocal connection objects inside abstractions. -Jonathan cheers M On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote: On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
Hi, I looked at accelerating* pd_unbind(), but it seems impossible without breaking binary compatibility somewhere along the line. There's simply no space to store any implementation-private data in objects, as an object is just a pointer to a class. *by making a parallel bindlist per object that points to nodes in a doubly linked bindlist per symbol, so pd_unbind(object, symbol) takes O(symbols per object) instead of O(objects per symbol), with the former number generally much smaller than the latter number (at least in my experience - are there any externals that bind to a large number of symbols? I did write one in Lua, but iirc pdlua uses one proxy object for each binding, so that it can tell which symbol was the target of the message). Claude On 10/08/13 01:06, Ivica Bukvic wrote: When and if such patch is implemented please do let us know as I would like to implement it in pd-l2ork as well. Best wishes, Ico On Aug 9, 2013 8:03 PM, Miller Puckette m...@ucsd.edu wrote: Well, if ia user really wants 32K receives of the same name, (s)he can have them - but most people won't want to do that. In contrast, you can't have 32K copies of an abstraction without hitting this problem - and the business of binding patches to names is only rarely actually used. So (I'm now thinking) Pd should make it easy to defeat that useless behavior. cheers M On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote: On 08/09/2013 04:31 PM, Miller Puckette wrote: Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares). What happens to Claude's test if you a) patch Pd to stop binding pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd] inside the abstraction that's getting massively replicated? I'd hypothesize that you end up with the same or closely similar problem, no? If so then messing with the abstraction name binding risks introducing bugs or breaking some strange but interesting patches, and doesn't solve the larger problem which becomes anxiety about [s]/[r] pairs or any other nonlocal connection objects inside abstractions. -Jonathan cheers M On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote: On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
