[PD] Ability to access error messages from patch

Miller Puckette msp at ucsd.edu
Mon Jun 14 18:10:50 CEST 2021


Here's another idea: a "catch" object that passes messages from inlet to outlet, but
then reports errors (somehow or other) only when those errors occur while forwarding
the message.

cheers
M

On Mon, Jun 14, 2021 at 04:01:15PM +0200, oliver wrote:
> Christof Ressi wrote:
> > 
> > > i quite like the idea of having a canvas-scope for such an object.
> > Personally, I would rather prefer that if the error code would be simply
> > output by the same object that generated the error.
> 
> that can take a long time, even for vanilla objects ;-)
> 
> and there are so many 3rd party objects out there that would all need to be
> modified and re-released in order to fit these quite specific needs.
> 
> if it's not too big a project (IOhannes must decide), i think that such an
> object (like [canvaserror]) would do no harm to "everyday users" and would
> at least be very handy for those who have a need for it.
> 
> > 
> > > On 6/14/21 10:37 AM, Peter P. wrote:
> > > > Yes, that's a good idea, but what if there are two identical objects
> > > > on the same canvas?
> > > 
> > > i think that would be *your* problem.
> > > if you want to catch error messages from two instances of the same
> > > objectclass, just put them into separate canvases.
> > > simple as that.
> > I think Peter's concern is valid and it's actually another reason why I
> > wouldn't like such a design.
> 
> since it would be part of IEMGUTS (which i think is where it belongs to),
> people usually know what they let themselves in for and would design their
> patches accordingly. for example, there's no real need for more than one
> [soundfiler] or [text define] objects in a canvas...
> 
> > 
> > Here's another idea, which I don't really love, but which I would prefer
> > over your proposed [canvaserror]:
> > 
> > Method calls which can generate an error send the error code to a global
> > [errno] object and the user can query the current error state with a
> > bang. This would be similar to 'errno' in C.
> > 
> > If the user queries the errno immediately after the method call, Pd's
> > determinism guarantees that the error really belongs to that method
> > call. We would have to reserve a special value (e.g. "0") to mean "no
> > error".
> 
> sounds nice, too. but it wouldn't verbosely specify the type of error, like
> the console output, would it ?
> 
> just my 2c
> 
> best
> 
> oliver
> 
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=8gelwsvceCfl8S54qwd_2K-7Ux1KXfqZmtASQ37VoS0&s=wIaD2xQChyOMZtLEyKYCnIgKliS1TuNuk-shjiuaJGY&e=

-- 





More information about the Pd-list mailing list