Re: [PD] variable number of outlets/inlets /dynamic patching
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets /dynamic patching
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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets
On Fri, 10 Aug 2012 22:28:53 +0200, Eldad Tsabary tazberry_d...@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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets /dynamic patching
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets /dynamic patching
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
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. 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
Re: [PD] variable number of outlets/inlets /dynamic patching
From: Michael Zacherl sdiy-m...@blauwurf.info To: IOhannes m zmölnig zmoel...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets /dynamic patching
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets
could you please be a little more specific? all the best der.brandt Zitat von Eldad Tsabary tazberry_d...@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
Re: [PD] variable number of outlets/inlets /dynamic patching
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets
What about something like this? james Quoth bra...@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_d...@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 #N canvas 720 172 450 300 10; #X obj 70 149 f; #X obj 109 149 + 1; #X obj 43 89 list-drip; #X obj 43 109 sel 0; #X obj 70 129 b; #X obj 109 169 * 50; #X msg 109 189 obj \$1 250 outlet; #X obj 43 49 loadbang; #X obj 43 21 namecanvas \$0-abs; #X obj 109 209 s \$0-abs; #X obj 43 69 any \$1 \$2 \$3 \$4 \$5 \$6 \$7 \$8 \$9 \$10; #X connect 0 0 1 0; #X connect 1 0 0 1; #X connect 1 0 5 0; #X connect 2 0 3 0; #X connect 3 1 4 0; #X connect 4 0 0 0; #X connect 5 0 6 0; #X connect 6 0 9 0; #X connect 7 0 10 0; #X connect 10 0 2 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] variable number of outlets/inlets
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
