HI,
I had a try on implementing tooltips, just commited to CVS. Feedback is welcome.
Generally youonly have to add a description what every inlet does in your abstractions:
|inlet frequency|
and you should be able to see it in edit mode from outside. turn it on and off with |;pd tooltips 1< |;pd tooltips 0< (its on by default). Especially feedback from win and osx is appreciated. What is missing is the information for the builtin objects, which can be added easily when the system proved to be useful.
Guenter
great idea!
i guess PD would be even more popular than it is now with more user-and-newbie-friendly things like that
oliver
Quoting guenter geiger geiger@xdv.org:
HI,
I had a try on implementing tooltips, just commited to CVS. Feedback is welcome.
Generally youonly have to add a description what every inlet does in your abstractions:
|inlet frequency|
and you should be able to see it in edit mode from outside. turn it on and off with |;pd tooltips 1< |;pd tooltips 0< (its on by default). Especially feedback from win and osx is appreciated. What is missing is the information for the builtin objects, which can be added easily when the system proved to be useful.
Guenter
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
------------------------------------------- sent through klingt.org webmail -------------------------------------------
is this implemented for externals as well? or just abstractions, by adding arguments to [inlet]? [outlet] too?
it sounds like a very useful extension.
guenter geiger wrote:
HI,
I had a try on implementing tooltips, just commited to CVS. Feedback is welcome.
Generally youonly have to add a description what every inlet does in your abstractions:
|inlet frequency|
and you should be able to see it in edit mode from outside. turn it on and off with |;pd tooltips 1< |;pd tooltips 0< (its on by default). Especially feedback from win and osx is appreciated. What is missing is the information for the builtin objects, which can be added easily when the system proved to be useful.
Guenter
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
------ http://USFamily.Net/info - Unlimited Internet - From $8.99/mo! ------
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
What is missing is the information for the builtin objects, which can be added easily when the system proved to be useful.
If you do so, please take a look at how flext provides hooks for xlet descriptions. I never looked at them more closely, but I guess those are simply not implemented in the Pd backend, but they are in Max and it would be cool to have it compatible.
ciao
If you do so, please take a look at how flext provides hooks for xlet descriptions. I never looked at them more closely, but I guess those are simply not implemented in the Pd backend, but they are in Max and it would be cool to have it compatible.
Yes it's true. Flext provides the means to define the tooltip text, but as there's no respective api function in PD it doesn't do anything with it. Yet.
greetings, Thomas
On Wed, 26 Nov 2003, Thomas Grill wrote:
If you do so, please take a look at how flext provides hooks for xlet descriptions. I never looked at them more closely, but I guess those are simply not implemented in the Pd backend, but they are in Max and it would be cool to have it compatible.
Yes it's true. Flext provides the means to define the tooltip text, but as there's no respective api function in PD it doesn't do anything with it. Yet.
I implemented them in the osc~, but I am not sure yet about the synthax. The strange thing is actually, that the first inlet isn't a real inlet, so the synthax is weird. You register the first inlet's text with the class, and the second with the inlet itself.
This reflects the internal structure, but it's not intuitive to use, so I might change that interface.
Guenter
greetings, Thomas
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
That's cool :) I like it. My first impression is that it's better than having it in some status area of a window...
So... how about the outlets :)
cheers. ./MiS
On Tue, 2003-11-25 at 15:05, guenter geiger wrote:
HI,
I had a try on implementing tooltips, just commited to CVS. Feedback is welcome.
Generally youonly have to add a description what every inlet does in your abstractions:
|inlet frequency|
and you should be able to see it in edit mode from outside. turn it on and off with |;pd tooltips 1< |;pd tooltips 0< (its on by default). Especially feedback from win and osx is appreciated. What is missing is the information for the builtin objects, which can be added easily when the system proved to be useful.
Guenter
On Tue, 25 Nov 2003, Michal Seta wrote:
That's cool :) I like it. My first impression is that it's better than having it in some status area of a window...
So... how about the outlets :)
.. will come next ...
Guenter
cheers. ./MiS
On Tue, 2003-11-25 at 15:05, guenter geiger wrote:
HI,
I had a try on implementing tooltips, just commited to CVS. Feedback is welcome.
Generally youonly have to add a description what every inlet does in your abstractions:
|inlet frequency|
and you should be able to see it in edit mode from outside. turn it on and off with |;pd tooltips 1< |;pd tooltips 0< (its on by default). Especially feedback from win and osx is appreciated. What is missing is the information for the builtin objects, which can be added easily when the system proved to be useful.
Guenter
-- Michal Seta mis@creazone.32k.org
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
guenter geiger wrote:
HI,
I had a try on implementing tooltips, just commited to CVS. Feedback is welcome.
Generally youonly have to add a description what every inlet does in your abstractions:
|inlet frequency|
the only problem with this is, that signal-[inlet~]s (and of course [outlet~]s) already make use of the first argument. it is the up/down-sampling algorithm.
so i think your idea (appealing as it is) provides inconsistency, and it will grow worse, as people might get used to putting comments as arguments into objects. i think a better solution would be a) from the GUI side: add a comment to any object via the right-click properties. b) from the pdfile-side: throw away pd's file-descripting language and finally make it xml. this would make files much bigger, but human-readable, which would be a great improvement.
just my 4 cent.
the tooltip idea is great
mfg.a.dsr IOhannes
Hi IOHannes,
yes, I am aware of the problem. A solution would be the properties dialog. Still pondering ..... Never used the up/downsampling algorithm settings ...
Guenter
On Wed, 26 Nov 2003, IOhannes zmoelnig wrote:
guenter geiger wrote:
HI,
I had a try on implementing tooltips, just commited to CVS. Feedback is welcome.
Generally youonly have to add a description what every inlet does in your abstractions:
|inlet frequency|
the only problem with this is, that signal-[inlet~]s (and of course [outlet~]s) already make use of the first argument. it is the up/down-sampling algorithm.
so i think your idea (appealing as it is) provides inconsistency, and it will grow worse, as people might get used to putting comments as arguments into objects. i think a better solution would be a) from the GUI side: add a comment to any object via the right-click properties. b) from the pdfile-side: throw away pd's file-descripting language and finally make it xml. this would make files much bigger, but human-readable, which would be a great improvement.
just my 4 cent.
the tooltip idea is great
mfg.a.dsr IOhannes
btw, max uses properties too (inlet/outlet `inspector') for that purpose. The text is saved in a patch file as a `comlet' message:
#N comlet <text>; #P inlet <arguments>;
(where #P is #X in Pd terms).
Krzysztof
guenter geiger wrote: ...
yes, I am aware of the problem. A solution would be the properties dialog. Still pondering .....
On Wed, 26 Nov 2003, Krzysztof Czaja wrote:
btw, max uses properties too (inlet/outlet `inspector') for that purpose. The text is saved in a patch file as a `comlet' message:
#N comlet <text>; #P inlet <arguments>;
hmm, and the comlet gets automatically associated with the inlet ? Is there a similar example within pd ? (up to now, I think properties are saved within the objects themselves)
Guenter
(where #P is #X in Pd terms).
Krzysztof
guenter geiger wrote: ...
yes, I am aware of the problem. A solution would be the properties dialog. Still pondering .....
guenter geiger wrote:
On Wed, 26 Nov 2003, Krzysztof Czaja wrote:
btw, max uses properties too (inlet/outlet `inspector') for that purpose. The text is saved in a patch file as a `comlet' message:
#N comlet <text>; #P inlet <arguments>;
hmm, and the comlet gets automatically associated with the inlet ? Is there a similar example within pd ? (up to now, I think properties are saved within the objects themselves)
that is why i was suggesting a shift to XML ok, i know this is lot of work. but still: the pd-fileformat is very flat, not at all suitable for describing hierarchies of complex objects (like sub-patches) other languages would allow this, and XML is just standard (even for microsoft...)
mfg.ads.r IOhannes
Hi all, i'm extremely pro-XML, just to say that. On the other hand, i'm also very pro-attributes (like in Max/Jitter), which is a way to simplify/unify inspector stuff a lot. It's fully implemented in flext (and all attribute-enabled flext objects have a respective inspector via the properties menu), but apart from that it would be great to have system-wide attribute functionality - although that's probably a lot of work as well.
best greetings, Thomas
----- Original Message ----- From: "IOhannes zmoelnig" zmoelnig@iem.kug.ac.at To: "guenter geiger" geiger@xdv.org Cc: "Krzysztof Czaja" czaja@chopin.edu.pl; pd-dev@iem.at Sent: Wednesday, November 26, 2003 12:55 PM Subject: Re: [PD-dev] tooltips
guenter geiger wrote:
On Wed, 26 Nov 2003, Krzysztof Czaja wrote:
btw, max uses properties too (inlet/outlet `inspector') for that purpose. The text is saved in a patch file as a `comlet' message:
#N comlet <text>; #P inlet <arguments>;
hmm, and the comlet gets automatically associated with the inlet ? Is there a similar example within pd ? (up to now, I think properties are saved within the objects themselves)
that is why i was suggesting a shift to XML ok, i know this is lot of work. but still: the pd-fileformat is very flat, not at all suitable for describing hierarchies of complex objects (like sub-patches) other languages would allow this, and XML is just standard (even for microsoft...)
mfg.ads.r IOhannes
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hi all,
I have been planning simply to put inlet attributes as arguments, once the correct design becomes apparent.
I'm not sure it's best to load the up/downsampling filters directly into the inlet~/outlet~ objects; it's certainly possible simply to put them in the subpatch instead.
Other ideas I'm thinking about are:
a name, a message type (for checking connections) an inlet~ with double outlets, one for an incoming signal and the other for messages to the same inlet.
cheers Miller
On Wed, Nov 26, 2003 at 01:07:02PM +0100, Thomas Grill wrote:
Hi all, i'm extremely pro-XML, just to say that. On the other hand, i'm also very pro-attributes (like in Max/Jitter), which is a way to simplify/unify inspector stuff a lot. It's fully implemented in flext (and all attribute-enabled flext objects have a respective inspector via the properties menu), but apart from that it would be great to have system-wide attribute functionality - although that's probably a lot of work as well.
best greetings, Thomas
----- Original Message ----- From: "IOhannes zmoelnig" zmoelnig@iem.kug.ac.at To: "guenter geiger" geiger@xdv.org Cc: "Krzysztof Czaja" czaja@chopin.edu.pl; pd-dev@iem.at Sent: Wednesday, November 26, 2003 12:55 PM Subject: Re: [PD-dev] tooltips
guenter geiger wrote:
On Wed, 26 Nov 2003, Krzysztof Czaja wrote:
btw, max uses properties too (inlet/outlet `inspector') for that purpose. The text is saved in a patch file as a `comlet' message:
#N comlet <text>; #P inlet <arguments>;
hmm, and the comlet gets automatically associated with the inlet ? Is there a similar example within pd ? (up to now, I think properties are saved within the objects themselves)
that is why i was suggesting a shift to XML ok, i know this is lot of work. but still: the pd-fileformat is very flat, not at all suitable for describing hierarchies of complex objects (like sub-patches) other languages would allow this, and XML is just standard (even for microsoft...)
mfg.ads.r IOhannes
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Miller Puckette wrote:
Hi all,
I have been planning simply to put inlet attributes as arguments, once the correct design becomes apparent.
I'm not sure it's best to load the up/downsampling filters directly into the inlet~/outlet~ objects; it's certainly possible simply to put them in the subpatch instead.
actually i found it not that simple to do, the way pd handles signals. i find pd's way of handling blocking, overlapping etc. a very clean solution: a subpatch just runs different signal-blocks and it is all handled by the inlet/outlet routines; the user doesn't have to care.
now for upsampling/downsampling without built-in filters: when a subpatch is upsampling, the whole filtering can be built inside the sub-patch. however, when doing downsampling, the filtering has to be in the parent patch, which i found very dirty: the parent-patch has to know the samplerate of the child to do it correctly. this was the main reason, why i chose to do the filtering in the iolet~s. although i have to admit: very few filters are implemented, and they cannot really be used for audio-processing. while we (at our institute) heavily use the up/down-sampling feature, the filtering is mostly done by hand (but that is, because they don't know it better ;-))
mfg.asrd IOhannes
On Wed, 26 Nov 2003, IOhannes m zmoelnig wrote: <snip>
this was the main reason, why i chose to do the filtering in the iolet~s.
Can't the selection of the filter be done as an argument to block~, just as the blocksize, overlap and resample factor ?
Just a thought, don't really know anything about it.
Anyhow, the current implementation doesn't break the filter setting code, you will just have the name of the filter as tooltip, ...
Guenter
although i have to admit: very few filters are implemented, and they cannot really be used for audio-processing. while we (at our institute) heavily use the up/down-sampling feature, the filtering is mostly done by hand (but that is, because they don't know it better ;-))
mfg.asrd IOhannes
hi all,
I am strongly pro-attributes too, in general. However, I wonder whether specifying tooltip text with attributes in an object box is the best possible idea (unless the same attributes could be specified in the properties dialog as well, as Thomas mentioned).
Actually, I find it redundant and clumsy, to have the same text both in an inlet (or outlet) object box, and in the tip (when mousing over the inlet or outlet object's outlet or inlet). Besides, screen space is precious.
So, for the time being, I would rather use properties.
Btw, Guenter, you did not mean tooltips to be single-word only, did you?
Krzysztof
Miller Puckette wrote: ...
I have been planning simply to put inlet attributes as arguments, once the correct design becomes apparent.
...
On Wed, Nov 26, 2003 at 01:07:02PM +0100, Thomas Grill wrote:
...
On the other hand, i'm also very pro-attributes (like in Max/Jitter), which is a way to simplify/unify inspector stuff a lot.
On Thu, 27 Nov 2003, Krzysztof Czaja wrote:
mousing over the inlet or outlet object's outlet or inlet). Besides, screen space is precious.
Yes, thats another possibility, .. have to add an inlet to the inlet then. I am probably going this way, because of the space requirements ... Anyhow this means I have to change the GUI of the inlet...
So, for the time being, I would rather use properties.
Btw, Guenter, you did not mean tooltips to be single-word only, did you?
No, a single symbol, yes.
Guenter
Krzysztof
Miller Puckette wrote: ...
I have been planning simply to put inlet attributes as arguments, once the correct design becomes apparent.
...
On Wed, Nov 26, 2003 at 01:07:02PM +0100, Thomas Grill wrote:
...
On the other hand, i'm also very pro-attributes (like in Max/Jitter), which is a way to simplify/unify inspector stuff a lot.
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
inlet's outlet and outlet's inlet that is, sorry for my clumsy style,
k
guenter geiger wrote: ...
mousing over the inlet or outlet object's outlet or inlet).
...
Yes, thats another possibility, .. have to add an inlet to the inlet then. I am probably going this way, because of the space requirements ... Anyhow this means I have to change the GUI of the inlet...
guenter geiger wrote: ...
hmm, and the comlet gets automatically associated with the inlet ? Is there a similar example within pd ?
there are no examples, but it is plain simple. In short, it is like if the pd_canvasmaker (aka "classmaker") quasi-object was taking the message 'comlet'. The comlet method would somehow store an assistance binbuf (the text of a tip). That binbuf would then be used by the constructor of the inlet or outlet created next, and cleared.
(up to now, I think properties are saved within the objects themselves)
there are data-embedding objects, though (array and a few cyclonics), so the idea of using more than one .pd-file message to create an object is not that weird after all.
Krzysztof
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Generally youonly have to add a description what every inlet does in your abstractions:
|inlet frequency|
I'm not sure, if it should be done this way in the long run. Wasn't there some discussion some time ago about the possibilities to have xlets numbered, like in jMax? Then we'd already have [inlet 1] as first arg. Whatever: If tooltips take the first arg's position, then that position is gone for possible other uses.
Maybe a kind of doc message for xlets would be an alternative. Like
[doc This inlet accepts the frequency( \ [inlet]
Okay, inlets don't have inlets yet, but it's just a thought.
ciao
On Wed, 26 Nov 2003, Frank Barknecht wrote:
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Generally youonly have to add a description what every inlet does in your abstractions:
|inlet frequency|
I'm not sure, if it should be done this way in the long run. Wasn't there some discussion some time ago about the possibilities to have xlets numbered, like in jMax? Then we'd already have [inlet 1] as first arg. Whatever: If tooltips take the first arg's position, then that position is gone for possible other uses.
Thats true, but if numbers take the first position then it is gone too, as well as the resampling from IOhannes ... Personally I do not like the idea of numbering inlets, because its very confusing for me.
Maybe a kind of doc message for xlets would be an alternative. Like
[doc This inlet accepts the frequency( \ [inlet]
Okay, inlets don't have inlets yet, but it's just a thought.
Would be another possibility. But why not using a [pos X] message if someone really wants to change inlet position.
I think it is important that documenting the inlets is easy. No additional messages and connecting.
One alternative that comes to my mind is having a property dialog popping up everytime you create an inlet.
Then it is important that the documentation about the inlet can be seen inside the patch too (how, maybe as a tooltip at the inlet itself ?)
In general, when inlets are replaced by a graphical representation, the positioning of the arguments doesn't matter anymore, so not everything is lost ...
Guenter
ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
e skogen -
Frank Barknecht -
guenter geiger -
IOhannes m zmoelnig -
IOhannes zmoelnig -
Krzysztof Czaja -
Michal Seta -
Miller Puckette -
stotz -
Thomas Grill