I just remembered a feature* one could have in the future (it relates to various threads and interesting discussions we had here):
- When rolling the mouse over a outlet of an abstraction it could tell what
that was. (useful for those crazy objects with n-th outs)
How could he tell what that outlet carries? This could be a sort of metadata comment (or other better/clever idea) added to the subpatch/abstraction that would be parsed and read by the GUI in order to simplify your work. Like "Metadata/Outlets: sound(mono); data(0.0-1.0); toogle(0-1); on-off(bang);"
Then in our main patch: __________________ |my_giant_abstraction| | *_ *_ _ _ ___________|
When rolling through outlet "1" it would say "Sound(mono)"., and so forth
Conversely, one could do the same for inputs/inlets.
Just a though after many hours of pd, Best regards, Pedro
- maybe this has been though/brought up here, its worth the try.
p.s.: anyway I'll take note of this, maybe I could try a simple version of it sometime...
btw, this is exactly what the people at vvvv thought Pd (and similar
programs) didn't do that well, and they programmed it all in. if you look
at that program, it has lots of examples of small stuff that makes the
experience a bit more "pleasurable".
In case someone is interested in putting this in, I would also suggest
that some metadata is created, so that even abstractions etc could make
use of this with help comments, etc.
João
I just remembered a feature* one could have in the future (it relates to various threads and interesting discussions we had here):
- When rolling the mouse over a outlet of an abstraction it could tell
what that was. (useful for those crazy objects with n-th outs)
How could he tell what that outlet carries? This could be a sort of
metadata comment (or other better/clever idea) added to the subpatch/abstraction
that would be parsed and read by the GUI in order to simplify your work. Like "Metadata/Outlets: sound(mono); data(0.0-1.0); toogle(0-1);
on-off(bang);"Then in our main patch: __________________ |my_giant_abstraction| | *_ *_ _ _ ___________|
When rolling through outlet "1" it would say "Sound(mono)"., and so forth
Conversely, one could do the same for inputs/inlets.
Just a though after many hours of pd, Best regards, Pedro
- maybe this has been though/brought up here, its worth the try.
p.s.: anyway I'll take note of this, maybe I could try a simple version
of it sometime...
On Wed, 29 Sep 2010, João Pais wrote:
In case someone is interested in putting this in, I would also suggest that some metadata is created, so that even abstractions etc could make use of this with help comments, etc.
It's easy to think about the features that you'd like to put in, and it's not that hard to code it : what's hard is to have the appropriate discussion with Miller about putting it in (let alone getting it approved at all...)
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
why not having a separate git branch(es) that remains compatible and pulls from vanilla-pd? then some people can try things out there and at the same time it can be tested.
2010/9/29 Mathieu Bouchard matju@artengine.ca:
On Wed, 29 Sep 2010, João Pais wrote:
In case someone is interested in putting this in, I would also suggest that some metadata is created, so that even abstractions etc could make use of this with help comments, etc.
It's easy to think about the features that you'd like to put in, and it's not that hard to code it : what's hard is to have the appropriate discussion with Miller about putting it in (let alone getting it approved at all...)
_______________________________________________________________________ | Mathieu Bouchard ------------------------------ Villeray, Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Am 29.09.2010 um 10:24 schrieb João Pais:
In case someone is interested in putting this in, I would also suggest that some metadata is created, so that even abstractions etc could make use of this with help comments, etc.
why complicated metadata if you can already do [inlet~ channel1] and [outlet activity] in an abstraction/subpatch? afaik arguments to those objects currently are ignored, but i do use them sometimes to make me remember their function.
why complicated metadata if you can already do [inlet~ channel1] and
[outlet activity] in an abstraction/subpatch? afaik arguments to those
objects currently are ignored, but i do use them sometimes to make me
remember their function.
several reasons:
- unless you want a really big box there, you should only use a symbol
(i.e. one word) for the inlets
- to see these symbols (they can't even be considered as comments, it's
not the same), you have to open the abstraction. if you go to open the
abstraction, then it's easier to leave a normal comment there. the purpose
of the idea was to save the work of opening the abstraction. just like you
can always know what number is coming out of any object, just connect it
to a number box; but if you are debugging, you have to be constantly
putting in number boxes and connecting them (and later deleting them)
- you wouldn't be able to see these comments on an external, without the
"metadata"
- if you decide to change the inlet~ "comment" in a patch already
programmed, the connections will break when the object is redrawn. that's
a not very coherent behaviour, but it's there. the metadata would be
somewhere else in the patch.
why complicated metadata if you can already do [inlet~ channel1] and
[outlet activity] in an >abstraction/subpatch? hum.. I didn't knew. Although I agree metadata would simplify the job in many ways (some mentioned by João in the last email) this is indeed a nice feature, but It lacks the "mouse hovering", so you always have to enter/open the abstraction/subpatch to see what lies in there - that was my main contribution with the "idea".
Best regards, Pedro Lopes
On Wed, Sep 29, 2010 at 4:39 PM, João Pais jmmmpais@googlemail.com wrote:
why complicated metadata if you can already do [inlet~ channel1] and
[outlet activity] in an abstraction/subpatch? afaik arguments to those objects currently are ignored, but i do use them sometimes to make me remember their function.
several reasons:
- unless you want a really big box there, you should only use a symbol
(i.e. one word) for the inlets
- to see these symbols (they can't even be considered as comments, it's not
the same), you have to open the abstraction. if you go to open the abstraction, then it's easier to leave a normal comment there. the purpose of the idea was to save the work of opening the abstraction. just like you can always know what number is coming out of any object, just connect it to a number box; but if you are debugging, you have to be constantly putting in number boxes and connecting them (and later deleting them)
- you wouldn't be able to see these comments on an external, without the
"metadata"
- if you decide to change the inlet~ "comment" in a patch already
programmed, the connections will break when the object is redrawn. that's a not very coherent behaviour, but it's there. the metadata would be somewhere else in the patch.
-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
On Wed, 29 Sep 2010, Max wrote:
why complicated metadata if you can already do [inlet~ channel1] and [outlet activity] in an abstraction/subpatch? afaik arguments to those objects currently are ignored, but i do use them sometimes to make me remember their function.
$1 $2 and $3 of [inlet~] and [outlet~] are already reserved for the resampling feature (specific to DSP). This feature was introduced a few years after the inlet-tooltip feature was introduced.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
why complicated metadata if you can already do [inlet~ channel1] and [outlet activity] in an abstraction/subpatch? afaik arguments to those objects currently are ignored, but i do use them sometimes to make me remember their function.
$1 $2 and $3 of [inlet~] and [outlet~] are already reserved for the resampling feature (specific to DSP). This feature was introduced a few years after the inlet-tooltip feature was introduced.
you mean like a block~/switch~ object? never heard of those features
before (I don't follow up all changelogs, so if it's not documented, I
don't know it).
--- On Wed, 9/29/10, João Pais jmmmpais@googlemail.com wrote:
From: João Pais jmmmpais@googlemail.com Subject: Re: [PD] [out-of-the-blue] a neat GUI feature? To: "Max" abonnements@revolwear.com, "Mathieu Bouchard" matju@artengine.ca Cc: "PD List" pd-list@iem.at Date: Wednesday, September 29, 2010, 7:52 PM
why complicated metadata if
you can already do [inlet~ channel1] and
[outlet activity] in an abstraction/subpatch?
afaik arguments to those
objects currently are ignored, but i do use them
sometimes to make me
remember their function.
$1 $2 and $3 of [inlet~] and [outlet~] are already
reserved for the
resampling feature (specific to DSP). This feature was
introduced a few
years after the inlet-tooltip feature was introduced.
you mean like a block~/switch~ object? never heard of those features before (I don't follow up all changelogs, so if it's not documented, I don't know it).
Right-click on [inlet~] or [outlet~], then look in the subpatch called "up/downsampling". It explains the $1, but whatever matju is referring to-- with $2 and $3 also being reserved for resampling-- is not documented there.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 29 Sep 2010, João Pais wrote:
$1 $2 and $3 of [inlet~] and [outlet~] are already reserved for the resampling feature (specific to DSP). This feature was introduced a few years after the inlet-tooltip feature was introduced.
you mean like a block~/switch~ object? never heard of those features before (I don't follow up all changelogs, so if it's not documented, I don't know it).
Actually, I said something wrong. [inlet~] takes only one argument, and it is complementary to arguments $2 and $3 of [block~], which were introduced at the same time, afaik.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On 2010-09-29 19:24, Mathieu Bouchard wrote:
On Wed, 29 Sep 2010, Max wrote:
why complicated metadata if you can already do [inlet~ channel1] and [outlet activity] in an abstraction/subpatch? afaik arguments to those objects currently are ignored, but i do use them sometimes to make me remember their function.
$1 $2 and $3 of [inlet~] and [outlet~] are already reserved for the resampling feature (specific to DSP). This feature was introduced a few years after the inlet-tooltip feature was introduced.
quite interesting remark.
i cannot remember exactly when the inlet-tooltio feature was introduced (i only remember that one implementation was done during the coding sprint at PdCon04; however i think that günter had an earlier implemenation lying around...ah searching the archives i find that günter has done an implementation in 2003: http://lists.puredata.info/pipermail/pd-dev/2003-11/001797.html)
the up/downsampling feature, that - according to you email was introduced a "few years after the inlet-tooltip", has been in Pd since 0.35.0 (the tar archive of which has time-stamps around 2002-07)
fgamsdr IOhannes
i cannot remember exactly when the inlet-tooltio feature was introduced (i only remember that one implementation was done during the coding sprint at PdCon04; however i think that gÃŒnter had an earlier implemenation lying around...ah searching the archives i find that gÃŒnter has done an implementation in 2003: http://lists.puredata.info/pipermail/pd-dev/2003-11/001797.html)
so this (whatever it is) has been there for 6 years, and no one knew of
it? the same with the "dirty 0" message, which could have been very
helpful when using donecanvasdialog in the past (from 0.43 won't be
important anymore).
since some developers don't do their documentation (for whichever reason
it may be), would it make sense to create a wiki page where they can
delegate that function? for people that don't read code, these features
remain in oblivion until someone more or less by chance stumbles upon
them. I myself can offer to work on the help patches to document new,
obscure and useful functions.
João Pais
On 2010-09-30 12:51, João Pais wrote:
so this (whatever it is) has been there for 6 years, and no one knew of it?
no. it has been posted on the list 7 years ago, so a lot of people new about it. it was discussed and re-implemented at pdcon 2004, and then posted to the patch-tracker; so even more people knew about it.
it was obvious that miller felt reluctant about accepting the patch, and in 2010 the issue was finally closed on sourceforge.
"knowing" about it doesn't mean "liking" or even "accepting".
fgmasdr IOhannes
On Thu, 30 Sep 2010, João Pais wrote:
since some developers don't do their documentation (for whichever reason it may be), would it make sense to create a wiki page where they can delegate that function? for people that don't read code, these features remain in oblivion until someone more or less by chance stumbles upon them. I myself can offer to work on the help patches to document new, obscure and useful functions.
I suggest that you work with Jonathan Wilkes on this.
Just forget about the wiki.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
--- On Fri, 10/8/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] [out-of-the-blue] a neat GUI feature? - Feature documentation To: "João Pais" jmmmpais@googlemail.com Cc: pd-list@iem.at, "IOhannes m zmoelnig" zmoelnig@iem.at Date: Friday, October 8, 2010, 4:50 PM On Thu, 30 Sep 2010, João Pais wrote:
since some developers don't do their documentation
(for whichever reason it may be), would it make sense to create a wiki page where they can delegate that function? for people that don't read code, these features remain in oblivion until someone more or less by chance stumbles upon them.
The only way to fix the current docs is to revise them and add to them.
I myself can offer to work on the help patches to document new, obscure and useful functions.
I've been revising the internal objects for a few months now.
As for external libraries-- I already have some additions for many libraries, but I'm not sure how to do them. For example, who is in charge of cyclone? I have some help patches to add to that library, plus corrections to the existing ones.
I suggest that you work with Jonathan Wilkes on this.
Just forget about the wiki.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC -----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 30 Sep 2010, IOhannes m zmoelnig wrote:
On 2010-09-29 19:24, Mathieu Bouchard wrote:
$1 $2 and $3 of [inlet~] and [outlet~] are already reserved for the resampling feature (specific to DSP). This feature was introduced a few years after the inlet-tooltip feature was introduced.
quite interesting remark.
not necessarily...
i cannot remember exactly when the inlet-tooltio feature was introduced (i only remember that one implementation was done during the coding sprint at PdCon04; however i think that günter had an earlier implemenation lying around...ah searching the archives i find that günter has done an implementation in 2003: http://lists.puredata.info/pipermail/pd-dev/2003-11/001797.html)
yeah, that's the one.
the up/downsampling feature, that - according to you email was introduced a "few years after the inlet-tooltip", has been in Pd since 0.35.0 (the tar archive of which has time-stamps around 2002-07)
Yeah, it was already there at the time of 0.37 (that's when I started reading the source and using Pd for real), but somehow I overlooked it or misremembered it.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
Am 29.09.2010 um 19:24 schrieb Mathieu Bouchard:
On Wed, 29 Sep 2010, Max wrote:
why complicated metadata if you can already do [inlet~ channel1] and [outlet activity] in an abstraction/subpatch? afaik arguments to those objects currently are ignored, but i do use them sometimes to make me remember their function.
$1 $2 and $3 of [inlet~] and [outlet~] are already reserved for the resampling feature (specific to DSP). This feature was introduced a few years after the inlet-tooltip feature was introduced.
That's interesting. From the help patch for [inlet~]/[outlet~] I can't tell what $2 and $3 are, just the two options “hold” and “lin” for $1.
m.
On Wed, 29 Sep 2010, Pedro Lopes wrote:
I just remembered a feature* one could have in the future (it relates to various threads and interesting discussions we had here): - When rolling the mouse over a outlet of an abstraction it could tell what that was. (useful for those crazy objects with n-th outs)
A feature like this was coded for pd back in 2003 :
http://sourceforge.net/tracker/index.php?func=detail&aid=1056914&gro...
And you can bet that it's never going to be added.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
I know what you mean Mathieu, this was just a proposal. This "metadata" issues has been brought up several times since I read the list. It has serious impact with pd's own structure and obviously it has to be a conceptual issue discussed and approved by Miller and all developers I guess.
About: http://sourceforge.net/tracker/index.php?func=detail&aid=1056914&gro...
I did not get exactly what this feature was about, I read the comments and overall description, but something slipped, could you enlighten?
Best regards, Pedro Lopes
On Wed, Sep 29, 2010 at 3:23 PM, Mathieu Bouchard matju@artengine.cawrote:
On Wed, 29 Sep 2010, Pedro Lopes wrote:
I just remembered a feature* one could have in the future (it relates to
various threads and interesting discussions we had here): - When rolling the mouse over a outlet of an abstraction it could tell what that was. (useful for those crazy objects with n-th outs)
A feature like this was coded for pd back in 2003 :
http://sourceforge.net/tracker/index.php?func=detail&aid=1056914&gro...
And you can bet that it's never going to be added.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Wed, 29 Sep 2010, Pedro Lopes wrote:
About: http://sourceforge.net/tracker/index.php?func=detail&aid=1056914&gro...
I did not get exactly what this feature was about, I read the comments and overall description, but something slipped, could you enlighten?
It's the same feature that you ask for, basically.
"tooltips" is the name for transient text that appears over a GUI to help the user (as a reminder, for example). It usually is triggered by mouse-over.
The original tooltip patches for pd were writing directly over the patch and make the text follow the mouse.
My version of it makes the text more visually stable (only is positioned once per appearance of the text) and puts it on an opaque beige rectangle such as how normal tooltips work in other apps. I also made another version of it for "find last error" with a red bg, which I mention only because that's the only related screenshot I can find right now :
http://artengine.ca/desiredata/gallery/find_last_error.png
Well, actually, there was also a name-completion tooltip for a while, before it was turned into another widget, and that was sharing some code with my inlet tooltip code :
http://artengine.ca/desiredata/gallery/completions2.gif
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
"tooltips" is the name for transient text that appears over a GUI to help
the user (as a reminder, for >example). It usually is triggered by mouse-over. Thanks for the enlightenment Mathieu :)
Very nice.
http://artengine.ca/desiredata/gallery/completions2.gifThat one I had already shown to a colleague here, I've seen it on your site. Nice feature!
Then its all about reconnecting pd with these "more friendly GUI features". Even if they don't make it to vanilla, why not extended?
Best regards, Pedro
On Thu, Sep 30, 2010 at 7:37 PM, Mathieu Bouchard matju@artengine.cawrote:
on of it makes the text more visually stable
On Thu, 30 Sep 2010, Pedro Lopes wrote:
Then its all about reconnecting pd with these "more friendly GUI features". Even if they don't make it to vanilla, why not extended?
pd-extended is only for the things Hans wants, and if it's not something that is expected to go in vanilla, it better be damn important, to justify maintaining a long-term difference between extended and vanilla.
I've heard Hans say that he can't use DesireData code because it's licensed under the GPL. Pd-extended is also said to be licensed under the GPL, but the pd core section of it comes with Miller's BSD notice, and any contributions to vanilla need to be under the BSD. However, in all those years, Hans never asked me whether relicensing any piece of it would be a possibility, so I think that the license issue is just a façade for another issue.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
A better model for the libs would be just to have packages, spreading the effort between people to maintain each package. And leaving space to develop the pd-core/pd-gut themselves. Don't you think? Maybe I'm missing something.
I didn't know about the incompatibility of BSD and GPL. This happens with all versions of BSD?
Mathieu, maybe we need a new project called PureFlow? :-)
2010/10/1 Mathieu Bouchard matju@artengine.ca:
On Thu, 30 Sep 2010, Pedro Lopes wrote:
Then its all about reconnecting pd with these "more friendly GUI features". Even if they don't make it to vanilla, why not extended?
pd-extended is only for the things Hans wants, and if it's not something that is expected to go in vanilla, it better be damn important, to justify maintaining a long-term difference between extended and vanilla.
I've heard Hans say that he can't use DesireData code because it's licensed under the GPL. Pd-extended is also said to be licensed under the GPL, but the pd core section of it comes with Miller's BSD notice, and any contributions to vanilla need to be under the BSD. However, in all those years, Hans never asked me whether relicensing any piece of it would be a possibility, so I think that the license issue is just a façade for another issue.
_______________________________________________________________________ | Mathieu Bouchard ------------------------------ Villeray, Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 1 Oct 2010, Bernardo Barros wrote:
A better model for the libs would be just to have packages, spreading the effort between people to maintain each package. And leaving space to develop the pd-core/pd-gut themselves. Don't you think? Maybe I'm missing something.
We're not talking about the structure of pd-extended, we're talking about the name. I say that it's better to call it "pcap" within Pd, meaning the embodiment of the original "pcap" as a pd thing, and outside of Pd, it should be known as "pd-pcap" instead, the hyphen meaning "pd's pcap".
I didn't know about the incompatibility of BSD and GPL. This happens with all versions of BSD?
If you put any GPL code together with BSD code, the overall license will be GPL, because you have to follow the terms of both licenses at once, all the terms of BSD are in GPL, and none of the other terms of GPL are in BSD. This doesn't change the license of any piece of code automatically, it only changes what you can do on the whole project, as long as you keep any GPL pieces in it.
Mathieu, maybe we need a new project called PureFlow? :-)
Bernardo, maybe we need that you explain yourself.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Oct 1, 2010, at 2:31 PM, Mathieu Bouchard wrote:
On Thu, 30 Sep 2010, Pedro Lopes wrote:
Then its all about reconnecting pd with these "more friendly GUI
features". Even if they don't make it to vanilla, why not extended?pd-extended is only for the things Hans wants, and if it's not
something that is expected to go in vanilla, it better be damn
important, to justify maintaining a long-term difference between
extended and vanilla.I've heard Hans say that he can't use DesireData code because it's
licensed under the GPL. Pd-extended is also said to be licensed
under the GPL, but the pd core section of it comes with Miller's BSD
notice, and any contributions to vanilla need to be under the BSD.
However, in all those years, Hans never asked me whether relicensing
any piece of it would be a possibility, so I think that the license
issue is just a façade for another issue.
These are both incorrect. There are things in Pd-extended which I did
not want to be there, I believe compromise is good sometimes. Pd-
extended is GPL and can therefore incorporate code from DesireData.
Pd-vanilla is BSD and my modifications to pd itself are also BSD. I
don't want to maintain GPL modifications to pd core. Someone else
could.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Fri, 8 Oct 2010, Hans-Christoph Steiner wrote:
There are things in Pd-extended which I did not want to be there, I believe compromise is good sometimes.
Everybody does. Most of the time, when you or someone else complains about some weird hack in GridFlow, I've already gone through that process and got over it. The fact is that it's pointless to insist in my head that I wanted something that I can't get. I want compromise. Some pieces of code that I write embody those compromises. But I often don't bother to call them as such.
(It shouldn't take a philosophy course to get past the «I want what I don't want» paradox...)
Pd-extended is GPL and can therefore incorporate code from DesireData. Pd-vanilla is BSD and my modifications to pd itself are also BSD. I don't want to maintain GPL modifications to pd core. Someone else could.
But who are the other maintainers of Pd extended ? Ah ok, thought so. You mean that if I forked pd-extended I could get GPL code into it ? Ok, but I can do that with pd-vanilla too.
Besides, DesireData isn't wholly GPL'ed : the C++ code is actually all BSD, since the beginning, and that's a large portion of the code.
These are both incorrect.
For things that are supposedly incorrect, you seem to be curiously confirming what I've been saying.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
-
Bernardo Barros -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
João Pais -
Mathieu Bouchard -
Max -
Pedro Lopes