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
----- Original Message -----
From: Marian Weger mail@marianweger.com 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
On 05/12/2012 07:58 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Marian Wegermail@marianweger.com 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.
----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at 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 Wegermail@marianweger.com 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
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 zmoelnig@iem.at 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 Wegermail@marianweger.com 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
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 msp@ucsd.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: IOhannes m zmölnig zmoelnig@iem.at; "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 zmoelnig@iem.at 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 Wegermail@marianweger.com 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 ->
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 jancsika@yahoo.comwrote:
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 msp@ucsd.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: IOhannes m zmölnig zmoelnig@iem.at; "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 zmoelnig@iem.at 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 Wegermail@marianweger.com 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 ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----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
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at 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
On 14/05/12 19:43, Jonathan Wilkes wrote:
From: IOhannes m zmoelnigzmoelnig@iem.at 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
----- Original Message -----
From: Claude Heiland-Allen claude@goto10.org 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 zmoelnigzmoelnig@iem.at 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
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 claude@goto10.org 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 zmoelnigzmoelnig@iem.at 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
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: Claude Heiland-Allen claude@goto10.org; "pd-list@iem.at" 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 claude@goto10.org 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 zmoelnigzmoelnig@iem.at 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 ->
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.
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.
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_<var>() 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_<var>() 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!
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-bounces@iem.at [mailto:pd-list-bounces@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_<var>() 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_<var>() 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
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-bounces@iem.at [mailto:pd-list-bounces@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_<var>() 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_<var>() 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
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 msp@ucsd.edu 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-bounces@iem.at [mailto:pd-list-bounces@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_<var>() 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_<var>() 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
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 msp@ucsd.edu 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-bounces@iem.at [mailto:pd-list-bounces@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_<var>() 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_<var>() 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
-----Original Message----- From: Miller Puckette [mailto:msp@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 msp@ucsd.edu 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-bounces@iem.at [mailto:pd-list-bounces@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_<var>() 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_<var>() 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
Hi Ico and list - On Tue, Jun 19, 2012 at 10:20:07PM -0400, Ivica Ico Bukvic wrote:
-----Original Message----- From: Miller Puckette [mailto:msp@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
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:msp@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
[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
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!
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.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 option 1B %lx\n", (t_int)x);
//fprintf(stderr,"pd_bind option 1B %lx\n", (t_int)x); t_bindlist *b = (t_bindlist *)pd_new(bindlist_class); t_bindelem *e1 = (t_bindelem *)getbytes(sizeof(t_bindelem)); t_bindelem *e2 = (t_bindelem *)getbytes(sizeof(t_bindelem));@@ -237,6 +291,7 @@
void pd_unbind(t_pd *x, t_symbol *s) {
- //fprintf(stderr,"pd_unbind %s\n", s->s_name); if (s->s_thing == x) { //fprintf(stderr,"pd_unbind option A %lx\n", (t_int)x); s->s_thing = 0;
@@ -247,30 +302,56 @@ 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 bindlistoccur via graph (through code execution, e.g. dynamic change of receives)and if so, we do not deallocate memory until the entire bindlist_<datatype>function is complete with its execution, after which we callbindlist_cleanup(). we control the execution via static int variablechange_bindlist_via_graph *///fprintf(stderr,"pd_unbind option B %lx\n", (t_int)x);
t_bindlist *b = (t_bindlist *)s->s_thing; t_bindelem *e, *e2; if ((e = b->b_list)->e_who == x) {
b->b_list = e->e_next;freebytes(e, sizeof(t_bindelem));
if (change_bindlist_via_graph) {change_bindlist_via_graph++;e->e_who = NULL;} else {b->b_list = e->e_next;freebytes(e, sizeof(t_bindelem));} //fprintf(stderr,"success B1a\n"); } else for (e = b->b_list; e2 = e->e_next; e = e2) if (e2->e_who == x) {
e->e_next = e2->e_next;freebytes(e2, sizeof(t_bindelem));
if (change_bindlist_via_graph) {change_bindlist_via_graph++;e2->e_who = NULL;} else {e->e_next = e2->e_next;freebytes(e2, sizeof(t_bindelem));} //fprintf(stderr,"success B1b\n"); break; }
if (!b->b_list->e_next)
int count_valid = 0;for (e = b->b_list; e; e = e->e_next) {if (e->e_who != NULL)count_valid++;}if (count_valid == 1) { s->s_thing = b->b_list->e_who;
freebytes(b->b_list, sizeof(t_bindelem));pd_free(&b->b_pd);///fprintf(stderr,"success B3\n");
if (!change_bindlist_via_graph) {freebytes(b->b_list, sizeof(t_bindelem));pd_free(&b->b_pd);}//fprintf(stderr,"success B2\n"); }
Miller Puckette msp@ucsd.edu 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;
}
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 option 1B %lx\n", (t_int)x);
//fprintf(stderr,"pd_bind option 1B %lx\n", (t_int)x); t_bindlist *b = (t_bindlist *)pd_new(bindlist_class); t_bindelem *e1 = (t_bindelem*)getbytes(sizeof(t_bindelem));
t_bindelem *e2 = (t_bindelem*)getbytes(sizeof(t_bindelem));
@@ -237,6 +291,7 @@
void pd_unbind(t_pd *x, t_symbol *s) {
- //fprintf(stderr,"pd_unbind %s\n", s->s_name); if (s->s_thing == x) { //fprintf(stderr,"pd_unbind option A %lx\n", (t_int)x); s->s_thing = 0;
@@ -247,30 +302,56 @@ 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 thebindlist
occur via graph (through code execution, e.g. dynamic change ofreceives)
and if so, we do not deallocate memory until the entirebindlist_<datatype>
function is complete with its execution, after which we callbindlist_cleanup(). we control the execution via static intvariable
change_bindlist_via_graph *///fprintf(stderr,"pd_unbind option B %lx\n", (t_int)x);
t_bindlist *b = (t_bindlist *)s->s_thing; t_bindelem *e, *e2; if ((e = b->b_list)->e_who == x) {
b->b_list = e->e_next;freebytes(e, sizeof(t_bindelem));
if (change_bindlist_via_graph) {change_bindlist_via_graph++;e->e_who = NULL;} else {b->b_list = e->e_next;freebytes(e, sizeof(t_bindelem));} //fprintf(stderr,"success B1a\n"); } else for (e = b->b_list; e2 = e->e_next; e = e2) if (e2->e_who == x) {
e->e_next = e2->e_next;freebytes(e2, sizeof(t_bindelem));
if (change_bindlist_via_graph) {change_bindlist_via_graph++;e2->e_who = NULL;} else {e->e_next = e2->e_next;freebytes(e2, sizeof(t_bindelem));} //fprintf(stderr,"success B1b\n"); break; }
if (!b->b_list->e_next)
int count_valid = 0;for (e = b->b_list; e; e = e->e_next) {if (e->e_who != NULL)count_valid++;}if (count_valid == 1) { s->s_thing = b->b_list->e_who;
freebytes(b->b_list, sizeof(t_bindelem));pd_free(&b->b_pd);///fprintf(stderr,"success B3\n");
if (!change_bindlist_via_graph) {freebytes(b->b_list, sizeof(t_bindelem));pd_free(&b->b_pd);}//fprintf(stderr,"success B2\n"); }
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
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: Miller Puckette msp@ucsd.edu Cc: pd-list@iem.at Sent: Saturday, June 23, 2012 6:36 PM Subject: Re: [PD] variable receive objects?
Miller Puckette msp@ucsd.edu 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) { 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 option 1B
%lx\n", (t_int)x);
+ //fprintf(stderr,"pd_bind option 1B %lx\n",
(t_int)x);
t_bindlist *b = (t_bindlist *)pd_new(bindlist_class); t_bindelem *e1 = (t_bindelem
*)getbytes(sizeof(t_bindelem));
t_bindelem *e2 = (t_bindelem
*)getbytes(sizeof(t_bindelem));
@@ -237,6 +291,7 @@ void pd_unbind(t_pd *x, t_symbol *s) { + //fprintf(stderr,"pd_unbind %s\n", s->s_name); if (s->s_thing == x) { //fprintf(stderr,"pd_unbind option A %lx\n",
(t_int)x);
s->s_thing = 0; @@ -247,30 +302,56 @@ 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_<datatype>
+ function is complete with its execution, after which we
call
+ bindlist_cleanup(). we control the execution via static
int
variable
+ change_bindlist_via_graph */
//fprintf(stderr,"pd_unbind option B %lx\n",
(t_int)x);
t_bindlist *b = (t_bindlist *)s->s_thing; t_bindelem *e, *e2; if ((e = b->b_list)->e_who == x) { - b->b_list = e->e_next; - freebytes(e, sizeof(t_bindelem)); + if (change_bindlist_via_graph) { + change_bindlist_via_graph++; + e->e_who = NULL; + } else { + b->b_list = e->e_next; + freebytes(e, sizeof(t_bindelem)); + } //fprintf(stderr,"success B1a\n"); } else for (e = b->b_list; e2 = e->e_next; e = e2) if (e2->e_who == x) { - e->e_next = e2->e_next; - freebytes(e2, sizeof(t_bindelem)); + if (change_bindlist_via_graph) { + change_bindlist_via_graph++; + e2->e_who = NULL; + } else { + e->e_next = e2->e_next; + freebytes(e2, sizeof(t_bindelem)); + } //fprintf(stderr,"success B1b\n"); break; } - if (!b->b_list->e_next)
+ int count_valid = 0; + for (e = b->b_list; e; e = e->e_next) { + if (e->e_who != NULL) + count_valid++;
+ } + if (count_valid == 1) { s->s_thing = b->b_list->e_who; - freebytes(b->b_list, sizeof(t_bindelem)); - pd_free(&b->b_pd); - ///fprintf(stderr,"success B3\n"); + if (!change_bindlist_via_graph) { + freebytes(b->b_list, sizeof(t_bindelem)); + pd_free(&b->b_pd); + } + //fprintf(stderr,"success B2\n"); } } else pd_error(x, "%s: couldn't unbind",
s->s_name);
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le centre Databaz, en partenariat avec Labomedia entre autres, organise le premier PUREDATA SummerCamp du 5 au 8 juillet 2012.
— Face à la diffusion croissante de puredata dans le milieu artistique français, databaz, qui organise régulièrement des work-shops puredata, a décidé de créer un moment estival de rencontres pour les développeurs et les utilisateurs de puredata et de ses extensions (autres langages, techniques). Ce moment, loin de toute volonté à prétention médiatique, vise à permettre une rencontre conviviale, de partage aussi bien de compétences que de créations. — Toutes les personnes intéressées par cet événement peuvent s'inscrire et proposer selon leur thème de recherches un atelier ou bien une intervention. Il y aura trois lieux distincts pour les ateliers, proposant des possibilités ausi bien au niveau sonore que de vidéo-projection. — Seront privilégiés : les ateliers de développement de librairie ou de documentation en relation aux dernières avancées de puredata [par exemple autour du GLSL, de librairie spécifiques, etc], mais aussi des ateliers de démonstration de liaisons entre puredata et d'autres formes de protocoles [php, python, bash, perl, java, etc]. — Pour les live-sets, nous aimerions anticiper et dès lors avoir des propositions en amont afin de structurer les deux soirées qui seront ouvertes au public. Organisation Début jeudi soir pour les arrivées (5 juillet) Vendredi 6 juillet-dimanche 8 juillet toute la journée Work-shop atelier interventions démonstration Vendredi soir et samedi soir soirée démonstration, live set, repas et fête. Databaz prendra à sa charge la nourriture et une part des boissons pendant l'ensemble de l'événement. Inscription obligatoire Databaz organisant cela dans son centre, il nous faut établir à l'avance le nombre de participants pour prévoir tous les couchages [sera demandé d'amener un sac de couchage] pour les non-régionaux. [Databaz — 100 rue du Gond — 16000 Angoulême — 06 61 37 22 35] Agrandir le plan [ http://databaz.org/centre ]
ce sera a angouleme ?
si des gens cherchent un lieu a paris pour organiser le meme type d'evenements,
j'habite dans une grande collocation magique d'artistes dans le 20eme et on a plusieurs espaces qu'on peut ouvrir pour des ateliers
Le 21 juin 2012 09:01, philippe boisnard philemon1@mac.com a écrit :
http://databaz.org/centre/wp-content/uploads/2010/03/Image-49.png Le centre Databaz, en partenariat avec Labomedia entre autres, organise le premier PUREDATA SummerCamp du 5 au 8 juillet 2012.
— Face à la diffusion croissante de puredata dans le milieu artistique français, databaz, qui organise régulièrement des work-shops puredata, a décidé de créer un moment estival de rencontres pour les développeurs et les utilisateurs de puredata et de ses extensions (autres langages, techniques). Ce moment, loin de toute volonté à prétention médiatique, vise à permettre une rencontre conviviale, de partage aussi bien de compétences que de créations. — Toutes les personnes intéressées par cet événement peuvent s'inscrire et proposer selon leur thème de recherches un atelier ou bien une intervention. Il y aura trois lieux distincts pour les ateliers, proposant des possibilités ausi bien au niveau sonore que de vidéo-projection. — Seront privilégiés : les ateliers de développement de librairie ou de documentation en relation aux dernières avancées de puredata [par exemple autour du GLSL, de librairie spécifiques, etc], mais aussi des ateliers de démonstration de liaisons entre puredata et d'autres formes de protocoles [php, python, bash, perl, java, etc]. — Pour les live-sets, nous aimerions anticiper et dès lors avoir des propositions en amont afin de structurer les deux soirées qui seront ouvertes au public. Organisation Début jeudi soir pour les arrivées (5 juillet) Vendredi 6 juillet-dimanche 8 juillet toute la journée Work-shop atelier interventions démonstration Vendredi soir et samedi soir soirée démonstration, live set, repas et fête. Databaz prendra à sa charge la nourriture et une part des boissons pendant l'ensemble de l'événement. Inscription obligatoire Databaz organisant cela dans son centre, il nous faut établir à l'avance le nombre de participants pour prévoir tous les couchages [sera demandé d'amener un sac de couchage] pour les non-régionaux. [Databaz — 100 rue du Gond — 16000 Angoulême — 06 61 37 22 35] Agrandir le planhttp://maps.google.fr/maps?f=q&source=embed&hl=fr&geocode=&q=100+rue+du+gond+angoul%C3%AAme&aq=&sll=46.75984,1.738281&sspn=8.762458,17.248535&ie=UTF8&hq=&hnear=100+Rue+du+Gond,+16000+Angoul%C3%AAme,+Charente,+Poitou-Charentes&ll=45.65676,0.162006&spn=0.017457,0.033689&t=m&z=14&iwloc=A [ http://databaz.org/centre ]
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[french version]
Yeepee...
Pour avoir gouté à la Databaz, je sais qu'il y a moyen d'y marquer un nombre considérable de points, voire de tuer le match dans l'oeuf... N'hésitez pas une seconde à venir gagner d'inoubliables victoires avec nous... D'autant que, bien entendu, de nombreux chef d'œuvres d'art majeur majeurs vont être mis à bas et/ou exhibés durant ce long WE... Ne pas venir, c'est un coup à pleurer des deux yeux pendant plusieurs années...
Par ailleurs, de toutes les Histoires de l'Humanité (Grèce Antique comprise), je ne suis pas sûr qu'il y ait déjà eu en France un évènement aussi prometteur quant à la possibilité pour la communauté francophone d'avoir des relations de promiscuité aussi inavouables.
Miam miam !
À tout de suite...
:-)
01ivier
[english version]
If you don't speak french, this event is the perfect moment for you to start learning it... Don't waste your time longer with sad friends and come to the PUREDATA SummerCamp in France. The victory is sure.
Yum !
(-:
01ivier
Le 21.06.2012 09:01, philippe boisnard a écrit :
[1] Le centre Databaz, en partenariat avec Labomedia entre autres, organise le premier PUREDATA SummerCamp du 5 au 8 juillet 2012.
— Face à la diffusion croissante de puredata dans le milieu artistique français, databaz, qui organise régulièrement des work-shops puredata, a décidé de créer un moment estival de rencontres pour les développeurs et les utilisateurs de puredata et de ses extensions (autres langages, techniques). Ce moment, loin de toute volonté à prétention médiatique, vise à permettre une rencontre conviviale, de partage aussi bien de compétences que de créations. — Toutes les personnes intéressées par cet événement peuvent s'inscrire et proposer selon leur thème de recherches un atelier ou bien une intervention. Il y aura trois lieux distincts pour les ateliers, proposant des possibilités ausi bien au niveau sonore que de vidéo-projection. — Seront privilégiés : les ateliers de développement de librairie ou de documentation en relation aux dernières avancées de puredata [par exemple autour du GLSL, de librairie spécifiques, etc], mais aussi des ateliers de démonstration de liaisons entre puredata et d'autres formes de protocoles [php, python, bash, perl, java, etc]. — Pour les live-sets, nous aimerions anticiper et dès lors avoir des propositions en amont afin de structurer les deux soirées qui seront ouvertes au public. Organisation Début jeudi soir pour les arrivées (5 juillet) Vendredi 6 juillet-dimanche 8 juillet toute la journée Work-shop atelier interventions démonstration Vendredi soir et samedi soir soirée démonstration, live set, repas et fête. Databaz prendra à sa charge la nourriture et une part des boissons pendant l'ensemble de l'événement. Inscription obligatoire Databaz organisant cela dans son centre, il nous faut établir à l'avance le nombre de participants pour prévoir tous les couchages [sera demandé d'amener un sac de couchage] pour les non-régionaux. [Databaz — 100 rue du Gond — 16000 Angoulême — 06 61 37 22 35] Agrandir le plan [2] [ http://databaz.org/centre [3] ]
Links:
[1] http://databaz.org/centre/wp-content/uploads/2010/03/Image-49.png [2]
http://maps.google.fr/maps?f=q&source=embed&hl=fr&geocode=&q... [3] http://databaz.org/centre
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
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Ivica Ico Bukvic ico@vt.edu Cc: "pd-list@iem.at" 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
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
----- Original Message -----
From: Claude Heiland-Allen claude@goto10.org 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
----- Original Message -----
From: Jörn Nettingsmeier nettings@stackingdwarves.net 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:
- prefixes "GetPlay" with the path of the abstraction's directory (using my patch to the source)
- possibly prefixes that with "__" or something (not sure if that's necessary)
- 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 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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 Barknecht Do You RjDj.me? _ ______footils.org__
----- Original Message -----
From: Frank Barknecht fbar@footils.org 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
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.volochine@gmail.com http://yvanvolochine.com
----- Original Message -----
From: yvan volochine yvan.pd@gmail.com To: pd-list pd-list@iem.at 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.volochine@gmail.com http://yvanvolochine.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Claude Heiland-Allen -
Frank Barknecht -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Ivica Ico Bukvic -
John Harrison -
Jonathan Wilkes -
Jörn Nettingsmeier -
Marian Weger -
Miller Puckette -
Olivier Baudu -
philippe boisnard -
Roch Jub -
yvan volochine