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
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
--- On Fri, 10/8/10, Mathieu Bouchard ma...@artengine.ca wrote:
From: Mathieu Bouchard ma...@artengine.ca
Subject: Re: [PD] [out-of-the-blue] a neat GUI feature? - Feature
documentation
To: João Pais jmmmp...@googlemail.com
Cc: pd-list@iem.at, IOhannes m zmoelnig zmoel...@iem.at
Date
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
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
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
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
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
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
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
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
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
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
On Wed, 29 Sep 2010, Pedro Lopes wrote:
About:
http://sourceforge.net/tracker/index.php?func=detailaid=1056914group_id=55736atid=478072
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
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 :)
http://artengine.ca/desiredata/gallery/find_last_error.png
Very nice.
btw, this is exactly what the people at 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
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
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
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
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:
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
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
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~]
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
--- On Wed, 9/29/10, João Pais jmmmp...@googlemail.com wrote:
From: João Pais jmmmp...@googlemail.com
Subject: Re: [PD] [out-of-the-blue] a neat GUI feature?
To: Max abonneme...@revolwear.com, Mathieu Bouchard ma...@artengine.ca
Cc: PD List pd-list@iem.at
Date: Wednesday, September 29
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 ma...@artengine.ca:
On Wed, 29 Sep 2010, João Pais wrote:
In case someone is interested in
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
27 matches
Mail list logo
