atom feed7 messages in at.iem.pd-devRe: [PD-dev] preserving connections o...
FromSent OnAttachments
Krzysztof CzajaSep 16, 2003 2:59 am 
guenter geigerSep 16, 2003 7:11 am 
Mathieu BouchardSep 16, 2003 8:44 am 
Miller PucketteSep 16, 2003 9:11 am 
pixSep 16, 2003 5:50 pm 
Mathieu BouchardSep 16, 2003 7:10 pm 
Krzysztof CzajaSep 17, 2003 5:27 am 
Subject:Re: [PD-dev] preserving connections of 'bogus' objects
From:Miller Puckette (mpuc@man104-1.ucsd.edu)
Date:Sep 16, 2003 9:11:04 am
List:at.iem.pd-dev

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.