Hi again,just another question regarding the pd-msg system. Say I have two parametrized abstractions [boo 1] and [boo 2] loaded in my patch. When I send a message to them to dynamically create some objects inside, I send it as [obj 20 30 metro 100(--->[s pd-boo.pd] which, of course, goes to both instances. Would it be a way to send the message only to a single instance, maybe taking into account the creation parameters? Adding prefix to the abstraction names is not elegant, as that would require previously creating n abstractions, named [1_boo] , [2_boo] and so on...clumsy
Hi Jeppi,
2011/5/5 Jeppi Jeppi jeppiot@hotmail.com
Hi again, just another question regarding the pd-msg system. Say I have two parametrized abstractions [boo 1] and [boo 2] loaded in my patch. When I send a message to them to dynamically create some objects inside, I send it as [obj 20 30 metro 100(--->[s pd-boo.pd] which, of course, goes to both instances.
Would it be a way to send the message only to a single instance, maybe taking into account the creation parameters?
If abstraction ``boo.pd'' is changed and saved to boo.pd changes are
applied to all boo.pd's in the patch. So two different boo.pd's require two different names. Except for creation arguments, I assume they're not saved in the abstraction, but in your main patch.
Adding prefix to the abstraction names is not elegant, as that would require
previously creating n abstractions, named [1_boo] , [2_boo] and so on...clumsy
Having two different abstractions with the same name seems less elegant
to me.
Cheers,
Funs
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 05/05/11 10:31, Jeppi Jeppi wrote:
Hi again,just another question regarding the pd-msg system. Say I have two parametrized abstractions [boo 1] and [boo 2] loaded in my patch. When I send a message to them to dynamically create some objects inside, I send it as [obj 20 30 metro 100(--->[s pd-boo.pd] which, of course, goes to both instances. Would it be a way to send the message only to a single instance, maybe taking into account the creation parameters? Adding prefix to the abstraction names is not elegant, as that would require previously creating n abstractions, named [1_boo] , [2_boo] and so on...clumsy
I would probably workaround this stuff by doing something like this:
boo.pd ----8<---- [inlet] <-- or a global [receive BOO] | [route $1] | | [loadbang] | | | [clear( <-- click this before saving too | / [s pd-$0-boo-subpatch] <-- the $0 is local to each abstraction [pd $0-boo-subpatch] ----8<----
Then [list prepend 1] etc each message before sending it to all the [inlet] or [send BOO] or whatever.
Claude
On 05/05/11 11:56, Claude Heiland-Allen wrote:
On 05/05/11 10:31, Jeppi Jeppi wrote:
Adding prefix to the abstraction names is not elegant, as that would require previously creating n abstractions, named [1_boo] , [2_boo] and so on...clumsy
Just remembered there is a "loader plugin" out there somewhere that creates new abstractions from a template for any unknown names - not sure where to find it though IOhannes might know?
Claude
2011/5/5 Claude Heiland-Allen claude@goto10.org
On 05/05/11 11:56, Claude Heiland-Allen wrote:
On 05/05/11 10:31, Jeppi Jeppi wrote:
Adding prefix to the abstraction names is not elegant, as that would require previously creating n abstractions, named [1_boo] , [2_boo] and so on...clumsy
Just remembered there is a "loader plugin" out there somewhere that creates new abstractions from a template for any unknown names - not sure where to find it though IOhannes might know?
iemguts/autoabstraction?
Funs
Hey, many thanks to all for such great tricks&hacks! The trick to route messages to a named subpatch turned out to be a chicken-egg problem if the subpatches are to be built dynamically as I need...thanks for the nice idea anyway :)though "obsolete" (?) that [namecanvas] really solved my problem. Hope it won't be deprecated, as it seems the only way to access individual abstraction instances through the pd-msg system. Otherwise a (better?) workaround should be provided.Btw where is this iemguts lib?
Date: Thu, 5 May 2011 13:24:22 +0200 From: funsseelen@gmail.com To: claude@goto10.org CC: pd-list@iem.at Subject: Re: [PD] msg to abstractions
2011/5/5 Claude Heiland-Allen claude@goto10.org
On 05/05/11 11:56, Claude Heiland-Allen wrote:
On 05/05/11 10:31, Jeppi Jeppi wrote:
Adding prefix to the abstraction names is not elegant, as that would
require previously creating n abstractions, named [1_boo] , [2_boo]
and so on...clumsy
Just remembered there is a "loader plugin" out there somewhere that creates new abstractions from a template for any unknown names - not sure where to find it though IOhannes might know?
iemguts/autoabstraction?
Funs
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2011/5/5 Jeppi Jeppi jeppiot@hotmail.com
Hey, many thanks to all for such great tricks&hacks!
The trick to route messages to a named subpatch turned out to be a chicken-egg problem if the subpatches are to be built dynamically as I need...thanks for the nice idea anyway :) though "obsolete" (?) that [namecanvas] really solved my problem. Hope it won't be deprecated, as it seems the only way to access individual abstraction instances through the pd-msg system. Otherwise a (better?) workaround should be provided. Btw where is this iemguts lib?
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/iem/ie...
Date: Thu, 5 May 2011 13:24:22 +0200 From: funsseelen@gmail.com To: claude@goto10.org CC: pd-list@iem.at Subject: Re: [PD] msg to abstractions
2011/5/5 Claude Heiland-Allen claude@goto10.org
On 05/05/11 11:56, Claude Heiland-Allen wrote:
On 05/05/11 10:31, Jeppi Jeppi wrote:
Adding prefix to the abstraction names is not elegant, as that would require previously creating n abstractions, named [1_boo] , [2_boo] and so on...clumsy
Just remembered there is a "loader plugin" out there somewhere that creates new abstractions from a template for any unknown names - not sure where to find it though IOhannes might know?
iemguts/autoabstraction?
Funs
_______________________________________________ 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 05/05/2011 09:15 PM, Jeppi Jeppi wrote:
Hey, many thanks to all for such great tricks&hacks!
The trick to route messages to a named subpatch turned out to be a chicken-egg problem if the subpatches are to be built dynamically as I need...thanks for the nice idea anyway :) though "obsolete" (?) that [namecanvas] really solved my problem. Hope it won't be deprecated, as it seems the only way to access individual abstraction instances through the pd-msg system. Otherwise a (better?) workaround should be provided.
well although I dunno it I guess that there must be a good reason to deprecate it (moving the gui out of pd maybe ?? =)
claude solution works nicely without fancy dynamic subpatch magic (which is IMHO kinda risky within pd anyway)
just my 0.02€
_y
On Thu, 5 May 2011, yvan volochine wrote:
well although I dunno it I guess that there must be a good reason to deprecate it
No.
(moving the gui out of pd maybe ?? =)
Moving the GUI out needs not have any impact on the existence of [namecanvas]. If it were to have any impact, it would be an unnecessary change.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Thu, 5 May 2011, Jeppi Jeppi wrote:
The trick to route messages to a named subpatch turned out to be a chicken-egg problem if the subpatches are to be built dynamically as I need...thanks for the nice idea anyway :) though "obsolete" (?) that [namecanvas] really solved my problem.
[namecanvas] has been marked obsolete for several years. Miller stated a reason for that, but I couldn't make sense of it. It's been several years, and [namecanvas] has been proved to be useful anyway, and you can bet that if Miller ever removes it, it will reappear the next week in five different libraries, and/or perhaps this removal will be cancelled in pd-extended.
Miller has shown no intention of removing the deprecation mark on it.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Thu, 2011-05-05 at 11:31 +0200, Jeppi Jeppi wrote:
Hi again, just another question regarding the pd-msg system. Say I have two parametrized abstractions [boo 1] and [boo 2] loaded in my patch. When I send a message to them to dynamically create some objects inside, I send it as [obj 20 30 metro 100(--->[s pd-boo.pd] which, of course, goes to both instances.
Would it be a way to send the message only to a single instance, maybe taking into account the creation parameters?
Adding prefix to the abstraction names is not elegant, as that would require previously creating n abstractions, named [1_boo] , [2_boo] and so on...clumsy
You could use the object [namecanvas] to name each of your instances of your abstraction differently. Exactly this setup is the reason why me (and many others) think that this object class shouldn't be deprecated at all, as stated in the help-file.
Just put a [namecanvas $1_boo] into your abstraction. Then you can address each instance separately ('1_boo', '2_boo', etc.) when sending it pd-msgs.
Roman
-
Claude Heiland-Allen -
Funs Seelen -
Jeppi Jeppi -
Mathieu Bouchard -
Roman Haefeli -
yvan volochine