hi all,
sorry for a longish post, and for dealing with what is surely not a high priority feature... Anyway, I will gladly hear from other devs about their views.
What I have in mind, is that during object creation, when the requested class is not known, and there is no matching abstraction, a `failsafe' replacement object is used. Currently in Pd, it has never any inlets nor outlets, even if loaded from a patch with the original object connected. (A slightly different case, and apparently easier to deal with, is an already patched up object, edited into a ``couldn't create'' nop by the user.)
Currently in Max, such creatures, called `bogus' objects, do preserve connections.
The newest cyclone's import feature creates connection-preserving replacements of all unknowns. The implementation is pretty straightforward:
. for every object of unknown class, create a bogus having as many inlets and outlets, as any sane object is ever likely to have;
. then, after the entire binbuf representation of a file has been evaluated, broadcast a request to all newly created bogus objects, making them adjust both their ports (delete every inlet/outlet right to the last connected one), and their text (delete the '_port.bogus' prefix).
For details, search for 'bogus' in miXed/shared/common/port.c in cvs.
This is simplistic, in a way, but I would rather avoid an additional parsing pass through the binbuf, and avoid maintaining an auxiliary data structure.
In the cyclone's case of an import-only mechanism supplied by an external library, the tricky part is to support the actual notion of an ``unknown class''. This is not just a class not yet defined, but such, that is also going to fail an attempt to load its library and abstraction files. Maintaining a specialized replacement of the binbuf_eval() routine would have been an even bigger evil, so I had to fake it -- by blocking all possible library/abstraction loading attempts from within binbuf_eval(), i.e. by temporary marking as `bogus' (during Max-to-Pd binbuf conversion stage) all objects of not yet defined classes.
Thus, in the import-only implementation, the library/abstraction loading attempt is always performed in the constructor of a bogus, which, in case of a successful loading, transforms itself into a `reclaimed' object proper. However, for every reclaimed object, in order to get rid of a '_port.bogus' prefix, a temporary `hook' has to be created, then invoked, and finally destroyed...
(Btw, this part could have been less clumsy, somewhat, if there were bindlist traversal routines in the API.)
In short, it seems to work, but I have a vague feeling, that a general mechanism would be much simpler (and more useful too). Otoh, without more research, I have a feeling of having too narrow a perspective for just starting to mess with Pd's way of creating objects.
Krzysztof
Hmm, wouldn't it be enough to just have a bogus object with some ins and outs as default, and not dealing with ajusting the numer of inlets/outlets as you suggest. You never know how many inlets and outlets the original object had, so whats the point in trying to guess them ?
This should not be to drastic a change within pd. Anyhow, to make these elements visible they should have another (red) color.
Guenter
On Tue, 16 Sep 2003, Krzysztof Czaja wrote:
hi all,
sorry for a longish post, and for dealing with what is surely not a high priority feature... Anyway, I will gladly hear from other devs about their views.
What I have in mind, is that during object creation, when the requested class is not known, and there is no matching abstraction, a `failsafe' replacement object is used. Currently in Pd, it has never any inlets nor outlets, even if loaded from a patch with the original object connected. (A slightly different case, and apparently easier to deal with, is an already patched up object, edited into a ``couldn't create'' nop by the user.)
Currently in Max, such creatures, called `bogus' objects, do preserve connections.
The newest cyclone's import feature creates connection-preserving replacements of all unknowns. The implementation is pretty straightforward:
. for every object of unknown class, create a bogus having as many inlets and outlets, as any sane object is ever likely to have;
. then, after the entire binbuf representation of a file has been evaluated, broadcast a request to all newly created bogus objects, making them adjust both their ports (delete every inlet/outlet right to the last connected one), and their text (delete the '_port.bogus' prefix).
For details, search for 'bogus' in miXed/shared/common/port.c in cvs.
This is simplistic, in a way, but I would rather avoid an additional parsing pass through the binbuf, and avoid maintaining an auxiliary data structure.
In the cyclone's case of an import-only mechanism supplied by an external library, the tricky part is to support the actual notion of an ``unknown class''. This is not just a class not yet defined, but such, that is also going to fail an attempt to load its library and abstraction files. Maintaining a specialized replacement of the binbuf_eval() routine would have been an even bigger evil, so I had to fake it -- by blocking all possible library/abstraction loading attempts from within binbuf_eval(), i.e. by temporary marking as `bogus' (during Max-to-Pd binbuf conversion stage) all objects of not yet defined classes.
Thus, in the import-only implementation, the library/abstraction loading attempt is always performed in the constructor of a bogus, which, in case of a successful loading, transforms itself into a `reclaimed' object proper. However, for every reclaimed object, in order to get rid of a '_port.bogus' prefix, a temporary `hook' has to be created, then invoked, and finally destroyed...
(Btw, this part could have been less clumsy, somewhat, if there were bindlist traversal routines in the API.)
In short, it seems to work, but I have a vague feeling, that a general mechanism would be much simpler (and more useful too). Otoh, without more research, I have a feeling of having too narrow a perspective for just starting to mess with Pd's way of creating objects.
Krzysztof
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Tue, 16 Sep 2003, Krzysztof Czaja wrote:
What I have in mind, is that during object creation, when the requested class is not known, and there is no matching abstraction, a `failsafe' replacement object is used. Currently in Pd, it has never any inlets nor outlets, even if loaded from a patch with the original object connected. (A slightly different case, and apparently easier to deal with, is an already patched up object, edited into a ``couldn't create'' nop by the user.)
Currently in Max, such creatures, called `bogus' objects, do preserve connections.
This is also a feature of jMax, which draws such objects in lightgray instead of white. That this feature is not present is a bit of an annoyance. It makes it not very much possible to look at a patch just for looking at it, without having the external.
This would be important to look at example patches for an external that is not installed yet, as a preview of what the external would be used and such. Well I don't know if many people do that, but sometimes I happen to.
Another possibly more important problem is when you change an object at runtime and make a mistake and then the object loses all its inlets/outlets and all associated connections (!). At least now there's Ctrl+Z that makes it less of a problem.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
I agree... I'll do this for 0.38... I actually write that feature of jMax but haven't got around to re-introducing it.
cheers Miller
On Tue, Sep 16, 2003 at 11:45:04AM -0400, Mathieu Bouchard wrote:
On Tue, 16 Sep 2003, Krzysztof Czaja wrote:
What I have in mind, is that during object creation, when the requested class is not known, and there is no matching abstraction, a `failsafe' replacement object is used. Currently in Pd, it has never any inlets nor outlets, even if loaded from a patch with the original object connected. (A slightly different case, and apparently easier to deal with, is an already patched up object, edited into a ``couldn't create'' nop by the user.)
Currently in Max, such creatures, called `bogus' objects, do preserve connections.
This is also a feature of jMax, which draws such objects in lightgray instead of white. That this feature is not present is a bit of an annoyance. It makes it not very much possible to look at a patch just for looking at it, without having the external.
This would be important to look at example patches for an external that is not installed yet, as a preview of what the external would be used and such. Well I don't know if many people do that, but sometimes I happen to.
Another possibly more important problem is when you change an object at runtime and make a mistake and then the object loses all its inlets/outlets and all associated connections (!). At least now there's Ctrl+Z that makes it less of a problem.
Mathieu Bouchard http://artengine.ca/matju
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
this reminds me of a feature which i have long thought would be useful, and that fits well with the (not so) new connection-selecting behaviour.
it would be nice if there was a key which would "intersect" an existing connection, and replace it with a pass-through object (either [inlet~]->[outlet~] or [inlet]->[outlet]). this object could be later edited into something else, in order to live-edit a patch without having to disconnect/reconnect objects.
for example:
[osc~ 100] -> [dac~]
select, the connection, hit the intersect button, and it becomes
[osc~ 100] -> [nop~] -> [dac~]
then the nop object could be edited into something useful, potentially with no interruption to audio:
[osc~ 100] -> [*~ 1] -> [dac~]
then a number box could be patched into the second inlet of the *~ object, and you have added volume control without having to stop the patch.
is this too wacky?
pix.
On Tue, 16 Sep 2003 09:11:26 -0700 Miller Puckette mpuckett@man104-1.ucsd.edu wrote:
I agree... I'll do this for 0.38... I actually write that feature of jMax but haven't got around to re-introducing it.
cheers Miller
On Tue, Sep 16, 2003 at 11:45:04AM -0400, Mathieu Bouchard wrote:
On Tue, 16 Sep 2003, Krzysztof Czaja wrote:
What I have in mind, is that during object creation, when the requested class is not known, and there is no matching abstraction, a`failsafe' replacement object is used. Currently in Pd, it has never any inlets nor outlets, even if loaded from a patch with the original object connected. (A slightly different case, and apparently easier to deal with, is an already patched up object, edited into a``couldn't create'' nop by the user.)
Currently in Max, such creatures, called `bogus' objects, do preserve connections.
This is also a feature of jMax, which draws such objects in lightgray instead of white. That this feature is not present is a bit of an annoyance. It makes it not very much possible to look at a patch just for looking at it, without having the external.
This would be important to look at example patches for an external that is not installed yet, as a preview of what the external would be used and such. Well I don't know if many people do that, but sometimes I happen to.
Another possibly more important problem is when you change an object at runtime and make a mistake and then the object loses all its inlets/outlets and all associated connections (!). At least now there's Ctrl+Z that makes it less of a problem.
Mathieu Bouchard http://artengine.ca/matju
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Wed, 17 Sep 2003, pix wrote:
[osc~ 100] -> [dac~] select, the connection, hit the intersect button, and it becomes [osc~ 100] -> [nop~] -> [dac~] then the nop object could be edited into something useful, potentially with no interruption to audio: [osc~ 100] -> [*~ 1] -> [dac~] then a number box could be patched into the second inlet of the *~ object, and you have added volume control without having to stop the patch. is this too wacky?
When I was VJing (an imposture...), showing off the effects of GridFlow and making new ones as I was going, I happened to wish I had the possibility of not interrupting the flow of grids, because the way it is right now, it's not visually smooth... But I still had to disconnect and reconnect, which takes 1 second unless I make a mistake. Still, æsthetically speaking, that may be significant, especially in fast-looking effects.
So I vote yes for this feature, and I request its complement as well:
Selecting a component and hitting a special deletion key (for example Ctrl+Del ?) would merge the wire(s) of its inlet 0 with the wire(s) of its outlet 0, and delete the object itself, in one pass.
So those two features allow to expand and shrink a chain of components without interrupting anything.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
Miller Puckette wrote:
I agree... I'll do this for 0.38... I actually write that feature of jMax but haven't got around to re-introducing it.
indeed... and it is so simple and obvious -- porting seems like a couple of lines in obj_connect(), plus defining a 'bogus_class'.
Nice to know, I will be able to get rid of the clumsy _port.bogus thing soon...
Krzysztof
-
guenter geiger -
Krzysztof Czaja -
Mathieu Bouchard -
Miller Puckette -
pix