Hi, How does one create an abstraction with a variable number of outlets (depending on the number of arguments)? Thanks Eldad
could you please be a little more specific?
all the best der.brandt
Zitat von "Eldad Tsabary" tazberry_docs@yahoo.ca:
Hi, How does one create an abstraction with a variable number of outlets
(depending on the number of arguments)? Thanks Eldad
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
What about something like this?
james
Quoth brandt@subnet.at, on 11/08/2012 09:47:
could you please be a little more specific?
all the best der.brandt
Zitat von "Eldad Tsabary" tazberry_docs@yahoo.ca:
Hi, How does one create an abstraction with a variable number of outlets (depending on the number of arguments)? Thanks Eldad
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
I tried something like that about a year ago using dynamic patching. I wanted to make this work in Pd-Vanilla and ran into the problem that at the time the patch is loaded the outlets don't exist. The abstraction builds up and works but can't be used since the original connections to this abstraction are broken because they just don't exist at this point. My approach to this was then to reverse the process, i.e. to create a big (maximum) number of inlets in advance and then remove them according to the needs of the patch. But I didn't finish this due to time constraints and actually, I didn't really need it so far.
In Pd-extended it could be easier since there are more possibilities to control the init-phase of a just loaded patch. I think it's in iemlib (Iohannes could chime in) but admittedly I forgot about it, since also there was a lot of discussion wether this should go into Vanilla or not, and also doing that in extended wasn't my goal. On the bottom line, according to my experience, I found dynamic patching pretty fragile and it always feels like a "hack" to me. i.e. changing the functional part of a dynamic abstraction appears like walking on a tight rope where everything could collapse like a house of cards. It was fun trying it but I suspect that's not the intended application of that technique. ;-) Michael.
On 10.8.2012, at 22:28 , Eldad Tsabary wrote:
Hi, How does one create an abstraction with a variable number of outlets (depending on the number of arguments)? Thanks Eldad
-- noise chasers: http://blauwurf.at http://soundcloud.com/noiseconformist
On 08/11/2012 01:58 PM, Michael Zacherl wrote:
In Pd-extended it could be easier since there are more possibilities to control the init-phase of a just loaded patch. I think it's in iemlib (Iohannes could chime in) but admittedly I forgot about it, since also there was a lot of discussion wether this should go into Vanilla or not,
the secrect is [initbang], which fires when the abstraction is ready (rather than [loadbang], which fires when all the patch (with all the abstractions, sub-patches and what not) is ready)).
unfortunately, i haven't found a way to make [initbang] without hacking Pd itself, so it's not part of any library (e.g. iemlib).
instead, there is a (low-level) "patch" for Pd somewhere in the tracker, which is applied to Pd-extended (but unfortunately not to Pd-vanilla).
thus: if you want to need [initbang] (which you do if you really need variable in/outlets in abstractions), you need to either compile Pd yourself or use Pd-extended (only the core binary, no need for any externals here)
fgmasdr IOhannes
On 08/11/2012 01:58 PM, Michael Zacherl wrote:
In Pd-extended it could be easier since there are more possibilities to
control the init-phase of a just loaded patch.
I think it's in iemlib (Iohannes could chime in) but admittedly I forgot about it, since also there was a lot of discussion wether this should go into Vanilla or not,
the secrect is [initbang], which fires when the abstraction is ready
(rather
than [loadbang], which fires when all the patch (with all the
abstractions,
sub-patches and what not) is ready)).
unfortunately, i haven't found a way to make [initbang] without hacking Pd itself, so it's not part of any library (e.g. iemlib).
instead, there is a (low-level) "patch" for Pd somewhere in the tracker,
which
is applied to Pd-extended (but unfortunately not to Pd-vanilla).
thus: if you want to need [initbang] (which you do if you really need
variable
in/outlets in abstractions), you need to either compile Pd yourself or use
Pd-
extended (only the core binary, no need for any externals here)
fgmasdr IOhannes
Also, if you need a pre-loadbang event which happens right before loadbang but after all the objects have loaded, you could try pd-l2ork which has also pre-loadbang event. Currently it is only being used for universal presets that depend on the graph placement of all objects to keep track of them. Therefore, the only time for the presets to detect objects they are tied to correctly is only after they have all been created but before loadbang (as one could loadbang a new preset which would not work unless all the objects have been paired properly). The reason preset_hub and preset_node do this is because this way a single preset can deal with multiple instances of a same abstraction and still be able to distinguish which one is being referenced. See pd-l2ork K12 mode for examples of how this works (tl;dr: one abstraction hosts presets and keeps track of all other abstractions and their states)...
HTH
Ico
Hallo IOhannes,
On 08/11/2012 01:58 PM, Michael Zacherl wrote:
In Pd-extended it could be easier since there are more possibilities to control the init-phase of a just loaded patch. I think it's in iemlib (Iohannes could chime in) but admittedly I forgot about it, since also there was a lot of discussion wether this should go into Vanilla or not,
the secrect is [initbang], which fires when the abstraction is ready (rather than [loadbang], which fires when all the patch (with all the abstractions, sub-patches and what not) is ready)).
what about dependencies within cascaded abstractions? E.g. one dynamically patched abstraction would need another one? is there a way to guarantee a sequence in order not to break connections?
unfortunately, i haven't found a way to make [initbang] without hacking Pd itself, so it's not part of any library (e.g. iemlib).
so it's a modified Pd-Vanilla, we have with Pd-extended, not only Pd-Vanilla plus a load of externals and abstractions? I wasn't aware of that. Now I understand all the discussions about that (not trying to open an old can of worms! ;-)
instead, there is a (low-level) "patch" for Pd somewhere in the tracker, which is applied to Pd-extended (but unfortunately not to Pd-vanilla).
tracker?
thus: if you want to need [initbang] (which you do if you really need variable in/outlets in abstractions), you need to either compile Pd yourself or use Pd-extended (only the core binary, no need for any externals here)
What I tried, and apparently works, is to create a maximum number of inlets/outlets and delete the ones not needed at load-time. ButI consider this one a hack and certainly doesn't improve the reliability of a dymamic patch.
Michael.
-- feed your perception: http://blauwurf.at http://soundcloud.com/noiseconformist
From: Michael Zacherl sdiy-mz01@blauwurf.info To: IOhannes m zmölnig zmoelnig@iem.at Cc: pd-list list pd-list@iem.at Sent: Tuesday, August 14, 2012 9:56 AM Subject: Re: [PD] variable number of outlets/inlets /dynamic patching Hallo IOhannes,
On 08/11/2012 01:58 PM, Michael Zacherl wrote:
In Pd-extended it could be easier since there are more possibilities to control the init-phase of a just loaded patch. I think it's in iemlib (Iohannes could chime in) but admittedly I forgot about it, since also there was a lot of discussion wether this should go into Vanilla or not,
the secrect is [initbang], which fires when the abstraction is ready (rather than [loadbang], which fires when all the patch (with all the abstractions, sub-patches and what not) is ready)).
what about dependencies within cascaded abstractions? E.g. one dynamically patched abstraction would need another one? is there a way to guarantee a sequence in order not to break connections?
unfortunately, i haven't found a way to make [initbang] without hacking Pd itself, so it's not part of any library (e.g. iemlib).
so it's a modified Pd-Vanilla, we have with Pd-extended, not only Pd-Vanilla plus a load of externals and abstractions? I wasn't aware of that. Now I understand all the discussions about that (not trying to open an old can of worms! ;-)
instead, there is a (low-level) "patch" for Pd somewhere in the tracker, which is applied to Pd-extended (but unfortunately not to Pd-vanilla).
tracker?
thus: if you want to need [initbang] (which you do if you really need variable in/outlets in abstractions), you need to either compile Pd yourself or use Pd-extended (only the core binary, no need for any externals here)
What I tried, and apparently works, is to create a maximum number of inlets/outlets and delete the ones not needed at load-time. ButI consider this one a hack and certainly doesn't improve the reliability of a dymamic patch.
Even with [initbang] it's still a hack. When designing and testing the abstraction, the user must remember to always remove the dynamically created inlets/outlets before saving, and there's no way to automate that without using yet another hack (faking mouse/cut messages, for example). -Jonathan
Michael.
-- feed your perception: http://blauwurf.at/ http://soundcloud.com/noiseconformist
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 14.8.2012, at 19:43 , Jonathan Wilkes wrote:
thus: if you want to need [initbang] (which you do if you really need variable in/outlets in abstractions), you need to either compile Pd yourself or use Pd-extended (only the core binary, no need for any externals here)
What I tried, and apparently works, is to create a maximum number of inlets/outlets and delete the ones not needed at load-time. ButI consider this one a hack and certainly doesn't improve the reliability of a dymamic patch.
Even with [initbang] it's still a hack. When designing and testing the abstraction, the user must remember to always remove the dynamically created inlets/outlets before saving, and there's no way to automate that without using yet another hack (faking mouse/cut messages, for example).
-Jonathan
admittedly I didn't look at dynamic patching for a long time. I remember that I searched for infos on best practices etc. but didn't find anything helpful back then. so curious as I am I still wonder what would be a good way to approach this. João's [jmmmp/dacm~] is nice but 'harmless' in this respect.
m.
-- hear the colours of noise: http://blauwurf.at http://soundcloud.com/noiseconformist
On 08/14/2012 07:43 PM, Jonathan Wilkes wrote:
Even with [initbang] it's still a hack. When designing and testing the abstraction, the user must remember to always remove the dynamically created inlets/outlets before saving, and there's no way to automate that without using yet another hack (faking mouse/cut messages, for example).
well yes, but that's _another_ problem.
fgmadsr IOhannes
On 08/14/2012 03:56 PM, Michael Zacherl wrote:
Hallo IOhannes,
On 08/11/2012 01:58 PM, Michael Zacherl wrote:
In Pd-extended it could be easier since there are more possibilities to control the init-phase of a just loaded patch. I think it's in iemlib (Iohannes could chime in) but admittedly I forgot about it, since also there was a lot of discussion wether this should go into Vanilla or not,
the secrect is [initbang], which fires when the abstraction is ready (rather than [loadbang], which fires when all the patch (with all the abstractions, sub-patches and what not) is ready)).
what about dependencies within cascaded abstractions? E.g. one dynamically patched abstraction would need another one? is there a way to guarantee a sequence in order not to break connections?
well, [initbang] guarantees[*] that it only fires after all the "static" objects contained within the abstraction have been properly constructed. an object is properly constructed after the "new" routine (constructor) has been called (in case of externals) or (in case of abstractions) the entire abstraction has been loaded and it's [initbang] method has been extecuted.
afaict, this is all you asked for.
fgmadr IOhannes
[*] if it does not as advertised here, i would consider it a bug.
with dynamic patching, for example [jmmmp/dacm~] in Pd-extended. not
exactly what you asked, but similar.
João
Hi, How does one create an abstraction with a variable number of outlets
(depending on the number of arguments)? Thanks Eldad
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
If the inlets/outlets are on the outside of your abstraction make sure you use [initbang]. Otherwise the connections to those ports in your main patch wouldn't be created. Michael.
On 14.8.2012, at 11:15 , João Pais wrote:
with dynamic patching, for example [jmmmp/dacm~] in Pd-extended. not exactly what you asked, but similar.
João
Hi, How does one create an abstraction with a variable number of outlets (depending on the number of arguments)? Thanks Eldad
-- noise chasers: http://blauwurf.at http://soundcloud.com/noiseconformist
On Fri, 10 Aug 2012 22:28:53 +0200, Eldad Tsabary tazberry_docs@yahoo.ca
wrote:
Hi, How does one create an abstraction with a variable number of outlets
(depending on the number of arguments)? Thanks Eldad
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
You can use [tof/arguments] to count the amount of arguments. Then, do
dynamic patching.
-
brandt＠subnet.at -
Eldad Tsabary -
IOhannes m zmölnig -
Ivica Ico Bukvic -
James Dunn -
Jonathan Wilkes -
João Pais -
Kaj Ailomaa -
Michael Zacherl