Hi developers,
say I have an abstraction having one (control) inlet and one (control) outlet and an external with the same number of inlets/outlets that does nothing by it's own. What I now would like to do is to 'load' the abstraction into may external instead of loading it as a 'stand-alone object'. Thus my external would always be there but I could load different abstractions into it. Would that be possible without having to write a second Pd in an external?
I tried some things but it all ended up in a new canvas popping up containing my abstraction (or parts of it or even parts of the calling patch...).
please enlighten me!
Olaf
Hi Olaf!
in the attached zip you'll find a test patch for abstraction loading and linking. I took send and receive instead of inlet and outlet, because it makes dynamic-linking much easier.
I hope that is what you meant...
leo
----- Original Message ----- From: Olaf Matthes olaf.matthes@gmx.de To: PD dev pd-dev@iem.kug.ac.at Sent: Friday, September 20, 2002 10:44 AM Subject: [PD-dev] loading abstractions into objcts...?
Hi developers,
say I have an abstraction having one (control) inlet and one (control) outlet and an external with the same number of inlets/outlets that does nothing by it's own. What I now would like to do is to 'load' the abstraction into may external instead of loading it as a 'stand-alone object'. Thus my external would always be there but I could load different abstractions into it. Would that be possible without having to write a second Pd in an external?
I tried some things but it all ended up in a new canvas popping up containing my abstraction (or parts of it or even parts of the calling patch...).
please enlighten me!
Olaf
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hi Olaf, list
This is similar to a problem that I've just spent some time working on: a poly~ style object/abstraction array container object. I've been writing this as a pd internal object because I don't think that it can easily be done from a external(?). I'd appreciate any help/comments from those who've delved inside PD more than I.
Apologies to Olaf - there are more questions than answers here.
I've pasted in the constructor at the end of the message.
Things to note: This works for objects or abstractions and dynamically creates the inlets and outlets according to the contained object.
I'm using an inlet proxy object (called ainlet) which is basically vinlet but without the canvas references. I attach each my object's inlets to an ainlet (which simply forwards its input to its output). Then I connect (using obj_connect) each ainlet to the inlets of the currently indexed container member object. Similarly, I'm using an outlet proxy object.
Is it possible to avoid the proxy objects in any way? I couldn't see a way of having multiple inlets on an object that could forward to other inlets on a contained object (and ideally to multiple inlets for an omni mode)?
Things not supported (yet): - Introspection into the contained object/abstraction. I think that I can just make a canvas visible somehow? - Signals. (Should be straightforward, I think... it might even work already...?)
Other questions: - How can this be done better? - Can this be done as an external? - Should I just programmatically create a canvas with my objects (inlets and outlets) in it and connect them together (avoids custom ainlet/aoutlet classes). - Should this object just be a specialization of the canvas class?
Thanks, Daniel
static void *objarray_new(t_symbol *s, int argc, t_atom *argv) { t_objarray *x = NULL;
if (argc >= 2) { int i;
x = (t_objarray *)pd_new(objarray_class); x->x_nobj = atom_getfloat(&argv[argc-1]); x->x_index = -1; x->x_objname = atom_getsymbol(&argv[0]); x->x_objarray = (t_object**)getbytes(x->x_nobj * sizeof(t_object*));
// make the object array for (i = 0; i < x->x_nobj; i++) { pd_typedmess(&pd_objectmaker, x->x_objname, argc-2, argv+2); x->x_objarray[i] = (t_object*)newest; if (newest && pd_class(newest) == canvas_class) canvas_loadbang((t_canvas *)newest); }
// make the inlet and outlet arrays x->x_ninlets = obj_ninlets(x->x_objarray[0]); x->x_noutlets = obj_noutlets(x->x_objarray[0]); x->x_inarray = (t_ainlet**)getbytes(x->x_ninlets * sizeof(t_ainlet*)); x->x_outarray = (t_aoutlet**)getbytes(x->x_noutlets * sizeof(t_aoutlet*));
// make the inlets for (i = 0; i < x->x_ninlets; i++) { x->x_inarray[i] = ainlet_new(NULL); inlet_new(&x->x_obj, &x->x_inarray[i]->x_obj.ob_pd, 0, 0); }
// make the outlets for (i = 0; i < x->x_noutlets; i++) { x->x_outarray[i] = aoutlet_new(outlet_new(&x->x_obj, NULL)); }
// make the index inlet inlet_new(&x->x_obj, &x->x_obj.ob_pd, &s_float, gensym("index")); } else error("objarray: usage [objarray object_name <args> array_size]"); }
Daniel
-----Original Message----- From: pd-dev-admin@iem.kug.ac.at [mailto:pd-dev-admin@iem.kug.ac.at]On Behalf Of Olaf Matthes Sent: Friday, 20 September 2002 6:44 PM To: PD dev Subject: [PD-dev] loading abstractions into objcts...?
Hi developers,
say I have an abstraction having one (control) inlet and one (control) outlet and an external with the same number of inlets/outlets that does nothing by it's own. What I now would like to do is to 'load' the abstraction into may external instead of loading it as a 'stand-alone object'. Thus my external would always be there but I could load different abstractions into it. Would that be possible without having to write a second Pd in an external?
I tried some things but it all ended up in a new canvas popping up containing my abstraction (or parts of it or even parts of the calling patch...).
please enlighten me!
Olaf
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hi Daniel and list,
it seems we've created very similar things... Based on Krzysztof's rabin~ code I've made an external called 'clone' that can load several instances of an abstraction. A first experimental prerelease can be found at http://www.akustische-kunst.org/puredata/clone/ (Win and OS X at the moment; but should compile for Linux as well). See the attached PDF for a short overview what it does.
Daniel Heckenberg schrieb:
Is it possible to avoid the proxy objects in any way?
Why? - 'clone' uses proxy inlets / outlets as well and I haven't found any other way to do it.
- Signals. (Should be straightforward, I think... it might even work
already...?)
... have a look at clone (or rabin~) to see how it could be done.
- Can this be done as an external?
Yes and now. Your solution calls a lot of Pd's internal routines which aren't exportet. On the other hand it's possible to use other functions to do (nearly) the same thing.
- Should I just programmatically create a canvas with my objects (inlets
and outlets) in it and connect them together (avoids custom ainlet/aoutlet classes).
If you mean dynamic patching I guess it depends on what you want to do. If you need it to be dynamic while your abstraction is running it's probably a good idea. In case you just want to load a fixed abstraction it's at least easier to create just one object box instead of all the things needed to build your abstraction dynamically...
Olaf
Hi Olaf, list
it seems we've created very similar things... Based on Krzysztof's rabin~ code I've made an external called 'clone' that can load several instances of an abstraction. A first experimental prerelease can be found at http://www.akustische-kunst.org/puredata/clone/ (Win and OS X at the moment; but should compile for Linux as well). See the attached PDF for a short overview what it does.
Great - looks nice.
Is it possible to avoid the proxy objects in any way?
Why? - 'clone' uses proxy inlets / outlets as well and I haven't found any other way to do it.
simply to avoid the parsing that goes on.
- Signals. (Should be straightforward, I think... it might even work
already...?)
... have a look at clone (or rabin~) to see how it could be done.
yup - thanks that does look quite straightforward
- Can this be done as an external?
Yes and now. Your solution calls a lot of Pd's internal routines which aren't exportet. On the other hand it's possible to use other functions to do (nearly) the same thing.
yes - I started off as an internal so I could call PD code without duplicating its functionality. Can someone tell me if there's a way to get the "newest" object from an external?
I figure that I should carefully look at the S__N and S__X symbols to get a hang of how they're used.
- Should I just programmatically create a canvas with my
objects (inlets
and outlets) in it and connect them together (avoids custom
ainlet/aoutlet
classes).
If you mean dynamic patching I guess it depends on what you want to do. If you need it to be dynamic while your abstraction is running it's probably a good idea. In case you just want to load a fixed abstraction it's at least easier to create just one object box instead of all the things needed to build your abstraction dynamically...
I was suggesting doing the dynamic patching programmatically... trying to avoid any duplication of PD internal code and make a clone/array that is more robust.
I'm glad that these objects have appeared - very useful and nice to avoid having to script any dynamic patching stuff which always seems like a step out of the patching paradigm.
As an aside, is it really true that nobody has created an sprintf external for PD yet? Now there's a project for this weekend...
Daniel
hi Daniel and all,
Daniel Heckenberg wrote: ...
Can someone tell me if there's a way to get the "newest" object from an external?
it is visible on linux, but hidden otherwise -- do not use it then. I really do think something like pd_newest() call would be very handy (please...)
...
I was suggesting doing the dynamic patching programmatically... trying to avoid any duplication of PD internal code and make a clone/array that is more robust.
there is the nqpoly~ by pix, which uses a very heavy dynamic patching, and does the job nicely. In the long run, though, I do not think dynamic patching can be robust?
The code duplication itself, which is minimal, is not a problem -- the hard part is how to keep up with future changes of the Pd's internal code. The API is the way to go, if there is any...
But the worst of all solutions would be to make an abstraction embedder class through modifying Pd's internal code, just for the sake of the current project needs.
...
As an aside, is it really true that nobody has created an sprintf external for PD yet? Now there's a project for this weekend...
it is in the cyclone (please test and report:)
Krzysztof
(since sooner or later a poly~-compatible external will be included in the cyclone library, or whatever name will it be called then, so if you intend to work on this, let us be in touch...)
Hi Krzysztof et all,
The code duplication itself, which is minimal, is not a problem -- the hard part is how to keep up with future changes of the Pd's internal code. The API is the way to go, if there is any...
Exactly... an API to clarify and support this kind of thing for externals would be great.
But the worst of all solutions would be to make an abstraction embedder class through modifying Pd's internal code, just for the sake of the current project needs.
Point well taken.
...
As an aside, is it really true that nobody has created an
sprintf external
for PD yet? Now there's a project for this weekend...
it is in the cyclone (please test and report:)
Shall do. Thanks for the pointer.
(since sooner or later a poly~-compatible external will be included in the cyclone library, or whatever name will it be called then, so if you intend to work on this, let us be in touch...)
I'd certainly like to have a poly~ style object (and why not make it compatible?). My immediate needs may be served by rabin/clone/my-quick-and-dirty-hack but it would be good to develop a fully functional object. Thanks to you and Olaf for producing that code, btw.
How to proceed?
Daniel
Daniel Heckenberg schrieb:
I'd certainly like to have a poly~ style object (and why not make it compatible?). My immediate needs may be served by rabin/clone/my-quick-and-dirty-hack but it would be good to develop a fully functional object. Thanks to you and Olaf for producing that code, btw.
How to proceed?
Hi Daniel,
if you 'only' need a poly~-style object it should be easier to overcome the limitations of the current solutions, I think. The crashes when adding or deleting inlets / outlets are caused because Pd attempts to recreate your object box. poly~ uses it's own type of inlets (in, out, in~, out~). By adopting this it should be possible to implement this feature in rabin~/clone and possibly your code.
I'm not going to implement it right now (clone does everything I need...). But this could be a good project for the long dark winter nights to come...
Olaf
hi Daniel, Olaf, Miller?...
would be nice to make poly~ into the cyclone, but I do not know how to proceed, not having:
1. inlets accepting both signal, and control input, and
2. editable glist structure without an associated object box (I have tried to formulate this idea into a ``feature request'' some time ago, but failed to do that properly, and chickened out...)
Krzysztof
(these are two easy adjustments, btw)
Olaf Matthes wrote:
Daniel Heckenberg schrieb:
...
I'd certainly like to have a poly~ style object (and why not make it
...
How to proceed?
...
if you 'only' need a poly~-style object it should be easier to overcome the limitations of the current solutions, I think. The crashes when adding or deleting inlets / outlets are caused because Pd attempts to recreate your object box. poly~ uses it's own type of inlets (in, out, in~, out~). By
-
Daniel Heckenberg -
Krzysztof Czaja -
lsw -
Olaf Matthes