Re: [PD] variable receive objects?
- Original Message -
> From: Ivica Ico Bukvic
> To: Miller Puckette
> Cc: pd-list@iem.at
> Sent: Saturday, June 23, 2012 6:36 PM
> Subject: Re: [PD] variable receive objects?
>
>
>
> Miller Puckette wrote:
>
>> Hmm.. I'm still looking for a solution that doesn't require adding
>> extra
>> stuff to bindlist_bang() etc.
>
> In the meantime for those eager to work with dynamic receives, the fix below
> is
> now in the pd-l2otk trunk on the github.
>
> Coming up next in the land o' pd-l2ork, universal presets ;-)
Sounds neat!
-Jonathan
>
> Best wishes,
>
> Ico
>
>>
>> cheers
>> M
>>
>> On Wed, Jun 20, 2012 at 06:09:22PM -0400, Ivica Ico Bukvic wrote:
>>> On 06/20/2012 05:38 PM, Miller Puckette wrote:
>>> >[snip]
>>> >I'm just saying that the automatic varable t_bindelem *e should
> be
>> declared
>>> >at the beginning of the block - no worries about
>> change_bindlist_via_graph.
>>> Ah, now I get it :-). Fixed.
>>> >I think bindlist_bang() etc are more critical than pd_unbind as
> they
>> naturally
>>> >get called many times while a patch is running whereas pd_unbind is
>> typically
>>> >called only when objects are deleted. So moving checks from
>> pd_unbind()
>>> >to bindlist_bang() etc decreases pd's run-time efficiency.
>>> >
>>> >cheers
>>> >M
>>> OK, how about the attached patch where now I use the
>>> change_bindlist_via_graph variable and increment it by one every
>>> time something needs to be unbound so when you return back to the
>>> bindlist_bang() or whatever call was issued, only if
>>> change_bindlist_via_graph > 1 should it call unbind. Now it avoids
>>> entering the bindlist_cleanup unless it absolutely has to...
>>>
>>> Attached is also a patch that illustrates your case presented
>>> earlier which crashed pd-l2ork prior to applying this latest version
>>> of the patch.
>>>
>>> Cheers!
>>>
>>> --
>>> Ivica Ico Bukvic, D.M.A
>>> Composition, Music Technology
>>> Director, DISIS Interactive Sound& Intermedia Studio
>>> Director, L2Ork Linux Laptop Orchestra
>>> Head, ICAT IMPACT Studio
>>> Virginia Tech
>>> Department of Music
>>> Blacksburg, VA 24061-0240
>>> (540) 231-6139
>>> (540) 231-5034 (fax)
>>> disis.music.vt.edu
>>> l2ork.music.vt.edu
>>> ico.bukvic.net
>>>
>>
>>> --- m_pd.c.old 2012-06-20 17:51:43.845040884 -0400
>>> +++ m_pd.c 2012-06-20 18:06:02.047009570 -0400
>>> @@ -146,48 +146,101 @@
>>> t_bindelem *b_list;
>>> } t_bindlist;
>>>
>>> +static int change_bindlist_via_graph = 0;
>>> +
>>> +static void bindlist_cleanup(t_bindlist *x)
>>> +{
>>> + //fprintf(stderr,"bindlist_cleanup\n");
>>> + t_bindelem *e, *e2;
>>> + if (x->b_list->e_who == NULL)
>>> + {
>>> + e = x->b_list;
>>> + x->b_list = e->e_next;
>>> + freebytes(e, sizeof(t_bindelem));
>>> + //fprintf(stderr,"success B1a\n");
>>> + }
>>> + for (e = x->b_list; e2 = e->e_next; e = e2)
>>> + if (e2->e_who == NULL)
>>> + {
>>> + e->e_next = e2->e_next;
>>> + freebytes(e2, sizeof(t_bindelem));
>>> + //fprintf(stderr,"success B1b\n");
>>> + break;
>>> + }
>>> + if (!x->b_list->e_next)
>>> + {
>>> + freebytes(x->b_list, sizeof(t_bindelem));
>>> + pd_free(&x->b_pd);
>>> + //fprintf(stderr,"success B2\n");
>>> + }
>>> +}
>>> +
>>> static void bindlist_bang(t_bindlist *x)
>>> {
>>> t_bindelem *e;
>>> + change_bindlist_via_graph = 1;
>>> for (e = x->b_list; e; e = e->e_next)
>>> - pd_bang(e->e_who);
>>> + if (e->e_who != NULL) pd_bang(e->e_who);
>>> + if (change_bindlist_via_graph > 1)
>>> + bindlist_cleanup(x);
>>> + change_bindlist_via_graph = 0;
>>> }
>>>
>>> static void bindlist_float(t_bindlist *x, t_float f)
>>> {
>>>
Re: [PD] variable receive objects?
Miller Puckette wrote:
>Hmm.. I'm still looking for a solution that doesn't require adding
>extra
>stuff to bindlist_bang() etc.
In the meantime for those eager to work with dynamic receives, the fix below is
now in the pd-l2otk trunk on the github.
Coming up next in the land o' pd-l2ork, universal presets ;-)
Best wishes,
Ico
>
>cheers
>M
>
>On Wed, Jun 20, 2012 at 06:09:22PM -0400, Ivica Ico Bukvic wrote:
>> On 06/20/2012 05:38 PM, Miller Puckette wrote:
>> >[snip]
>> >I'm just saying that the automatic varable t_bindelem *e should be
>declared
>> >at the beginning of the block - no worries about
>change_bindlist_via_graph.
>> Ah, now I get it :-). Fixed.
>> >I think bindlist_bang() etc are more critical than pd_unbind as they
>naturally
>> >get called many times while a patch is running whereas pd_unbind is
>typically
>> >called only when objects are deleted. So moving checks from
>pd_unbind()
>> >to bindlist_bang() etc decreases pd's run-time efficiency.
>> >
>> >cheers
>> >M
>> OK, how about the attached patch where now I use the
>> change_bindlist_via_graph variable and increment it by one every
>> time something needs to be unbound so when you return back to the
>> bindlist_bang() or whatever call was issued, only if
>> change_bindlist_via_graph > 1 should it call unbind. Now it avoids
>> entering the bindlist_cleanup unless it absolutely has to...
>>
>> Attached is also a patch that illustrates your case presented
>> earlier which crashed pd-l2ork prior to applying this latest version
>> of the patch.
>>
>> Cheers!
>>
>> --
>> Ivica Ico Bukvic, D.M.A
>> Composition, Music Technology
>> Director, DISIS Interactive Sound& Intermedia Studio
>> Director, L2Ork Linux Laptop Orchestra
>> Head, ICAT IMPACT Studio
>> Virginia Tech
>> Department of Music
>> Blacksburg, VA 24061-0240
>> (540) 231-6139
>> (540) 231-5034 (fax)
>> disis.music.vt.edu
>> l2ork.music.vt.edu
>> ico.bukvic.net
>>
>
>> --- m_pd.c.old 2012-06-20 17:51:43.845040884 -0400
>> +++ m_pd.c 2012-06-20 18:06:02.047009570 -0400
>> @@ -146,48 +146,101 @@
>> t_bindelem *b_list;
>> } t_bindlist;
>>
>> +static int change_bindlist_via_graph = 0;
>> +
>> +static void bindlist_cleanup(t_bindlist *x)
>> +{
>> +//fprintf(stderr,"bindlist_cleanup\n");
>> +t_bindelem *e, *e2;
>> +if (x->b_list->e_who == NULL)
>> +{
>> +e = x->b_list;
>> +x->b_list = e->e_next;
>> +freebytes(e, sizeof(t_bindelem));
>> +//fprintf(stderr,"success B1a\n");
>> +}
>> +for (e = x->b_list; e2 = e->e_next; e = e2)
>> +if (e2->e_who == NULL)
>> +{
>> +e->e_next = e2->e_next;
>> +freebytes(e2, sizeof(t_bindelem));
>> +//fprintf(stderr,"success B1b\n");
>> +break;
>> +}
>> +if (!x->b_list->e_next)
>> +{
>> +freebytes(x->b_list, sizeof(t_bindelem));
>> +pd_free(&x->b_pd);
>> +//fprintf(stderr,"success B2\n");
>> +}
>> +}
>> +
>> static void bindlist_bang(t_bindlist *x)
>> {
>> t_bindelem *e;
>> +change_bindlist_via_graph = 1;
>> for (e = x->b_list; e; e = e->e_next)
>> -pd_bang(e->e_who);
>> +if (e->e_who != NULL) pd_bang(e->e_who);
>> +if (change_bindlist_via_graph > 1)
>> +bindlist_cleanup(x);
>> +change_bindlist_via_graph = 0;
>> }
>>
>> static void bindlist_float(t_bindlist *x, t_float f)
>> {
>> t_bindelem *e;
>> +change_bindlist_via_graph = 1;
>> for (e = x->b_list; e; e = e->e_next)
>> -pd_float(e->e_who, f);
>> +if (e->e_who != NULL) pd_float(e->e_who, f);
>> +if (change_bindlist_via_graph > 1)
>> +bindlist_cleanup(x);
>> +change_bindlist_via_graph = 0;
>> }
>>
>> static void bindlist_symbol(t_bindlist *x, t_symbol *s)
>> {
>> t_bindelem *e;
>> +change_bindlist_via_graph = 1;
>> for (e = x->b_list; e; e = e->e_next)
>> -pd_symbol(e->e_who, s);
>> +if (e->e_who != NULL) pd_symbol(e->e_who, s);
>> +if (change_bindlist_via_graph > 1)
>> +bindlist_cleanup(x);
>> +change_bindlist_via_graph = 0;
>> }
>>
>> static void bindlist_pointer(t_bindlist *x, t_gpointer *gp)
>> {
>> t_bindelem *e;
>> +change_bindlist_via_graph = 1;
>> for (e = x->b_list; e; e = e->e_next)
>> -pd_pointer(e->e_who, gp);
>> +if (e->e_who != NULL) pd_pointer(e->e_who, gp);
>> +if (change_bindlist_via_graph > 1)
>> +bindlist_cleanup(x);
>> +change_bindlist_via_graph = 0;
>> }
>>
>> static void bindlist_list(t_bindlist *x, t_symbol *s,
>> int argc, t_atom *argv)
>> {
>> t_bindelem *e;
>> +change_bindlist_via_graph = 1;
>> for (e = x->b_list; e; e = e->e_next)
>> -pd_list(e->e_who, s, argc, argv);
>> +if (e->e_who != NULL) pd_list(e->e_who, s, argc, argv);
>> +if (change_bindlist_via_graph > 1)
>> +bindlist_cleanup(x);
>> +change_bindlist_via_graph = 0;
>>
Re: [PD] variable receive objects?
Hmm.. I'm still looking for a solution that doesn't require adding extra
stuff to bindlist_bang() etc.
cheers
M
On Wed, Jun 20, 2012 at 06:09:22PM -0400, Ivica Ico Bukvic wrote:
> On 06/20/2012 05:38 PM, Miller Puckette wrote:
> >[snip]
> >I'm just saying that the automatic varable t_bindelem *e should be declared
> >at the beginning of the block - no worries about change_bindlist_via_graph.
> Ah, now I get it :-). Fixed.
> >I think bindlist_bang() etc are more critical than pd_unbind as they
> >naturally
> >get called many times while a patch is running whereas pd_unbind is typically
> >called only when objects are deleted. So moving checks from pd_unbind()
> >to bindlist_bang() etc decreases pd's run-time efficiency.
> >
> >cheers
> >M
> OK, how about the attached patch where now I use the
> change_bindlist_via_graph variable and increment it by one every
> time something needs to be unbound so when you return back to the
> bindlist_bang() or whatever call was issued, only if
> change_bindlist_via_graph > 1 should it call unbind. Now it avoids
> entering the bindlist_cleanup unless it absolutely has to...
>
> Attached is also a patch that illustrates your case presented
> earlier which crashed pd-l2ork prior to applying this latest version
> of the patch.
>
> Cheers!
>
> --
> Ivica Ico Bukvic, D.M.A
> Composition, Music Technology
> Director, DISIS Interactive Sound& Intermedia Studio
> Director, L2Ork Linux Laptop Orchestra
> Head, ICAT IMPACT Studio
> Virginia Tech
> Department of Music
> Blacksburg, VA 24061-0240
> (540) 231-6139
> (540) 231-5034 (fax)
> disis.music.vt.edu
> l2ork.music.vt.edu
> ico.bukvic.net
>
> --- m_pd.c.old2012-06-20 17:51:43.845040884 -0400
> +++ m_pd.c2012-06-20 18:06:02.047009570 -0400
> @@ -146,48 +146,101 @@
> t_bindelem *b_list;
> } t_bindlist;
>
> +static int change_bindlist_via_graph = 0;
> +
> +static void bindlist_cleanup(t_bindlist *x)
> +{
> + //fprintf(stderr,"bindlist_cleanup\n");
> + t_bindelem *e, *e2;
> +if (x->b_list->e_who == NULL)
> +{
> + e = x->b_list;
> +x->b_list = e->e_next;
> +freebytes(e, sizeof(t_bindelem));
> + //fprintf(stderr,"success B1a\n");
> +}
> +for (e = x->b_list; e2 = e->e_next; e = e2)
> +if (e2->e_who == NULL)
> +{
> +e->e_next = e2->e_next;
> +freebytes(e2, sizeof(t_bindelem));
> + //fprintf(stderr,"success B1b\n");
> +break;
> +}
> +if (!x->b_list->e_next)
> +{
> +freebytes(x->b_list, sizeof(t_bindelem));
> +pd_free(&x->b_pd);
> + //fprintf(stderr,"success B2\n");
> +}
> +}
> +
> static void bindlist_bang(t_bindlist *x)
> {
> t_bindelem *e;
> + change_bindlist_via_graph = 1;
> for (e = x->b_list; e; e = e->e_next)
> -pd_bang(e->e_who);
> +if (e->e_who != NULL) pd_bang(e->e_who);
> + if (change_bindlist_via_graph > 1)
> + bindlist_cleanup(x);
> + change_bindlist_via_graph = 0;
> }
>
> static void bindlist_float(t_bindlist *x, t_float f)
> {
> t_bindelem *e;
> + change_bindlist_via_graph = 1;
> for (e = x->b_list; e; e = e->e_next)
> -pd_float(e->e_who, f);
> +if (e->e_who != NULL) pd_float(e->e_who, f);
> + if (change_bindlist_via_graph > 1)
> + bindlist_cleanup(x);
> + change_bindlist_via_graph = 0;
> }
>
> static void bindlist_symbol(t_bindlist *x, t_symbol *s)
> {
> t_bindelem *e;
> + change_bindlist_via_graph = 1;
> for (e = x->b_list; e; e = e->e_next)
> -pd_symbol(e->e_who, s);
> +if (e->e_who != NULL) pd_symbol(e->e_who, s);
> + if (change_bindlist_via_graph > 1)
> + bindlist_cleanup(x);
> + change_bindlist_via_graph = 0;
> }
>
> static void bindlist_pointer(t_bindlist *x, t_gpointer *gp)
> {
> t_bindelem *e;
> + change_bindlist_via_graph = 1;
> for (e = x->b_list; e; e = e->e_next)
> -pd_pointer(e->e_who, gp);
> +if (e->e_who != NULL) pd_pointer(e->e_who, gp);
> + if (change_bindlist_via_graph > 1)
> + bindlist_cleanup(x);
> + change_bindlist_via_graph = 0;
> }
>
> static void bindlist_list(t_bindlist *x, t_symbol *s,
> int argc, t_atom *argv)
> {
> t_bindelem *e;
> + change_bindlist_via_graph = 1;
> for (e = x->b_list; e; e = e->e_next)
> -pd_list(e->e_who, s, argc, argv);
> +if (e->e_who != NULL) pd_list(e->e_who, s, argc, argv);
> + if (change_bindlist_via_graph > 1)
> + bindlist_cleanup(x);
> + change_bindlist_via_graph = 0;
> }
>
> static void bindlist_anything(t_bindlist *x, t_symbol *s,
> int argc, t_atom *argv)
> {
> t_bindelem *e;
> + change_bindlist_via_graph = 1;
> for (e = x->b_list; e; e = e->e_next)
> -pd_typedmess(e->e_who, s, argc, argv);
> +if (e->e_who != NULL) pd_typedmess(e->e_who, s, argc, argv);
> + if (change
Re: [PD] variable receive objects?
On 06/20/2012 05:38 PM, Miller Puckette wrote:
[snip]
I'm just saying that the automatic varable t_bindelem *e should be declared
at the beginning of the block - no worries about change_bindlist_via_graph.
Ah, now I get it :-). Fixed.
I think bindlist_bang() etc are more critical than pd_unbind as they naturally
get called many times while a patch is running whereas pd_unbind is typically
called only when objects are deleted. So moving checks from pd_unbind()
to bindlist_bang() etc decreases pd's run-time efficiency.
cheers
M
OK, how about the attached patch where now I use the
change_bindlist_via_graph variable and increment it by one every time
something needs to be unbound so when you return back to the
bindlist_bang() or whatever call was issued, only if
change_bindlist_via_graph > 1 should it call unbind. Now it avoids
entering the bindlist_cleanup unless it absolutely has to...
Attached is also a patch that illustrates your case presented earlier
which crashed pd-l2ork prior to applying this latest version of the patch.
Cheers!
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound& Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
--- m_pd.c.old 2012-06-20 17:51:43.845040884 -0400
+++ m_pd.c 2012-06-20 18:06:02.047009570 -0400
@@ -146,48 +146,101 @@
t_bindelem *b_list;
} t_bindlist;
+static int change_bindlist_via_graph = 0;
+
+static void bindlist_cleanup(t_bindlist *x)
+{
+ //fprintf(stderr,"bindlist_cleanup\n");
+ t_bindelem *e, *e2;
+if (x->b_list->e_who == NULL)
+{
+ e = x->b_list;
+x->b_list = e->e_next;
+freebytes(e, sizeof(t_bindelem));
+ //fprintf(stderr,"success B1a\n");
+}
+for (e = x->b_list; e2 = e->e_next; e = e2)
+if (e2->e_who == NULL)
+{
+e->e_next = e2->e_next;
+freebytes(e2, sizeof(t_bindelem));
+ //fprintf(stderr,"success B1b\n");
+break;
+}
+if (!x->b_list->e_next)
+{
+freebytes(x->b_list, sizeof(t_bindelem));
+pd_free(&x->b_pd);
+ //fprintf(stderr,"success B2\n");
+}
+}
+
static void bindlist_bang(t_bindlist *x)
{
t_bindelem *e;
+ change_bindlist_via_graph = 1;
for (e = x->b_list; e; e = e->e_next)
-pd_bang(e->e_who);
+if (e->e_who != NULL) pd_bang(e->e_who);
+ if (change_bindlist_via_graph > 1)
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
static void bindlist_float(t_bindlist *x, t_float f)
{
t_bindelem *e;
+ change_bindlist_via_graph = 1;
for (e = x->b_list; e; e = e->e_next)
-pd_float(e->e_who, f);
+if (e->e_who != NULL) pd_float(e->e_who, f);
+ if (change_bindlist_via_graph > 1)
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
static void bindlist_symbol(t_bindlist *x, t_symbol *s)
{
t_bindelem *e;
+ change_bindlist_via_graph = 1;
for (e = x->b_list; e; e = e->e_next)
-pd_symbol(e->e_who, s);
+if (e->e_who != NULL) pd_symbol(e->e_who, s);
+ if (change_bindlist_via_graph > 1)
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
static void bindlist_pointer(t_bindlist *x, t_gpointer *gp)
{
t_bindelem *e;
+ change_bindlist_via_graph = 1;
for (e = x->b_list; e; e = e->e_next)
-pd_pointer(e->e_who, gp);
+if (e->e_who != NULL) pd_pointer(e->e_who, gp);
+ if (change_bindlist_via_graph > 1)
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
static void bindlist_list(t_bindlist *x, t_symbol *s,
int argc, t_atom *argv)
{
t_bindelem *e;
+ change_bindlist_via_graph = 1;
for (e = x->b_list; e; e = e->e_next)
-pd_list(e->e_who, s, argc, argv);
+if (e->e_who != NULL) pd_list(e->e_who, s, argc, argv);
+ if (change_bindlist_via_graph > 1)
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
static void bindlist_anything(t_bindlist *x, t_symbol *s,
int argc, t_atom *argv)
{
t_bindelem *e;
+ change_bindlist_via_graph = 1;
for (e = x->b_list; e; e = e->e_next)
-pd_typedmess(e->e_who, s, argc, argv);
+if (e->e_who != NULL) pd_typedmess(e->e_who, s, argc, argv);
+ if (change_bindlist_via_graph > 1)
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
void m_pd_setup(void)
@@ -204,6 +257,7 @@
void pd_bind(t_pd *x, t_symbol *s)
{
+ //fprintf(stderr,"pd_bind %s\n", s->s_name);
if (s->s_thing)
{
if (*s->s_thing == bindlist_class)
@@ -217,7 +271,7 @@
}
else
{
- //fprintf(stderr,"pd_unbind
Re: [PD] variable receive objects?
[snip] > >>>Also, there are declarations after functional lines, e.g., > >>> > >>>+ change_bindlist_via_graph = 1; > >>> t_bindelem *e; > >>> > >>>which is not standard C - something I frequently have to clean up in > >>people's > >>>patches :) > >>You mean declaration of a global variable needs to be placed at the top of > >>the source file? Sure, that is an easy fix. It's been placed here in > >>proximity to make the patch more legible. > >> > >It's an automatic variable whose declaration should be at the beginning of a > >block. Otherwise Visual C++ seems to get offended (and I don't find out > >until I crank up my stupid windows machine :) > > But it is declared as a global variable at the beginning of the diff > so it is not an automatic variable that is destroyed after function > exits: > > +static int change_bindlist_via_graph = 0; > + > +static void bindlist_cleanup(t_bindlist *x) > > Are you saying that I need to re-declare it within the function? If > so, that is the first time I would've seen anything like it and it > is something certainly the rest of the Pd code does not conform to, > either (or at least pd-extended). > I'm just saying that the automatic varable t_bindelem *e should be declared at the beginning of the block - no worries about change_bindlist_via_graph. > > > >>>I think something like what you proposed could work; there would still be > >>a > >>>performance hit which I'd probably want to measure before committing to > >>>doing this... since after all we're just talking about a wierd and > >>obnoxious > >>>'feature' > >>>in IEMGUIs that I would simply take out if I could :) > >>I am not so sure there is a performance hit since in both cases > >>dereferencing happens in exactly the same way, except in this one the > >>referencing is delayed and in the interim structs destined to be > >>dereferenced are made to point to null and then skipped if a subsequent call > >>trips over a null-pointing struct before it has been dereferenced. As such > >>its performance impact should be minimal. > >> > >Main performance hit would be that every time anyone traverses a bindlist > >(many send/receive messages, perhaps most) there's all that extra code in > >bindlist_bang(), etc. needed to make the extra tests (possible zero receiver > >and possible cleanup needed afterward). > Clean-up afterward is already implemented and is done within > bindlist_cleanup() call which is nearly identical in terms of its > workload to what was originally placed within pd_unbind, so I > seriously doubt this will make much if any difference. > > What will potentially add a bit of an overhead is the call above > that I forgot to add: > > if (e->e_who != NULL) pd_whatever(e->e_who); > > I honestly have no idea how much a single if statement checking for > a null pointer requires in terms of CPU usage. That said, FWIW I > seriously doubt that this one if would cause that much of cpu > overhead even if executed on a large number of calls. > > I think bindlist_bang() etc are more critical than pd_unbind as they naturally get called many times while a patch is running whereas pd_unbind is typically called only when objects are deleted. So moving checks from pd_unbind() to bindlist_bang() etc decreases pd's run-time efficiency. cheers M ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
On 06/20/2012 01:53 PM, Miller Puckette wrote: Hi Ico and list - On Tue, Jun 19, 2012 at 10:20:07PM -0400, Ivica Ico Bukvic wrote: -Original Message- From: Miller Puckette [mailto:m...@ucsd.edu] Sent: Tuesday, June 19, 2012 5:11 PM To: Ivica Ico Bukvic Cc: 'Claude Heiland-Allen'; Hans-Christoph Steiner; pd-list@iem.at Subject: Re: [PD] variable receive objects? I don't think your patch works in every case (I think you simply have to check every e->e_who inside functions like bindlist_bang() before dereferencing them since someone could clear one of them while inside a previous one). Thanks for the update, Miller. Is there a way you could give me an example patch that would fail this way? I ask this simply because I am unable to imagine one you describe here. Namely, even if a parent's send has been changed by the child-of-a-child object this way, this change would only make specific instance point to null object but its pointer would be still valid until its entire sub-tree has been navigated, and only after its entire sub-tree has been navigated would it be actually dereferencing stuff and fixing the pointers accordingly before the next incoming wave of calls. I don't have an example handy but here's a stack pseudo-trace: ... bindlist_bang() pd_bang(first item in bindlist) ... toggle_receive()<--- zeros out second item in bindlist You're right, there should be one more check before calling pd_bang or pd_whatever simply stating if (e->e_who != NULL) pd_whatever(e->e_who); Beyond that, it should work as only e structs that have been slated for deallocation will have that one set to NULL while still having a valid pointer to the rest of the list so as to avoid the crash. then when pd_bang returns, bindlist_bang proceeds to dereference second item in bindlist and... not bang but more like 'boom'. Also, there are declarations after functional lines, e.g., + change_bindlist_via_graph = 1; t_bindelem *e; which is not standard C - something I frequently have to clean up in people's patches :) You mean declaration of a global variable needs to be placed at the top of the source file? Sure, that is an easy fix. It's been placed here in proximity to make the patch more legible. It's an automatic variable whose declaration should be at the beginning of a block. Otherwise Visual C++ seems to get offended (and I don't find out until I crank up my stupid windows machine :) But it is declared as a global variable at the beginning of the diff so it is not an automatic variable that is destroyed after function exits: +static int change_bindlist_via_graph = 0; + +static void bindlist_cleanup(t_bindlist *x) Are you saying that I need to re-declare it within the function? If so, that is the first time I would've seen anything like it and it is something certainly the rest of the Pd code does not conform to, either (or at least pd-extended). I think something like what you proposed could work; there would still be a performance hit which I'd probably want to measure before committing to doing this... since after all we're just talking about a wierd and obnoxious 'feature' in IEMGUIs that I would simply take out if I could :) I am not so sure there is a performance hit since in both cases dereferencing happens in exactly the same way, except in this one the referencing is delayed and in the interim structs destined to be dereferenced are made to point to null and then skipped if a subsequent call trips over a null-pointing struct before it has been dereferenced. As such its performance impact should be minimal. Main performance hit would be that every time anyone traverses a bindlist (many send/receive messages, perhaps most) there's all that extra code in bindlist_bang(), etc. needed to make the extra tests (possible zero receiver and possible cleanup needed afterward). Clean-up afterward is already implemented and is done within bindlist_cleanup() call which is nearly identical in terms of its workload to what was originally placed within pd_unbind, so I seriously doubt this will make much if any difference. What will potentially add a bit of an overhead is the call above that I forgot to add: if (e->e_who != NULL) pd_whatever(e->e_who); I honestly have no idea how much a single if statement checking for a null pointer requires in terms of CPU usage. That said, FWIW I seriously doubt that this one if would cause that much of cpu overhead even if executed on a large number of calls. cheers M -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net __
Re: [PD] variable receive objects?
Hi Ico and list - On Tue, Jun 19, 2012 at 10:20:07PM -0400, Ivica Ico Bukvic wrote: > > -Original Message- > > From: Miller Puckette [mailto:m...@ucsd.edu] > > Sent: Tuesday, June 19, 2012 5:11 PM > > To: Ivica Ico Bukvic > > Cc: 'Claude Heiland-Allen'; Hans-Christoph Steiner; pd-list@iem.at > > Subject: Re: [PD] variable receive objects? > > > > I don't think your patch works in every case (I think you simply have to > check > > every e->e_who inside functions like bindlist_bang() before dereferencing > > them since someone could clear one of them while inside a previous one). > > Thanks for the update, Miller. Is there a way you could give me an example > patch that would fail this way? I ask this simply because I am unable to > imagine one you describe here. Namely, even if a parent's send has been > changed by the child-of-a-child object this way, this change would only make > specific instance point to null object but its pointer would be still valid > until its entire sub-tree has been navigated, and only after its entire > sub-tree has been navigated would it be actually dereferencing stuff and > fixing the pointers accordingly before the next incoming wave of calls. > I don't have an example handy but here's a stack pseudo-trace: ... bindlist_bang() pd_bang(first item in bindlist) ... toggle_receive() <--- zeros out second item in bindlist then when pd_bang returns, bindlist_bang proceeds to dereference second item in bindlist and... not bang but more like 'boom'. > > > > Also, there are declarations after functional lines, e.g., > > > > + change_bindlist_via_graph = 1; > > t_bindelem *e; > > > > which is not standard C - something I frequently have to clean up in > people's > > patches :) > > You mean declaration of a global variable needs to be placed at the top of > the source file? Sure, that is an easy fix. It's been placed here in > proximity to make the patch more legible. > It's an automatic variable whose declaration should be at the beginning of a block. Otherwise Visual C++ seems to get offended (and I don't find out until I crank up my stupid windows machine :) > > > > I think something like what you proposed could work; there would still be > a > > performance hit which I'd probably want to measure before committing to > > doing this... since after all we're just talking about a wierd and > obnoxious > > 'feature' > > in IEMGUIs that I would simply take out if I could :) > > I am not so sure there is a performance hit since in both cases > dereferencing happens in exactly the same way, except in this one the > referencing is delayed and in the interim structs destined to be > dereferenced are made to point to null and then skipped if a subsequent call > trips over a null-pointing struct before it has been dereferenced. As such > its performance impact should be minimal. > Main performance hit would be that every time anyone traverses a bindlist (many send/receive messages, perhaps most) there's all that extra code in bindlist_bang(), etc. needed to make the extra tests (possible zero receiver and possible cleanup needed afterward). cheers M ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
> -Original Message- > From: Miller Puckette [mailto:m...@ucsd.edu] > Sent: Tuesday, June 19, 2012 5:11 PM > To: Ivica Ico Bukvic > Cc: 'Claude Heiland-Allen'; Hans-Christoph Steiner; pd-list@iem.at > Subject: Re: [PD] variable receive objects? > > I don't think your patch works in every case (I think you simply have to check > every e->e_who inside functions like bindlist_bang() before dereferencing > them since someone could clear one of them while inside a previous one). Thanks for the update, Miller. Is there a way you could give me an example patch that would fail this way? I ask this simply because I am unable to imagine one you describe here. Namely, even if a parent's send has been changed by the child-of-a-child object this way, this change would only make specific instance point to null object but its pointer would be still valid until its entire sub-tree has been navigated, and only after its entire sub-tree has been navigated would it be actually dereferencing stuff and fixing the pointers accordingly before the next incoming wave of calls. > > Also, there are declarations after functional lines, e.g., > > + change_bindlist_via_graph = 1; > t_bindelem *e; > > which is not standard C - something I frequently have to clean up in people's > patches :) You mean declaration of a global variable needs to be placed at the top of the source file? Sure, that is an easy fix. It's been placed here in proximity to make the patch more legible. > > I think something like what you proposed could work; there would still be a > performance hit which I'd probably want to measure before committing to > doing this... since after all we're just talking about a wierd and obnoxious > 'feature' > in IEMGUIs that I would simply take out if I could :) I am not so sure there is a performance hit since in both cases dereferencing happens in exactly the same way, except in this one the referencing is delayed and in the interim structs destined to be dereferenced are made to point to null and then skipped if a subsequent call trips over a null-pointing struct before it has been dereferenced. As such its performance impact should be minimal. Best wishes, Ico > > cheers > Miller > > > > On Wed, May 30, 2012 at 06:12:48PM -0400, Ivica Ico Bukvic wrote: > > In that case, the patch I attached in my previous email should take care of it > with practically no added overhead. > > > > Best wishes, > > > > Ico > > > > Ivica Ico Bukvic, D.M.A > > Composition, Music Technology > > Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork > > Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech > > Department of Music Blacksburg, VA 24061-0240 > > (540) 231-6139 > > (540) 231-5034 (fax) > > disis.music.vt.edu > > l2ork.music.vt.edu > > ico.bukvic.net > > > > Miller Puckette wrote: > > > > I haven't looked at this in detail yet. I don't think there are any > > worries as to teh caveat at the bottim since as far as I know Pd does > > nothing asynchronously except for read/writesf~. > > > > cheers > > Miller > > On Tue, May 29, 2012 at 07:09:28PM -0400, Ivica Ico Bukvic wrote: > > > Has anyone bothered testing this? It works fine over here as far as > > > I can see. Also, Miller, I would greatly appreciate your insight on > > > the potential caveat described below. Namely, is it possible for Pd > > > to execute multiple paths asynchronously (e.g. one part of the graph > > > is executing something and at the same time there is a bang button > > > pressed via GUI--in this situation does the bang trigger second, > > > asynchronous process or is this scheduled after the previous graph call > has completed its navigation?)? > > > > > > NB: patch might require a bit of fuzzy factor since it is based off > > > of the pd-l2ork code base that is slightly different from the > vanilla/extended. > > > > > > Ico > > > > > > > -Original Message- > > > > From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On > > > > Behalf Of Ivica Ico Bukvic > > > > Sent: Monday, May 28, 2012 1:08 AM > > > > To: Claude Heiland-Allen > > > > Cc: pd-list@iem.at > > > > Subject: Re: [PD] variable receive objects? > > > > > > > > On 05/28/2012 12:10 AM, Ivica Ico Bukvic wrote: > > > > > Never mind. Just had a look at pd_bind/unbind code. This makes > > > > > me wonder what if all bindings/unbindings were handled as lists? >
Re: [PD] variable receive objects?
I don't think your patch works in every case (I think you simply have to check every e->e_who inside functions like bindlist_bang() before dereferencing them since someone could clear one of them while inside a previous one). Also, there are declarations after functional lines, e.g., + change_bindlist_via_graph = 1; t_bindelem *e; which is not standard C - something I frequently have to clean up in people's patches :) I think something like what you proposed could work; there would still be a performance hit which I'd probably want to measure before committing to doing this... since after all we're just talking about a wierd and obnoxious 'feature' in IEMGUIs that I would simply take out if I could :) cheers Miller On Wed, May 30, 2012 at 06:12:48PM -0400, Ivica Ico Bukvic wrote: > In that case, the patch I attached in my previous email should take care of > it with practically no added overhead. > > Best wishes, > > Ico > > Ivica Ico Bukvic, D.M.A > Composition, Music Technology > Director, DISIS Interactive Sound & Intermedia Studio > Director, L2Ork Linux Laptop Orchestra > Assistant Director, CCTAD > Virginia Tech > Department of Music > Blacksburg, VA 24061-0240 > (540) 231-6139 > (540) 231-5034 (fax) > disis.music.vt.edu > l2ork.music.vt.edu > ico.bukvic.net > > Miller Puckette wrote: > > I haven't looked at this in detail yet. I don't think there are any worries > as to teh caveat at the bottim since as far as I know Pd does nothing > asynchronously except for read/writesf~. > > cheers > Miller > On Tue, May 29, 2012 at 07:09:28PM -0400, Ivica Ico Bukvic wrote: > > Has anyone bothered testing this? It works fine over here as far as I can > > see. Also, Miller, I would greatly appreciate your insight on the potential > > caveat described below. Namely, is it possible for Pd to execute multiple > > paths asynchronously (e.g. one part of the graph is executing something and > > at the same time there is a bang button pressed via GUI--in this situation > > does the bang trigger second, asynchronous process or is this scheduled > > after the previous graph call has completed its navigation?)? > > > > NB: patch might require a bit of fuzzy factor since it is based off of the > > pd-l2ork code base that is slightly different from the vanilla/extended. > > > > Ico > > > > > -Original Message----- > > > From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of > > > Ivica Ico Bukvic > > > Sent: Monday, May 28, 2012 1:08 AM > > > To: Claude Heiland-Allen > > > Cc: pd-list@iem.at > > > Subject: Re: [PD] variable receive objects? > > > > > > On 05/28/2012 12:10 AM, Ivica Ico Bukvic wrote: > > > > Never mind. Just had a look at pd_bind/unbind code. This makes me > > > > wonder what if all bindings/unbindings were handled as lists? Would > > > > this potentially break anything (other than having to modify > > > > bind/unbind mechanism)? Does anything else depend on 2-member list vs. > > > > 1-member pointer in terms of bindings? I suspect there would be some > > > > cpu impact on having it implemented this way, but not that much. > > > > > > > Actually, please try attached patch. It fixes all such crashes for me on > > pd- > > > l2ork. Basically it has a static variable set within m_pd.c that is turned > > on only > > > when one of bindlist_() functions is called in which case any > > potential > > > memory deallocation calls within pd_unbind are deferred until all members > > > of bindlist->b_list have been served with data. After that > > bindlist_cleanup > > > does its thing based on which members have e_who pointing to NULL and > > > that's that. In the event a call arrives outside those bindlist_() > > > functions, it immediately deallocates stuff as is currently the case with > > pd > > > vanilla and extended. > > > > > > Potential caveat: if one somehow invokes an event outside regular > > execution > > > of the code and it somehow arrives exactly during that narrow span of time > > > when the static var is enabled, its memory deallocation will be ignored. I > > am > > > however unsure if this is theoretically even possible since my > > understanding > > > is that the graph is never being executed out-of-sync. Please correct me > > if I > > > am wrong. > > > > > > Cheers! > > > > > > -- > > > Ivica Ico Bukvic, D.M.A > > > Composition, Music Technology > > > Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork > > Linux > > > Laptop Orchestra Head, ICAT Integrative Performance Studio Virginia Tech > > > Department of Music Blacksburg, VA 24061-0240 > > > (540) 231-6139 > > > (540) 231-5034 (fax) > > > disis.music.vt.edu > > > l2ork.music.vt.edu > > > ico.bukvic.net > > > > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
In that case, the patch I attached in my previous email should take care of it with practically no added overhead. Best wishes, Ico Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Miller Puckette wrote: I haven't looked at this in detail yet. I don't think there are any worries as to teh caveat at the bottim since as far as I know Pd does nothing asynchronously except for read/writesf~. cheers Miller On Tue, May 29, 2012 at 07:09:28PM -0400, Ivica Ico Bukvic wrote: > Has anyone bothered testing this? It works fine over here as far as I can > see. Also, Miller, I would greatly appreciate your insight on the potential > caveat described below. Namely, is it possible for Pd to execute multiple > paths asynchronously (e.g. one part of the graph is executing something and > at the same time there is a bang button pressed via GUI--in this situation > does the bang trigger second, asynchronous process or is this scheduled > after the previous graph call has completed its navigation?)? > > NB: patch might require a bit of fuzzy factor since it is based off of the > pd-l2ork code base that is slightly different from the vanilla/extended. > > Ico > > > -Original Message- > > From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of > > Ivica Ico Bukvic > > Sent: Monday, May 28, 2012 1:08 AM > > To: Claude Heiland-Allen > > Cc: pd-list@iem.at > > Subject: Re: [PD] variable receive objects? > > > > On 05/28/2012 12:10 AM, Ivica Ico Bukvic wrote: > > > Never mind. Just had a look at pd_bind/unbind code. This makes me > > > wonder what if all bindings/unbindings were handled as lists? Would > > > this potentially break anything (other than having to modify > > > bind/unbind mechanism)? Does anything else depend on 2-member list vs. > > > 1-member pointer in terms of bindings? I suspect there would be some > > > cpu impact on having it implemented this way, but not that much. > > > > > Actually, please try attached patch. It fixes all such crashes for me on > pd- > > l2ork. Basically it has a static variable set within m_pd.c that is turned > on only > > when one of bindlist_() functions is called in which case any > potential > > memory deallocation calls within pd_unbind are deferred until all members > > of bindlist->b_list have been served with data. After that > bindlist_cleanup > > does its thing based on which members have e_who pointing to NULL and > > that's that. In the event a call arrives outside those bindlist_() > > functions, it immediately deallocates stuff as is currently the case with > pd > > vanilla and extended. > > > > Potential caveat: if one somehow invokes an event outside regular > execution > > of the code and it somehow arrives exactly during that narrow span of time > > when the static var is enabled, its memory deallocation will be ignored. I > am > > however unsure if this is theoretically even possible since my > understanding > > is that the graph is never being executed out-of-sync. Please correct me > if I > > am wrong. > > > > Cheers! > > > > -- > > Ivica Ico Bukvic, D.M.A > > Composition, Music Technology > > Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork > Linux > > Laptop Orchestra Head, ICAT Integrative Performance Studio Virginia Tech > > Department of Music Blacksburg, VA 24061-0240 > > (540) 231-6139 > > (540) 231-5034 (fax) > > disis.music.vt.edu > > l2ork.music.vt.edu > > ico.bukvic.net > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
I haven't looked at this in detail yet. I don't think there are any worries as to teh caveat at the bottim since as far as I know Pd does nothing asynchronously except for read/writesf~. cheers Miller On Tue, May 29, 2012 at 07:09:28PM -0400, Ivica Ico Bukvic wrote: > Has anyone bothered testing this? It works fine over here as far as I can > see. Also, Miller, I would greatly appreciate your insight on the potential > caveat described below. Namely, is it possible for Pd to execute multiple > paths asynchronously (e.g. one part of the graph is executing something and > at the same time there is a bang button pressed via GUI--in this situation > does the bang trigger second, asynchronous process or is this scheduled > after the previous graph call has completed its navigation?)? > > NB: patch might require a bit of fuzzy factor since it is based off of the > pd-l2ork code base that is slightly different from the vanilla/extended. > > Ico > > > -Original Message- > > From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of > > Ivica Ico Bukvic > > Sent: Monday, May 28, 2012 1:08 AM > > To: Claude Heiland-Allen > > Cc: pd-list@iem.at > > Subject: Re: [PD] variable receive objects? > > > > On 05/28/2012 12:10 AM, Ivica Ico Bukvic wrote: > > > Never mind. Just had a look at pd_bind/unbind code. This makes me > > > wonder what if all bindings/unbindings were handled as lists? Would > > > this potentially break anything (other than having to modify > > > bind/unbind mechanism)? Does anything else depend on 2-member list vs. > > > 1-member pointer in terms of bindings? I suspect there would be some > > > cpu impact on having it implemented this way, but not that much. > > > > > Actually, please try attached patch. It fixes all such crashes for me on > pd- > > l2ork. Basically it has a static variable set within m_pd.c that is turned > on only > > when one of bindlist_() functions is called in which case any > potential > > memory deallocation calls within pd_unbind are deferred until all members > > of bindlist->b_list have been served with data. After that > bindlist_cleanup > > does its thing based on which members have e_who pointing to NULL and > > that's that. In the event a call arrives outside those bindlist_() > > functions, it immediately deallocates stuff as is currently the case with > pd > > vanilla and extended. > > > > Potential caveat: if one somehow invokes an event outside regular > execution > > of the code and it somehow arrives exactly during that narrow span of time > > when the static var is enabled, its memory deallocation will be ignored. I > am > > however unsure if this is theoretically even possible since my > understanding > > is that the graph is never being executed out-of-sync. Please correct me > if I > > am wrong. > > > > Cheers! > > > > -- > > Ivica Ico Bukvic, D.M.A > > Composition, Music Technology > > Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork > Linux > > Laptop Orchestra Head, ICAT Integrative Performance Studio Virginia Tech > > Department of Music Blacksburg, VA 24061-0240 > > (540) 231-6139 > > (540) 231-5034 (fax) > > disis.music.vt.edu > > l2ork.music.vt.edu > > ico.bukvic.net > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
Has anyone bothered testing this? It works fine over here as far as I can see. Also, Miller, I would greatly appreciate your insight on the potential caveat described below. Namely, is it possible for Pd to execute multiple paths asynchronously (e.g. one part of the graph is executing something and at the same time there is a bang button pressed via GUI--in this situation does the bang trigger second, asynchronous process or is this scheduled after the previous graph call has completed its navigation?)? NB: patch might require a bit of fuzzy factor since it is based off of the pd-l2ork code base that is slightly different from the vanilla/extended. Ico > -Original Message- > From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of > Ivica Ico Bukvic > Sent: Monday, May 28, 2012 1:08 AM > To: Claude Heiland-Allen > Cc: pd-list@iem.at > Subject: Re: [PD] variable receive objects? > > On 05/28/2012 12:10 AM, Ivica Ico Bukvic wrote: > > Never mind. Just had a look at pd_bind/unbind code. This makes me > > wonder what if all bindings/unbindings were handled as lists? Would > > this potentially break anything (other than having to modify > > bind/unbind mechanism)? Does anything else depend on 2-member list vs. > > 1-member pointer in terms of bindings? I suspect there would be some > > cpu impact on having it implemented this way, but not that much. > > > Actually, please try attached patch. It fixes all such crashes for me on pd- > l2ork. Basically it has a static variable set within m_pd.c that is turned on only > when one of bindlist_() functions is called in which case any potential > memory deallocation calls within pd_unbind are deferred until all members > of bindlist->b_list have been served with data. After that bindlist_cleanup > does its thing based on which members have e_who pointing to NULL and > that's that. In the event a call arrives outside those bindlist_() > functions, it immediately deallocates stuff as is currently the case with pd > vanilla and extended. > > Potential caveat: if one somehow invokes an event outside regular execution > of the code and it somehow arrives exactly during that narrow span of time > when the static var is enabled, its memory deallocation will be ignored. I am > however unsure if this is theoretically even possible since my understanding > is that the graph is never being executed out-of-sync. Please correct me if I > am wrong. > > Cheers! > > -- > Ivica Ico Bukvic, D.M.A > Composition, Music Technology > Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux > Laptop Orchestra Head, ICAT Integrative Performance Studio Virginia Tech > Department of Music Blacksburg, VA 24061-0240 > (540) 231-6139 > (540) 231-5034 (fax) > disis.music.vt.edu > l2ork.music.vt.edu > ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
- Original Message - > From: Miller Puckette > To: Ivica Ico Bukvic > Cc: "pd-list@iem.at" > Sent: Monday, May 28, 2012 1:13 AM > Subject: Re: [PD] variable receive objects? > > Lots of stuff - grep s_thing *.c :) > > One weak way to proceed might be to maintain a static "count" that > increments anytime anyone unbinds anything in all of Pd and break out > of the loops in bindlist_bang() etc if the number changes. A more > specific but slightly uglier approach would be to maintain such a count > per-symbol. but it seems quite a bit of baggage jus to allow receive to > have that inlet. The main aim in my opinion would be to keep iemguis from being crash-able. -Jonathan > > cheers > Miller > >> Never mind. Just had a look at pd_bind/unbind code. This makes me >> wonder what if all bindings/unbindings were handled as lists? Would >> this potentially break anything (other than having to modify >> bind/unbind mechanism)? Does anything else depend on 2-member list >> vs. 1-member pointer in terms of bindings? I suspect there would be >> some cpu impact on having it implemented this way, but not that >> much. >> >> -- >> Ivica Ico Bukvic, D.M.A >> Composition, Music Technology >> Director, DISIS Interactive Sound& Intermedia Studio >> Director, L2Ork Linux Laptop Orchestra >> Head, ICAT Integrative Performance Studio >> Virginia Tech >> Department of Music >> Blacksburg, VA 24061-0240 >> (540) 231-6139 >> (540) 231-5034 (fax) >> disis.music.vt.edu >> l2ork.music.vt.edu >> ico.bukvic.net >> >> >> ___ >> 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] variable receive objects?
Lots of stuff - grep s_thing *.c :) One weak way to proceed might be to maintain a static "count" that increments anytime anyone unbinds anything in all of Pd and break out of the loops in bindlist_bang() etc if the number changes. A more specific but slightly uglier approach would be to maintain such a count per-symbol. but it seems quite a bit of baggage jus to allow receive to have that inlet. cheers Miller > Never mind. Just had a look at pd_bind/unbind code. This makes me > wonder what if all bindings/unbindings were handled as lists? Would > this potentially break anything (other than having to modify > bind/unbind mechanism)? Does anything else depend on 2-member list > vs. 1-member pointer in terms of bindings? I suspect there would be > some cpu impact on having it implemented this way, but not that > much. > > -- > Ivica Ico Bukvic, D.M.A > Composition, Music Technology > Director, DISIS Interactive Sound& Intermedia Studio > Director, L2Ork Linux Laptop Orchestra > Head, ICAT Integrative Performance Studio > Virginia Tech > Department of Music > Blacksburg, VA 24061-0240 > (540) 231-6139 > (540) 231-5034 (fax) > disis.music.vt.edu > l2ork.music.vt.edu > ico.bukvic.net > > > ___ > 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] variable receive objects?
On 05/28/2012 12:10 AM, Ivica Ico Bukvic wrote:
Never mind. Just had a look at pd_bind/unbind code. This makes me
wonder what if all bindings/unbindings were handled as lists? Would
this potentially break anything (other than having to modify
bind/unbind mechanism)? Does anything else depend on 2-member list vs.
1-member pointer in terms of bindings? I suspect there would be some
cpu impact on having it implemented this way, but not that much.
Actually, please try attached patch. It fixes all such crashes for me on
pd-l2ork. Basically it has a static variable set within m_pd.c that is
turned on only when one of bindlist_() functions is called in which
case any potential memory deallocation calls within pd_unbind are
deferred until all members of bindlist->b_list have been served with
data. After that bindlist_cleanup does its thing based on which members
have e_who pointing to NULL and that's that. In the event a call arrives
outside those bindlist_() functions, it immediately deallocates
stuff as is currently the case with pd vanilla and extended.
Potential caveat: if one somehow invokes an event outside regular
execution of the code and it somehow arrives exactly during that narrow
span of time when the static var is enabled, its memory deallocation
will be ignored. I am however unsure if this is theoretically even
possible since my understanding is that the graph is never being
executed out-of-sync. Please correct me if I am wrong.
Cheers!
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound& Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT Integrative Performance Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
--- m_pd.c.old 2012-05-28 00:55:52.616612895 -0400
+++ m_pd.c.new 2012-05-28 00:58:47.514606515 -0400
@@ -146,48 +146,95 @@
t_bindelem *b_list;
} t_bindlist;
+static int change_bindlist_via_graph = 0;
+
+static void bindlist_cleanup(t_bindlist *x)
+{
+ //fprintf(stderr,"bindlist_cleanup\n");
+ t_bindelem *e, *e2;
+if (x->b_list->e_who == NULL)
+{
+ e = x->b_list;
+x->b_list = e->e_next;
+freebytes(e, sizeof(t_bindelem));
+ //fprintf(stderr,"success B1a\n");
+}
+for (e = x->b_list; e2 = e->e_next; e = e2)
+if (e2->e_who == NULL)
+{
+e->e_next = e2->e_next;
+freebytes(e2, sizeof(t_bindelem));
+ //fprintf(stderr,"success B1b\n");
+break;
+}
+if (!x->b_list->e_next)
+{
+freebytes(x->b_list, sizeof(t_bindelem));
+pd_free(&x->b_pd);
+ //fprintf(stderr,"success B2\n");
+}
+}
+
static void bindlist_bang(t_bindlist *x)
{
+ change_bindlist_via_graph = 1;
t_bindelem *e;
for (e = x->b_list; e; e = e->e_next)
pd_bang(e->e_who);
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
static void bindlist_float(t_bindlist *x, t_float f)
{
+ change_bindlist_via_graph = 1;
t_bindelem *e;
for (e = x->b_list; e; e = e->e_next)
pd_float(e->e_who, f);
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
static void bindlist_symbol(t_bindlist *x, t_symbol *s)
{
+ change_bindlist_via_graph = 1;
t_bindelem *e;
for (e = x->b_list; e; e = e->e_next)
pd_symbol(e->e_who, s);
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
static void bindlist_pointer(t_bindlist *x, t_gpointer *gp)
{
+ change_bindlist_via_graph = 1;
t_bindelem *e;
for (e = x->b_list; e; e = e->e_next)
pd_pointer(e->e_who, gp);
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
static void bindlist_list(t_bindlist *x, t_symbol *s,
int argc, t_atom *argv)
{
+ change_bindlist_via_graph = 1;
t_bindelem *e;
for (e = x->b_list; e; e = e->e_next)
pd_list(e->e_who, s, argc, argv);
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
static void bindlist_anything(t_bindlist *x, t_symbol *s,
int argc, t_atom *argv)
{
+ change_bindlist_via_graph = 1;
t_bindelem *e;
for (e = x->b_list; e; e = e->e_next)
pd_typedmess(e->e_who, s, argc, argv);
+ bindlist_cleanup(x);
+ change_bindlist_via_graph = 0;
}
void m_pd_setup(void)
@@ -247,29 +294,53 @@
goes down to one, get rid of the bindlist and bind the symbol
straight to the remaining element. */
+ /* in pd-l2ork, we however also check whether changes
to the bindlist
+ occur via graph (through code execution, e.g. dynamic
change of receives)
+ and if so, we do not deallocate memory until the entire
bindlist_
+ function is complete with its execution, after whi
Re: [PD] variable receive objects?
On 05/27/2012 05:35 PM, Ivica Ico Bukvic wrote: What if the send/receive property was handled via clock_delay(0); ? If I understand the underlying mechanism correctly, this would put the changing of the receive at the end of the current working queue and/or the beginning of the next one. Either way, the process that had to take place would've either already taken place or would happen after the change was done. Again, all this is assuming I understand how the clock_delay(0); works. This would generate a bit of an out-of-sequence delay (in terms of order of execution), but if that solves the crash, it would be probably a trade-off worth tolerating. Perhaps adding a second outlet that signals that the receive has been reset (e.g. via bang) would allow to sync the rest of the operations... All that said, this is awful close to being a hack rather than a solution. Never mind. Just had a look at pd_bind/unbind code. This makes me wonder what if all bindings/unbindings were handled as lists? Would this potentially break anything (other than having to modify bind/unbind mechanism)? Does anything else depend on 2-member list vs. 1-member pointer in terms of bindings? I suspect there would be some cpu impact on having it implemented this way, but not that much. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT Integrative Performance Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
On 05/18/2012 07:08 AM, Claude Heiland-Allen wrote: On 14/05/12 19:43, Jonathan Wilkes wrote: How do I manifest the bug? See attached. Uses iem_r, though it should make no difference which settable-receive you use. WARNING: clicking the "boom" message makes Pd segfault :WARNING To understand this you need to know that pd stores a receiver in the symbol table. When there is only one receiver, it's just a pointer to the object, but when there's more than one there's a proxy object that contains a list. When you change a receiver it can end up deleting the proxy object if the receiver count for a symbol drops from 2 to 1. Deleting an object while code is executing in its context -> boom. Claude What if the send/receive property was handled via clock_delay(0); ? If I understand the underlying mechanism correctly, this would put the changing of the receive at the end of the current working queue and/or the beginning of the next one. Either way, the process that had to take place would've either already taken place or would happen after the change was done. Again, all this is assuming I understand how the clock_delay(0); works. This would generate a bit of an out-of-sequence delay (in terms of order of execution), but if that solves the crash, it would be probably a trade-off worth tolerating. Perhaps adding a second outlet that signals that the receive has been reset (e.g. via bang) would allow to sync the rest of the operations... All that said, this is awful close to being a hack rather than a solution. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT Integrative Performance Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
- Original Message - > From: Miller Puckette > To: Jonathan Wilkes > Cc: Claude Heiland-Allen ; "pd-list@iem.at" > > Sent: Friday, May 18, 2012 12:06 PM > Subject: Re: [PD] variable receive objects? > > I didn't realize this until reading about it in this thread - I don't > know what > to do about it either; it's been there for years, probably since I added the > IEM guis to Pd (2000 or so?) Yep. And for people who send 'receive' messages to iemguis in complex patches, it could be quite a doozy, as the problem doesn't manifest until you get more than one object using that receive-symbol. (Well, at least I couldn't get it to crash with just one object...) > > There's no good way to fix it and it can't be taken out compatibly - > perhaps > it should just print a warning now. > > cheers > Miller > > On Fri, May 18, 2012 at 08:40:54AM -0700, Jonathan Wilkes wrote: >> - Original Message - >> >> > From: Claude Heiland-Allen >> > To: pd-list@iem.at >> > Cc: >> > Sent: Friday, May 18, 2012 7:08 AM >> > Subject: Re: [PD] variable receive objects? >> > >> > On 14/05/12 19:43, Jonathan Wilkes wrote: >> >>> From: IOhannes m zmoelnig >> >>> On 2012-05-14 05:02, John Harrison wrote: >> >>>> I've used those 2 objects a lot and thought they > seemed >> > pretty >> >>>> stable... >> >>> >> >>> that's because the "trivial" case (where > receiving data >> > and >> >>> changing >> >>> the receive label are completely independent of each other >> >>> (stackwise)) won't create much of a problem. >> >> >> >> How do I manifest the bug? >> > >> > See attached. Uses iem_r, though it should make no difference which >> > settable-receive you use. >> > >> > WARNING: clicking the "boom" message makes Pd segfault > :WARNING >> > >> > To understand this you need to know that pd stores a receiver in the > symbol >> > table. When there is only one receiver, it's just a pointer to > the object, >> > but when there's more than one there's a proxy object that > contains a >> > list. When you change a receiver it can end up deleting the proxy > object if the >> > receiver count for a symbol drops from 2 to 1. Deleting an object > while code is >> > executing in its context -> boom. >> >> Thanks, Claude. >> >> I just want to point out that this affects every iemgui as well. >> >> > >> > >> > Claude >> > >> > ___ >> > 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] variable receive objects?
I didn't realize this until reading about it in this thread - I don't know what to do about it either; it's been there for years, probably since I added the IEM guis to Pd (2000 or so?) There's no good way to fix it and it can't be taken out compatibly - perhaps it should just print a warning now. cheers Miller On Fri, May 18, 2012 at 08:40:54AM -0700, Jonathan Wilkes wrote: > - Original Message - > > > From: Claude Heiland-Allen > > To: pd-list@iem.at > > Cc: > > Sent: Friday, May 18, 2012 7:08 AM > > Subject: Re: [PD] variable receive objects? > > > > On 14/05/12 19:43, Jonathan Wilkes wrote: > >>> From: IOhannes m zmoelnig > >>> On 2012-05-14 05:02, John Harrison wrote: > >>>> I've used those 2 objects a lot and thought they seemed > > pretty > >>>> stable... > >>> > >>> that's because the "trivial" case (where receiving data > > and > >>> changing > >>> the receive label are completely independent of each other > >>> (stackwise)) won't create much of a problem. > >> > >> How do I manifest the bug? > > > > See attached. Uses iem_r, though it should make no difference which > > settable-receive you use. > > > > WARNING: clicking the "boom" message makes Pd segfault :WARNING > > > > To understand this you need to know that pd stores a receiver in the symbol > > table. When there is only one receiver, it's just a pointer to the object, > > but when there's more than one there's a proxy object that contains a > > list. When you change a receiver it can end up deleting the proxy object > > if the > > receiver count for a symbol drops from 2 to 1. Deleting an object while > > code is > > executing in its context -> boom. > > Thanks, Claude. > > I just want to point out that this affects every iemgui as well. > > > > > > > Claude > > > > ___ > > 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] variable receive objects?
- Original Message - > From: Claude Heiland-Allen > To: pd-list@iem.at > Cc: > Sent: Friday, May 18, 2012 7:08 AM > Subject: Re: [PD] variable receive objects? > > On 14/05/12 19:43, Jonathan Wilkes wrote: >>> From: IOhannes m zmoelnig >>> On 2012-05-14 05:02, John Harrison wrote: >>>> I've used those 2 objects a lot and thought they seemed > pretty >>>> stable... >>> >>> that's because the "trivial" case (where receiving data > and >>> changing >>> the receive label are completely independent of each other >>> (stackwise)) won't create much of a problem. >> >> How do I manifest the bug? > > See attached. Uses iem_r, though it should make no difference which > settable-receive you use. > > WARNING: clicking the "boom" message makes Pd segfault :WARNING > > To understand this you need to know that pd stores a receiver in the symbol > table. When there is only one receiver, it's just a pointer to the object, > but when there's more than one there's a proxy object that contains a > list. When you change a receiver it can end up deleting the proxy object if > the > receiver count for a symbol drops from 2 to 1. Deleting an object while code > is > executing in its context -> boom. Thanks, Claude. I just want to point out that this affects every iemgui as well. > > > Claude > > ___ > 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] variable receive objects?
On 14/05/12 19:43, Jonathan Wilkes wrote: From: IOhannes m zmoelnig On 2012-05-14 05:02, John Harrison wrote: I've used those 2 objects a lot and thought they seemed pretty stable... that's because the "trivial" case (where receiving data and changing the receive label are completely independent of each other (stackwise)) won't create much of a problem. How do I manifest the bug? See attached. Uses iem_r, though it should make no difference which settable-receive you use. WARNING: clicking the "boom" message makes Pd segfault :WARNING To understand this you need to know that pd stores a receiver in the symbol table. When there is only one receiver, it's just a pointer to the object, but when there's more than one there's a proxy object that contains a list. When you change a receiver it can end up deleting the proxy object if the receiver count for a symbol drops from 2 to 1. Deleting an object while code is executing in its context -> boom. Claude #N canvas 0 0 450 300 10; #X obj 30 64 iem_r foo; #X obj 164 62 iem_r foo; #X msg 75 89 set bar; #X msg 208 89 set bar; #X msg 87 133 boom; #X obj 87 154 s foo; #X connect 0 0 2 0; #X connect 1 0 3 0; #X connect 2 0 0 0; #X connect 3 0 1 0; #X connect 4 0 5 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
- Original Message - > From: IOhannes m zmoelnig > To: pd-list@iem.at > Cc: > Sent: Monday, May 14, 2012 3:42 AM > Subject: Re: [PD] variable receive objects? > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2012-05-14 05:02, John Harrison wrote: >> I thought [send13] and [receive13] from the ext13 library were for >> settable send and receive? Or am I misunderstanding the question? > > for settable send i would _highly_ recommend to use the built-in [send]. > whether you use [iem_r] or [receive13] is probably only a matter of > taste (but i think that most of ext13's objects are not so important > nowadays; and d13b is not so active in Pd land any more) > >> >> I've used those 2 objects a lot and thought they seemed pretty >> stable... >> > > that's because the "trivial" case (where receiving data and > changing > the receive label are completely independent of each other > (stackwise)) won't create much of a problem. Well, with [iem_r foo] I tried recursion while changing the rcv-symbol at various points, sending multiple messages with a [; foo set bar] nested in the middle, and making two [iem_r] objects and having the first one that receives a message trigger a [set bar( to the 2nd one _before_ the 2nd one receives its message. None of these trigger a crash. How do I manifest the bug? -Jonathan > > it's easy to implement a feature and suddenly end up with a bug. it's > even common. both [recevie13] and [iem_receive] have probably gone > this route. > however, it's incredibly harder to implement a feature where you know > beforehand that you will open a can of worms and you don't know yet > how to close it (properly). that's the route [r] has gone. > > fgmasdr > IOhannes > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk+wt1AACgkQkX2Xpv6ydvT2LACg5wh3vPHkGrtpNDHGs71QJHb6 > 84IAoNn0OViWhBvmjEof24UTJPWmcfnp > =pvRn > -END PGP SIGNATURE- > > > ___ > 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] variable receive objects?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-05-14 05:02, John Harrison wrote: > I thought [send13] and [receive13] from the ext13 library were for > settable send and receive? Or am I misunderstanding the question? for settable send i would _highly_ recommend to use the built-in [send]. whether you use [iem_r] or [receive13] is probably only a matter of taste (but i think that most of ext13's objects are not so important nowadays; and d13b is not so active in Pd land any more) > > I've used those 2 objects a lot and thought they seemed pretty > stable... > that's because the "trivial" case (where receiving data and changing the receive label are completely independent of each other (stackwise)) won't create much of a problem. it's easy to implement a feature and suddenly end up with a bug. it's even common. both [recevie13] and [iem_receive] have probably gone this route. however, it's incredibly harder to implement a feature where you know beforehand that you will open a can of worms and you don't know yet how to close it (properly). that's the route [r] has gone. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+wt1AACgkQkX2Xpv6ydvT2LACg5wh3vPHkGrtpNDHGs71QJHb6 84IAoNn0OViWhBvmjEof24UTJPWmcfnp =pvRn -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
I thought [send13] and [receive13] from the ext13 library were for settable send and receive? Or am I misunderstanding the question? I've used those 2 objects a lot and thought they seemed pretty stable... -John On Sun, May 13, 2012 at 11:29 AM, Jonathan Wilkes wrote: > Does anyone have a demo crasher, with iem_receive, [r~], or of any of the > iemguis (which of course have settable receives as well)? > > It's not immediately apparent how to change a receive symbol while a > message is "currently passing through the receive object". I though Pd was > supposed to be deterministic. > > > -Jonathan > > > > - Original Message - > > From: Miller Puckette > > To: Jonathan Wilkes > > Cc: IOhannes m zmölnig ; "pd-list@iem.at" < > pd-list@iem.at> > > Sent: Sunday, May 13, 2012 11:42 AM > > Subject: Re: [PD] variable receive objects? > > > > Hi all - > > > > If you make a settable 'receive' and then change the setting in a > > context > > in which a message is currently passing through the receive object (not > > at all an unlikely thing to have happen) it will crash Pd. There are > ways > > around this but I don't know of any that would not slow down the global > > functioning of Pd itself. > > > > cheers > > Miller > > > > On Sun, May 13, 2012 at 07:07:28AM -0700, Jonathan Wilkes wrote: > >> > >> > >> > >> > >> - Original Message - > >> > From: IOhannes m zmölnig > >> > To: pd-list@iem.at > >> > Cc: > >> > Sent: Sunday, May 13, 2012 4:03 AM > >> > Subject: Re: [PD] variable receive objects? > >> > > >> > On 05/12/2012 07:58 PM, Jonathan Wilkes wrote: > >> >> - Original Message - > >> >> > >> >>> From: Marian Weger > >> >>> To: pd-list@iem.at > >> >>> Cc: > >> >>> Sent: Saturday, May 12, 2012 8:09 AM > >> >>> Subject: Re: [PD] variable receive objects? > >> >>> > >> >>> hi! > >> >>> > >> >>>>is there a way to generate a variable receive object > > similar to a > >> > send via > >> >>> message box, whose source is defined at load time? > >> >>> > >> >>> use iem_receive / iem_r from iemlib. > >> >> > >> >> Wow, that is classic Pd development style-- add a tiny feature to > > an > >> >> object, but don't actually improve _that_ object. > >> > > >> > ever thought that there might be a good reason why [r] is not > > seettable, > >> > and that [iem_r] - while superficially working - exposes exactly the > >> > problems of a settable [r]? > >> > >> Enlighten me. > >> > >> > > >> > mfgadsr > >> > IOhannes > >> > > >> > PS: there should be a discussion on this topic in the archives. > >> > >> I don't find anything of the sort. Tried searching for "settable > > receive", "setting receive", > >> and "iem_receive" > >> > >> -Jonathan > >> > >> > > >> > ___ > >> > 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] variable receive objects?
Does anyone have a demo crasher, with iem_receive, [r~], or of any of the iemguis (which of course have settable receives as well)? It's not immediately apparent how to change a receive symbol while a message is "currently passing through the receive object". I though Pd was supposed to be deterministic. -Jonathan - Original Message - > From: Miller Puckette > To: Jonathan Wilkes > Cc: IOhannes m zmölnig ; "pd-list@iem.at" > Sent: Sunday, May 13, 2012 11:42 AM > Subject: Re: [PD] variable receive objects? > > Hi all - > > If you make a settable 'receive' and then change the setting in a > context > in which a message is currently passing through the receive object (not > at all an unlikely thing to have happen) it will crash Pd. There are ways > around this but I don't know of any that would not slow down the global > functioning of Pd itself. > > cheers > Miller > > On Sun, May 13, 2012 at 07:07:28AM -0700, Jonathan Wilkes wrote: >> >> >> >> >> - Original Message - >> > From: IOhannes m zmölnig >> > To: pd-list@iem.at >> > Cc: >> > Sent: Sunday, May 13, 2012 4:03 AM >> > Subject: Re: [PD] variable receive objects? >> > >> > On 05/12/2012 07:58 PM, Jonathan Wilkes wrote: >> >> - Original Message - >> >> >> >>> From: Marian Weger >> >>> To: pd-list@iem.at >> >>> Cc: >> >>> Sent: Saturday, May 12, 2012 8:09 AM >> >>> Subject: Re: [PD] variable receive objects? >> >>> >> >>> hi! >> >>> >> >>>> is there a way to generate a variable receive object > similar to a >> > send via >> >>> message box, whose source is defined at load time? >> >>> >> >>> use iem_receive / iem_r from iemlib. >> >> >> >> Wow, that is classic Pd development style-- add a tiny feature to > an >> >> object, but don't actually improve _that_ object. >> > >> > ever thought that there might be a good reason why [r] is not > seettable, >> > and that [iem_r] - while superficially working - exposes exactly the >> > problems of a settable [r]? >> >> Enlighten me. >> >> > >> > mfgadsr >> > IOhannes >> > >> > PS: there should be a discussion on this topic in the archives. >> >> I don't find anything of the sort. Tried searching for "settable > receive", "setting receive", >> and "iem_receive" >> >> -Jonathan >> >> > >> > ___ >> > 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] variable receive objects?
Hi all - If you make a settable 'receive' and then change the setting in a context in which a message is currently passing through the receive object (not at all an unlikely thing to have happen) it will crash Pd. There are ways around this but I don't know of any that would not slow down the global functioning of Pd itself. cheers Miller On Sun, May 13, 2012 at 07:07:28AM -0700, Jonathan Wilkes wrote: > > > > > - Original Message - > > From: IOhannes m zmölnig > > To: pd-list@iem.at > > Cc: > > Sent: Sunday, May 13, 2012 4:03 AM > > Subject: Re: [PD] variable receive objects? > > > > On 05/12/2012 07:58 PM, Jonathan Wilkes wrote: > >> - Original Message - > >> > >>> From: Marian Weger > >>> To: pd-list@iem.at > >>> Cc: > >>> Sent: Saturday, May 12, 2012 8:09 AM > >>> Subject: Re: [PD] variable receive objects? > >>> > >>> hi! > >>> > >>>> is there a way to generate a variable receive object similar to a > > send via > >>> message box, whose source is defined at load time? > >>> > >>> use iem_receive / iem_r from iemlib. > >> > >> Wow, that is classic Pd development style-- add a tiny feature to an > >> object, but don't actually improve _that_ object. > > > > ever thought that there might be a good reason why [r] is not seettable, > > and that [iem_r] - while superficially working - exposes exactly the > > problems of a settable [r]? > > Enlighten me. > > > > > mfgadsr > > IOhannes > > > > PS: there should be a discussion on this topic in the archives. > > I don't find anything of the sort. Tried searching for "settable receive", > "setting receive", > and "iem_receive" > > -Jonathan > > > > > ___ > > 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] variable receive objects?
- Original Message - > From: IOhannes m zmölnig > To: pd-list@iem.at > Cc: > Sent: Sunday, May 13, 2012 4:03 AM > Subject: Re: [PD] variable receive objects? > > On 05/12/2012 07:58 PM, Jonathan Wilkes wrote: >> - Original Message - >> >>> From: Marian Weger >>> To: pd-list@iem.at >>> Cc: >>> Sent: Saturday, May 12, 2012 8:09 AM >>> Subject: Re: [PD] variable receive objects? >>> >>> hi! >>> >>>> is there a way to generate a variable receive object similar to a > send via >>> message box, whose source is defined at load time? >>> >>> use iem_receive / iem_r from iemlib. >> >> Wow, that is classic Pd development style-- add a tiny feature to an >> object, but don't actually improve _that_ object. > > ever thought that there might be a good reason why [r] is not seettable, > and that [iem_r] - while superficially working - exposes exactly the > problems of a settable [r]? Enlighten me. > > mfgadsr > IOhannes > > PS: there should be a discussion on this topic in the archives. I don't find anything of the sort. Tried searching for "settable receive", "setting receive", and "iem_receive" -Jonathan > > ___ > 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] variable receive objects?
On 05/12/2012 07:58 PM, Jonathan Wilkes wrote: - Original Message - From: Marian Weger To: pd-list@iem.at Cc: Sent: Saturday, May 12, 2012 8:09 AM Subject: Re: [PD] variable receive objects? hi! is there a way to generate a variable receive object similar to a send via message box, whose source is defined at load time? use iem_receive / iem_r from iemlib. Wow, that is classic Pd development style-- add a tiny feature to an object, but don't actually improve _that_ object. ever thought that there might be a good reason why [r] is not seettable, and that [iem_r] - while superficially working - exposes exactly the problems of a settable [r]? mfgadsr IOhannes PS: there should be a discussion on this topic in the archives. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
- Original Message - > From: yvan volochine > To: pd-list > Cc: > Sent: Saturday, May 12, 2012 8:17 PM > Subject: Re: [PD] variable receive objects? > > On 05/12/2012 10:29 PM, Jonathan Wilkes wrote: >> However, there comes a point when making a serious user interface that >> wires start to get in the way, esp. on some of the more complex interfaces > people >> have made in Pd for sequencing, real-time performance, etc. I'd say at > the level >> where the author is designing for user's who don't necessarily need > to know the ins >> and outs of Pd's dataflow paradigm, wires become a hindrance. >> >> Of course that doesn't mean one can't do normal Pd patching using > only GUI objects. > > just to add my 2 cents.. > if a patch needs a GUI, I really like when its top-level canvas contain only > the > GUI and only patchers (read: *no wires* when opening the patch) > > using GUI send|receive instead of wires is a very good idea. > it also encourage putting things where they should be, i.e. separate the > logic > from the GUI (à la maxmsp 'presentation mode'). > > then somewhere in your subpatches: > [s GUI-to-vol] [r GUI-from-vol] [s GUI-to-mute] etc.. > > much cleaner IMHO > > or even better, only: > [pd init] > [pd audio] > [pd GUI] > on the top-level and some key triggers opening [pd GUI] > > BTW I'd _love_ to be able to do that: > [hslider sendSymbol receiveSymbol] Supercollider-style any-order keyword args would be nice. -Jonathan > > now that would save some time :) > > cheers, > y > > -- > yvan.voloch...@gmail.com > http://yvanvolochine.com > > ___ > 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] variable receive objects?
On 05/12/2012 10:29 PM, Jonathan Wilkes wrote: However, there comes a point when making a serious user interface that wires start to get in the way, esp. on some of the more complex interfaces people have made in Pd for sequencing, real-time performance, etc. I'd say at the level where the author is designing for user's who don't necessarily need to know the ins and outs of Pd's dataflow paradigm, wires become a hindrance. Of course that doesn't mean one can't do normal Pd patching using only GUI objects. just to add my 2 cents.. if a patch needs a GUI, I really like when its top-level canvas contain only the GUI and only patchers (read: *no wires* when opening the patch) using GUI send|receive instead of wires is a very good idea. it also encourage putting things where they should be, i.e. separate the logic from the GUI (à la maxmsp 'presentation mode'). then somewhere in your subpatches: [s GUI-to-vol] [r GUI-from-vol] [s GUI-to-mute] etc.. much cleaner IMHO or even better, only: [pd init] [pd audio] [pd GUI] on the top-level and some key triggers opening [pd GUI] BTW I'd _love_ to be able to do that: [hslider sendSymbol receiveSymbol] now that would save some time :) cheers, y -- yvan.voloch...@gmail.com http://yvanvolochine.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
- Original Message - > From: Frank Barknecht > To: pd-list@iem.at > Cc: > Sent: Saturday, May 12, 2012 2:23 PM > Subject: Re: [PD] variable receive objects? > > Hi Jörn, > > On Sat, May 12, 2012 at 01:20:45PM +0200, Jörn Nettingsmeier wrote: >> is there a way to generate a variable receive object similar to a send >> via message box, whose source is defined at load time? > > Attached is a common idiom that can be used in this kind of situation. It > basically works by using one single global send/receive name for everything, > thereby reducing the risk of nameclashes. That actually increases the risk of name clashes, as any other set of abstractions using this common idiom will leak data to the other set. > You could pass $0 as argument to both > abstraction to make it a bit local or better yet: Use [inlet]s to make it as > local as it gets in Pd. Inlets rock! I agree about the inlets. I find that people are too quick to make a lot of things nonlocal when they start working with gop gui abstractions. However, there comes a point when making a serious user interface that wires start to get in the way, esp. on some of the more complex interfaces people have made in Pd for sequencing, real-time performance, etc. I'd say at the level where the author is designing for user's who don't necessarily need to know the ins and outs of Pd's dataflow paradigm, wires become a hindrance. Of course that doesn't mean one can't do normal Pd patching using only GUI objects. I think Ivica is doing this with a special version of Pd with a limited set of user-friendly GUI objects-- there, it's still important to use wires to show the path the signal takes. (Just like in a DAW the user wants to know the order in which the signal gets processed by a series of filters.) -Jonathan > > Then each message you pass along gets prefixed by a certain tag (a number > "id" > in the example) in the sender and routed accordingly at the receive side. > This basically moves the actual receive name into the message you send. > > The example requires Pd 0.43 with settable [route] objects, but it's > possible > to clone a settable route with [select], check out the sroute.pd example in > the > [list]-abs collection. > > Ciao > -- > Frank Barknecht Do You RjDj.me? _ __footils.org__ > > ___ > 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] variable receive objects?
Hi Jörn, On Sat, May 12, 2012 at 01:20:45PM +0200, Jörn Nettingsmeier wrote: > is there a way to generate a variable receive object similar to a send > via message box, whose source is defined at load time? Attached is a common idiom that can be used in this kind of situation. It basically works by using one single global send/receive name for everything, thereby reducing the risk of nameclashes. You could pass $0 as argument to both abstraction to make it a bit local or better yet: Use [inlet]s to make it as local as it gets in Pd. Inlets rock! Then each message you pass along gets prefixed by a certain tag (a number "id" in the example) in the sender and routed accordingly at the receive side. This basically moves the actual receive name into the message you send. The example requires Pd 0.43 with settable [route] objects, but it's possible to clone a settable route with [select], check out the sroute.pd example in the [list]-abs collection. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ rs-set.pd Description: application/puredata r-set.pd Description: application/puredata s-set.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
- Original Message - > From: Claude Heiland-Allen > To: pd-list@iem.at > Cc: > Sent: Saturday, May 12, 2012 8:16 AM > Subject: Re: [PD] variable receive objects? > > On 12/05/12 12:20, Jörn Nettingsmeier wrote: > [snip] >> is there a way to generate a variable receive object similar to a send >> via message box, whose source is defined at load time? > [snip] >> or maybe i'm totally up the wrong alley, and someone can suggest a more >> idiomatic way to deal with this issue? > > I think more idiomatic is identifier flow from outside in (rather than trying > to > get the insides out). > > Use $1 in the player and the controller, instead of their own local $0. > > Pass the same value in as the player and controller(s) arguments. > > Possibly passing in something based on the local $0 of their common parent > patch > if they have one, otherwise pick a magic name that is hopefully unique enough. > > I find it quite common to add layers of $ when nesting abstractions, perhaps > with a pattern similar to: > #1 Quick: Someone other than Claude: how long does it take you to figure out what gets printed? > patch: [nbx]--[s $0-r] [foo $0] [r $0-s]--[print] > foo: [r $1-r]--[s $0-$1-r] [bar $0-$1] [r $0-$1-s]--[s $1-s] > bar: [r $1-r]--[s $0-$1-r] [baz $0-$1] [r $0-$1-s]--[s $1-s] > baz: [r $1-r]--[+ 1]--[s $1-s] Note: my [to]/[from] wrappers take a numeric arg to specify parent level. #2 Quick: Someone other than me: how long does it take you to figure out what gets printed? patch: [nbx]--[to r] [foo] [from s]--[print] foo: [bar] bar: [baz] baz: [from r 3]-[+ 1]--[to s 3] -Jonathan > > > Claude > > ___ > 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] variable receive objects?
- Original Message - > From: Marian Weger > To: pd-list@iem.at > Cc: > Sent: Saturday, May 12, 2012 8:09 AM > Subject: Re: [PD] variable receive objects? > > hi! > >> is there a way to generate a variable receive object similar to a send via > message box, whose source is defined at load time? > > use iem_receive / iem_r from iemlib. Wow, that is classic Pd development style-- add a tiny feature to an object, but don't actually improve _that_ object. No, rewrite the entire class, prefix the original class name with something else, and add it to the growing pile of externals that duplicate the function of an internal while adding a tiny feature. I'm not making fun of that decision-- I've certainly used that method to improve the help docs. It's just such a huge waste of time and effort-- I bet Pd-extended includes within itself at least 3 forks of Pd. -Jonathan > > cheers, > marian > > ___ > 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] variable receive objects?
- Original Message - > From: Jörn Nettingsmeier > To: pd-list@iem.at > Cc: > Sent: Saturday, May 12, 2012 7:20 AM > Subject: [PD] variable receive objects? > > hi *! > > > i'm playing around with a theatre cue player written around readanysf, which > i will post on the web as soon as i'm sure it's not going to be too > embarrassing - need to pick up some more pd idioms first... > > > so far, i've been able to create a nice gui using graph-on-parent, and all > gui events are messages sent to receive objects, internally. for instance, > hitting the "play" bang button will send the bang to > cfPlayer$0SetPlay. > > the idea is that everybody can grab this event, not just the readanysf~ > object. > > now i've painted myself into a corner: i want to create a midi controller > abstraction which is separate from the player and gui. > > to that end, i have added an outlet to my player that contains the player's > unique id $0. this outlet is connected to the controller object, which can > now > happily send messages back to the player, using message boxes: > > |inlet| <-- gets the parent player's $0 ID > |set $1( > | ( > |; cfPlayer$1SetPlay bang( > > that gives me nice separation. the problem is that i want the controller > object > to be able to _listen_ to player events as well as generate them, so that the > midi controller always reflects the current state, even if it was initiated > elsewhere, such as via the gui or by loading a playlist item. > > is there a way to generate a variable receive object similar to a send via > message box, whose source is defined at load time? > something like this: > |inlet| <-- gets the parent player's $0 ID > |set $1( > | ( > |receive cfPlayer$1GetPlay( [inlet] | [list append $0 | [clear, obj 20 20 receive cfPlayer$1GetPlay, obj 20 80 send $2-out, connect 0 0 1 0( | [s pd-$0-dynamic-subpatch] [pd $0-dynamic-subpatch] [r $0-out] | [outlet] <-- all messages to cfPlayer$1GetPlay will go here > > which, of course, doesn't work. > > > or maybe i'm totally up the wrong alley, and someone can suggest a more > idiomatic way to deal with this issue? There isn't because Pd sucks at specifying scope for the symbol name associated with an object. Thus you are sending messages through wires so that your abstractions can build their own notion of "library" level scope. I made a source code patch that would make stuff like this easier. Instead of passing around $0 among the abstractions of a library, I made a [to]/[from] wrapper around [s]/[r] that takes an additional argument to specify the scope. I'm still figuring out what the best interface is, but for the purposes of this thread let's say "library" scope is specified by adding the argument "mylib" after the send name. This scope is shared among all the abstractions that are located in the same directory. That means you can just do this: | [to GetPlay mylib] The [to] object does this: 1. prefixes "GetPlay" with the path of the abstraction's directory (using my patch to the source) 2. possibly prefixes that with "__" or something (not sure if that's necessary) 3. sets an internal [s] object with that send-symbol [from GetPlay mylib] does similarly, and at the end creates a [r] object with that same symbol as an arg. Thus you can send and receive messages without wires to any of the abstractions in your library, without using $0, and with a very low likelihood of running into namespace clashes (since it is unlikely that a [s] or [r] in some other random abstraction or patch will be using a receive name prefixed with the path of your library.) The other nice thing about the [to]/[from] wrapper is that it defaults to canvas-local scope-- that is, if you just want [s $0-foo] you type [to foo], which 95% of the time is what you want anyway (look at how many of Miller's help patches have a "Put" menu array named "array1"!) It's trivial to wrap [s~]/[r~], [throw~]/[catch~], and any others that I'm missing. Drawback is this doesn't jibe with message box nonlocal sends which are inescapably global in scope, nor with the iemguis (which could easily have a dialog option added to define scope), nor garrays (which could, too, except that there are tons of internals/externals that specify array name with a single symbolic arg, so to be consistent with this interface you'd have to set the array symbol with a message, and now we're back to the same ugliness of sending a $0 to a message box...). -Jonathan > > what i want is this: > > player doesn't know or care who's controlling
Re: [PD] variable receive objects?
On 12/05/12 12:20, Jörn Nettingsmeier wrote: [snip] is there a way to generate a variable receive object similar to a send via message box, whose source is defined at load time? [snip] or maybe i'm totally up the wrong alley, and someone can suggest a more idiomatic way to deal with this issue? I think more idiomatic is identifier flow from outside in (rather than trying to get the insides out). Use $1 in the player and the controller, instead of their own local $0. Pass the same value in as the player and controller(s) arguments. Possibly passing in something based on the local $0 of their common parent patch if they have one, otherwise pick a magic name that is hopefully unique enough. I find it quite common to add layers of $ when nesting abstractions, perhaps with a pattern similar to: patch:[nbx]--[s $0-r] [foo $0] [r $0-s]--[print] foo: [r $1-r]--[s $0-$1-r] [bar $0-$1] [r $0-$1-s]--[s $1-s] bar: [r $1-r]--[s $0-$1-r] [baz $0-$1] [r $0-$1-s]--[s $1-s] baz: [r $1-r]--[+ 1]--[s $1-s] Claude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable receive objects?
hi! is there a way to generate a variable receive object similar to a send via message box, whose source is defined at load time? use iem_receive / iem_r from iemlib. cheers, marian ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] variable receive objects?
hi *! i'm playing around with a theatre cue player written around readanysf, which i will post on the web as soon as i'm sure it's not going to be too embarrassing - need to pick up some more pd idioms first... so far, i've been able to create a nice gui using graph-on-parent, and all gui events are messages sent to receive objects, internally. for instance, hitting the "play" bang button will send the bang to cfPlayer$0SetPlay. the idea is that everybody can grab this event, not just the readanysf~ object. now i've painted myself into a corner: i want to create a midi controller abstraction which is separate from the player and gui. to that end, i have added an outlet to my player that contains the player's unique id $0. this outlet is connected to the controller object, which can now happily send messages back to the player, using message boxes: |inlet| <-- gets the parent player's $0 ID |set $1( | ( |; cfPlayer$1SetPlay bang( that gives me nice separation. the problem is that i want the controller object to be able to _listen_ to player events as well as generate them, so that the midi controller always reflects the current state, even if it was initiated elsewhere, such as via the gui or by loading a playlist item. is there a way to generate a variable receive object similar to a send via message box, whose source is defined at load time? something like this: |inlet| <-- gets the parent player's $0 ID |set $1( | ( |receive cfPlayer$1GetPlay( which, of course, doesn't work. or maybe i'm totally up the wrong alley, and someone can suggest a more idiomatic way to deal with this issue? what i want is this: player doesn't know or care who's controlling it. controller can (and does) have knowledge of the player event model. this way, i can easily add OSC or playlist controllers later, keeping the main player nice and simple. best, jörn -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
