[PD-dev] preserving connections of 'bogus' objects

[guenter geiger]

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 at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>