Ok cool. I will make a test build with Tcl/Tk 8.6.10:
Pd-0.51-0-tk8610.zip http://docs.danomatika.com/pdbuilds/0.51/Pd-0.51-0-tk8610.zip
On my system, I can confirm that the canvas window background is no longer white by default, so IOhannes patch to force this is required.
On Jul 15, 2020, at 11:25 AM, pd-list-request@lists.iem.at wrote:
Date: Wed, 15 Jul 2020 11:25:37 +0200 From: Antoine Villeret <antoine.villeret@gmail.com mailto:antoine.villeret@gmail.com> To: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] Pd 0.50-2 on macos 11.0 BigSur beta Message-ID: <CAGn5wNcmGG2mEZAW_s9DUmeDnkjEmuPhpjTYsdioF3_iDVFDkg@mail.gmail.com mailto:CAGn5wNcmGG2mEZAW_s9DUmeDnkjEmuPhpjTYsdioF3_iDVFDkg@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
You're right Dan, using Wish 8.6.10 works. 8.6.7 doesn't.
So upgrading WIsh is the key.
Thanks for your support
Best
Antoine
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Hi,
Getting desperate after spending hours to locate the error "inlet: expected 'signal' but got ‘bang’” I am getting from a fairly huge project, running in pd 0.49 on a raspberry pi.
The only object I am aware of being able to produce an error like this is the [inlet~]. After checking all subpatches I have not found any [inlet~] that has any non-signal patch cords connected.
Is anyone here aware of any other objects that might produce the above error message? The 'last error' feature does unfortunately not give a result or clue.
Thanks, Sebastian
Hi,
The only object I am aware of being able to produce an error like this is the [inlet~]
This error message is also shown whenever you send a bang to any signal inlet - except for the main inlet. Try to send a bang to the right inlet of [+~], for example.
The 'last error' feature does unfortunately not give a result or clue.
Maybe the offending object is inside a cloned abstraction? Pd can't locate such errors (yet).
Christof
PS: if you want to start a new thread, don't reply to an existing e-mail.
On 17.07.2020 00:48, Sebastian Lexer wrote:
Hi,
Getting desperate after spending hours to locate the error "inlet: expected 'signal' but got ‘bang’” I am getting from a fairly huge project, running in pd 0.49 on a raspberry pi.
The only object I am aware of being able to produce an error like this is the [inlet~]. After checking all subpatches I have not found any [inlet~] that has any non-signal patch cords connected.
Is anyone here aware of any other objects that might produce the above error message? The 'last error' feature does unfortunately not give a result or clue.
Thanks, Sebastian
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thank you all, particularly thank you Christof!
That the error messaging does not work within cloned abstractions the same as it does in normal patches was the key to finding the error!
Replacing the abstraction within clone with a single instance made it possible to use the last error find option available.
Thank again, Sebastian On 17 Jul 2020, 00:12 +0100, Christof Ressi info@christofressi.com, wrote:
Hi,
The only object I am aware of being able to produce an error like this is the [inlet~]
This error message is also shown whenever you send a bang to any signal inlet - except for the main inlet. Try to send a bang to the right inlet of [+~], for example.
The 'last error' feature does unfortunately not give a result or clue.
Maybe the offending object is inside a cloned abstraction? Pd can't locate such errors (yet). Christof PS: if you want to start a new thread, don't reply to an existing e-mail. On 17.07.2020 00:48, Sebastian Lexer wrote:
Hi,
Getting desperate after spending hours to locate the error "inlet: expected 'signal' but got ‘bang’” I am getting from a fairly huge project, running in pd 0.49 on a raspberry pi.
The only object I am aware of being able to produce an error like this is the [inlet~]. After checking all subpatches I have not found any [inlet~] that has any non-signal patch cords connected.
Is anyone here aware of any other objects that might produce the above error message? The 'last error' feature does unfortunately not give a result or clue.
Thanks, Sebastian
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Great!
BTW, Antoine already made a PR to fix this issue: https://github.com/pure-data/pure-data/pull/965
Christof
On 17.07.2020 10:41, Sebastian Lexer wrote:
Thank you all, particularly thank you Christof!
That the error messaging does not work within cloned abstractions the same as it does in normal patches was the key to finding the error!
Replacing the abstraction within clone with a single instance made it possible to use the last error find option available.
Thank again, Sebastian On 17 Jul 2020, 00:12 +0100, Christof Ressi info@christofressi.com, wrote:
Hi,
The only object I am aware of being able to produce an error like this is the [inlet~]
This error message is also shown whenever you send a bang to any signal inlet - except for the main inlet. Try to send a bang to the right inlet of [+~], for example.
The 'last error' feature does unfortunately not give a result or clue.
Maybe the offending object is inside a cloned abstraction? Pd can't locate such errors (yet).
Christof
PS: if you want to start a new thread, don't reply to an existing e-mail.
On 17.07.2020 00:48, Sebastian Lexer wrote:
Hi,
Getting desperate after spending hours to locate the error "inlet: expected 'signal' but got ‘bang’” I am getting from a fairly huge project, running in pd 0.49 on a raspberry pi.
The only object I am aware of being able to produce an error like this is the [inlet~]. After checking all subpatches I have not found any [inlet~] that has any non-signal patch cords connected.
Is anyone here aware of any other objects that might produce the above error message? The 'last error' feature does unfortunately not give a result or clue.
Thanks, Sebastian
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> On Thursday, July 16, 2020, 6:58:40 PM EDT, Sebastian Lexer <s.lexer@incalcando.com> wrote:
Hi,
Getting desperate after spending hours to locate the error "inlet: expected 'signal' but got ‘bang’” I am getting from a fairly huge project, running in pd 0.49 on a raspberry pi.
The only object I am aware of being able to produce an error like this is the [inlet~]. After checking all subpatches I have not found any [inlet~] that has any non-signal patch cords connected.
Is anyone here aware of any other objects that might produce the above error message? The 'last error' feature does unfortunately not give a result or clue.
"inlet" is actually a bit of an implementation detail here. "inlet" is it's own little class that handles messages on behalf of ancillary inlets of a given object. The error should probably say "inlet of x" where x is the class name for the object that owns the inlet.
At least in Purr Data[1], each error has a hyperlink which will focus the appropriate canvas with the relevant object highlighted. So the vague error message is less problematic (though I just added an issue for it anyway[2])
It's not discoverable in Pd Vanilla, but you should be able to do the same thing like this:
Best, Jonathan
Thanks, Sebastian _______________________________________________
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2020-07-17 03:58, Jonathan Wilkes via Pd-list wrote:
At least in Purr Data[1], each error has a hyperlink which will focus the appropriate canvas with the relevant object highlighted. So
that works the same for Pd-vanilla. the problem was, as christof explained, that it does *not* work (yet) for abstractions within a [clone] context.
gfmsdr IOhannes