Hi, I was asking people on facebook where did they get the idea of putting names in inlets/outlets, like: [inlet this-inlet-controls-frequency].
My reasoning is that it is a comment as an invalid argument and a bad practice, and then I heard this used to be a feature in some version of Pd where you'd get the name when passing the mouse over the inlet. Can someone confirm that? Which version/fork of Pd was that (I'm assuming it can't be vanilla)? Just really curious.
thanks
On Tuesday, March 2, 2021, 11:10:36 AM EST, Alexandre Torres Porres porres@gmail.com wrote:
Hi, I was asking people on facebook where did they get the idea of putting names in inlets/outlets, like: [inlet this-inlet-controls-frequency].
Not sure. But A_DEFSYM and A_DEFFLOAT are implemented in a way that allows an arbitrary number of extra float/symbol arguments, so it could be [inlet this inlet controls frequency]. Or following the [get] and [set] pattern-- [inlet - this inlet controls frequency] to skip over the first arg that is currently used for up/downsampling.
Someone asked on the Purr Data list about this. It would be easy to implement, but it doesn't cover the case of setting a description for the object itself. Plus I'd much rather just leverage the documentation index in the GUI to look up tooltip data.
-Jonathan
On 02/03/2021 17:45, Jonathan Wilkes via Pd-list wrote:
On Tuesday, March 2, 2021, 11:10:36 AM EST, Alexandre Torres Porres
porres@gmail.com wrote:
Hi, I was asking people on facebook where did they get the idea of
putting names in inlets/outlets, like: [inlet this-inlet-controls-frequency].
Not sure. But A_DEFSYM and A_DEFFLOAT are implemented in a way that allows an arbitrary number of extra float/symbol arguments, so it could be
[inlet this inlet controls frequency]. Or following the[get]and[set]pattern--[inlet - this inlet controls frequency]to skip over the first arg that is currently used for up/downsampling.Someone asked on the Purr Data list about this. It would be easy to implement, but it doesn't cover the case of setting a description for the object itself. Plus I'd much rather just leverage the documentation index in the GUI to look up tooltip data.
-Jonathan
Thanks for the pointers, I don't see this implemented in Extended (42/43) or in Purr Data by extension. By readng the discussion, the patch was never included in the distribution, right?
So it was more like a plan than a reality?
Em ter., 2 de mar. de 2021 às 15:20, Claude Heiland-Allen < claude@mathr.co.uk> escreveu:
On 02/03/2021 17:45, Jonathan Wilkes via Pd-list wrote:
On Tuesday, March 2, 2021, 11:10:36 AM EST, Alexandre Torres Porres
porres@gmail.com wrote:
Hi, I was asking people on facebook where did they get the idea of
putting names in inlets/outlets, like: [inlet this-inlet-controls-frequency].
Not sure. But A_DEFSYM and A_DEFFLOAT are implemented in a way that allows an arbitrary number of extra float/symbol arguments, so it could be
[inlet this inlet controls frequency]. Or following the[get]and[set]pattern--[inlet - this inlet controls frequency]to skip over the first arg that is currently used for up/downsampling.Someone asked on the Purr Data list about this. It would be easy to implement, but it doesn't cover the case of setting a description for the object itself. Plus I'd much rather just leverage the documentation index in the GUI to look up tooltip data.
-Jonathan
https://download.puredata.info/dev/InletDescriptions
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Tuesday, March 2, 2021, 1:57:43 PM EST, Alexandre Torres Porres porres@gmail.com wrote: Thanks for the pointers, I don't see this implemented in Extended (42/43) or in Purr Data by extension. By readng the discussion, the patch was never included in the distribution, right?
AFAICT, the example code linked there has never been included in any implementation. Pd-l2ork 1.0 has tooltips, but they don't use any of the code in that link. -Jonathan
So it was more like a plan than a reality?
Em ter., 2 de mar. de 2021 às 15:20, Claude Heiland-Allen claude@mathr.co.uk escreveu:
On 02/03/2021 17:45, Jonathan Wilkes via Pd-list wrote:
On Tuesday, March 2, 2021, 11:10:36 AM EST, Alexandre Torres Porres
porres@gmail.com wrote:
Hi, I was asking people on facebook where did they get the idea of
putting names in inlets/outlets, like: [inlet this-inlet-controls-frequency].
Not sure. But A_DEFSYM and A_DEFFLOAT are implemented in a way that allows an arbitrary number of extra float/symbol arguments, so it could be
[inlet this inlet controls frequency]. Or following the[get]and[set]pattern--[inlet - this inlet controls frequency]to skip over the first arg that is currently used for up/downsampling.Someone asked on the Purr Data list about this. It would be easy to implement, but it doesn't cover the case of setting a description for the object itself. Plus I'd much rather just leverage the documentation index in the GUI to look up tooltip data.
-Jonathan
https://download.puredata.info/dev/InletDescriptions
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
Em ter., 2 de mar. de 2021 às 16:26, Jonathan Wilkes jancsika@yahoo.com escreveu:
Pd-l2ork 1.0 has tooltips
hmm, but how does it work? Does it show the symbol from an inlet argument? If so, there is in fact a version of Pd that implements this.
On Tuesday, March 2, 2021, 2:48:36 PM EST, Alexandre Torres Porres porres@gmail.com wrote:
Em ter., 2 de mar. de 2021 às 16:26, Jonathan Wilkes jancsika@yahoo.com escreveu:
Pd-l2ork 1.0 has tooltips
hmm, but how does it work?
By fetching the data from [pd META] subpatches in help patches, which is the same across abstractions, binary externals, and internal classes.
Does it show the symbol from an inlet argument?
Nope. I knew one *could* abuse inlet(~)/outlet(~) to write descriptions of the data flowing, but I didn't know until last week that anyone was actually using it to do that in practice.
I'd strongly advise investigating a way to implement tooltips that is more robust-- one that handles cases for externals as well as showing a general description when mousing over the main rectangle of an object.
Otherwise you'll end up with something like Cascading Style Sheets where the data for tips is scattered all over the place, or tooltip data in one place overrides tooltip data in another, etc.
-Jonathan
If so, there is in fact a version of Pd that implements this.
On Tuesday, March 2, 2021, 1:19:53 PM EST, Claude Heiland-Allen claude@mathr.co.uk wrote: On 02/03/2021 17:45, Jonathan Wilkes via Pd-list wrote:
On Tuesday, March 2, 2021, 11:10:36 AM EST, Alexandre Torres Porres
porres@gmail.com wrote:
Hi, I was asking people on facebook where did they get the idea of
putting names in inlets/outlets, like: [inlet this-inlet-controls-frequency].
Not sure. But A_DEFSYM and A_DEFFLOAT are implemented in a way that allows an arbitrary number of extra float/symbol arguments, so it could be
[inlet this inlet controls frequency]. Or following the[get]and[set]pattern--[inlet - this inlet controls frequency]to skip over the first arg that is currently used for up/downsampling.Someone asked on the Purr Data list about this. It would be easy to implement, but it doesn't cover the case of setting a description for the object itself. Plus I'd much rather just leverage the documentation index in the GUI to look up tooltip data.
-Jonathan https://download.puredata.info/dev/InletDescriptions
Yeah, perhaps they got it by somehow discovering that ancient scroll. :)
Anyhow, Albert Graef recently made a nice caching system for the Purr Data doc index. Leveraging that, I *think* I can now add tooltips, completely in the GUI of Purr Data, and only require a single extra string to be sent from the backend on object creation. At that point tooltips would be the cost of essentially looking up a key in JSON, and the cost of the additional DOM element to display it on hover (which would be zero if tooltips are disabled). -Jonathan
The idea doesn't sound bad, it'd be a nice GUI feature. As for the design, I think you'd need a special flag to set the name and not just some symbol, this way you'd not get into conflicts with the actual arguments.
Well, anyway, someone started abusing the fact that the object doesn't complain about invalid arguments and now I can only see this as a bad practice indeed. I like to joke that Pd will not complain if you create [osc~ 440 hz (cycles per second)], but that doesn't mean you should do it :)
Em ter., 2 de mar. de 2021 às 14:46, Jonathan Wilkes jancsika@yahoo.com escreveu:
On Tuesday, March 2, 2021, 11:10:36 AM EST, Alexandre Torres Porres <
porres@gmail.com> wrote:
Hi, I was asking people on facebook where did they get the idea of
putting names in inlets/outlets, like: [inlet this-inlet-controls-frequency].
Not sure. But A_DEFSYM and A_DEFFLOAT are implemented in a way that allows an arbitrary number of extra float/symbol arguments, so it could be
[inlet this inlet controls frequency]. Or following the[get]and[set]pattern--[inlet - this inlet controls frequency]to skip over the first arg that is currently used for up/downsampling.Someone asked on the Purr Data list about this. It would be easy to implement, but it doesn't cover the case of setting a description for the object itself. Plus I'd much rather just leverage the documentation index in the GUI to look up tooltip data.
-Jonathan
On Tuesday, March 2, 2021, 2:11:36 PM EST, Alexandre Torres Porres porres@gmail.com wrote: The idea doesn't sound bad, it'd be a nice GUI feature. As for the design, I think you'd need a special flag to set the name and not just some symbol, this way you'd not get into conflicts with the actual arguments.
I have no plans to implement it that way, and the tooltip implementation we wrote in Pd-l2ork 1.0 draws directly from the help patches for its tooltip data. However, if it turns out that a sizable number of users are abusing inlet(~)/outlet(~) args that way and they really want it displayed in the tooltip, I'll revisit it. -Jonathan
Well, anyway, someone started abusing the fact that the object doesn't complain about invalid arguments and now I can only see this as a bad practice indeed. I like to joke that Pd will not complain if you create [osc~ 440 hz (cycles per second)], but that doesn't mean you should do it :)
-
Alexandre Torres Porres -
Claude Heiland-Allen -
Jonathan Wilkes