segmented patchcords can make patches less readable, but most of the time they make patches more readable, and that is when you use so many unsegmented cords that they hide the objects. also when you want to connect an object at the bottom of the patch to an object at the top, then you can lay the cord at the outside of the patch to make the ~feed-back. you don't want patchcords in situations where it is not clear anymore which cord is going where. a big problem in max is that there is no undo for segmented patchcords. once segmented, you can only delete them and redraw to make them not segmented. that might be one of the new features of max 5... as well as the infinite number of undos. (true?) marius.
i have never felt the need for segmented patch cords. and as many people keep saying, your patches will eventually end up neater and more logical without them. they force you to patch more correctly.
infinite undos would be nice though :)
On Wed, 5 Dec 2007, hard off wrote:
i have never felt the need for segmented patch cords. and as many people keep saying, your patches will eventually end up neater and more logical without them. they force you to patch more correctly.
they also force me to do workarounds every time i need to connect objects in a loop, unless i just let patchcords go over objects. There's no way that loop situations can be "untangled" without [s]/[r].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 4, 2007, at 4:53 PM, Mathieu Bouchard wrote:
On Wed, 5 Dec 2007, hard off wrote:
i have never felt the need for segmented patch cords. and as many people keep saying, your patches will eventually end up neater and more logical without them. they force you to patch more correctly.
they also force me to do workarounds every time i need to connect
objects in a loop, unless i just let patchcords go over objects.
There's no way that loop situations can be "untangled" without [s]/ [r].
I use a [bang] or a [list] in between for recursive connection.
That's the one time I think that something other than a straight
patchcord would be useful. I rarely use send/receive at all.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
On Tue, 4 Dec 2007, Hans-Christoph Steiner wrote:
On Dec 4, 2007, at 4:53 PM, Mathieu Bouchard wrote:
they also force me to do workarounds every time i need to connect objects in a loop, unless i just let patchcords go over objects. There's no way that loop situations can be "untangled" without [s]/[r].
I use a [bang] or a [list] in between for recursive connection. That's the one time I think that something other than a straight patchcord would be useful. I rarely use send/receive at all.
If your recursion only involves the left side of objects, one object to the left of the main chain might be ok, but when it's not, you may have to use *two* objects for making it look clear.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
I think it is really a personal preference then anything else and I was thinking that it could be a nice option. I have used segmented patch cords for a while and I never had a problem with the patch being less readable because the patch cord could be lined up besides another and organized more easily to make the patch cleaner. Also another feature that would be useful that I use in MAX is colored patch cords. This helps organize different types of data.
On Dec 4, 2007 10:09 AM, marius schebella marius.schebella@gmail.com wrote:
segmented patchcords can make patches less readable, but most of the time they make patches more readable, and that is when you use so many unsegmented cords that they hide the objects. also when you want to connect an object at the bottom of the patch to an object at the top, then you can lay the cord at the outside of the patch to make the ~feed-back. you don't want patchcords in situations where it is not clear anymore which cord is going where. a big problem in max is that there is no undo for segmented patchcords. once segmented, you can only delete them and redraw to make them not segmented. that might be one of the new features of max 5... as well as the infinite number of undos. (true?) marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 2007-12-04 at 10:33 -0500, Joe Reinsel wrote:
I think it is really a personal preference then anything else and I was thinking that it could be a nice option.
hm... i think it depends on what kind of patches you actually work on. if the patch is something rather simple like:
[mygop.synth]
|________________
|
| _____
[mygop.fx1] / [mygop.fx2]
|__________/ /
| _______________/
|/
[mygop.mixer]
segmented patch chords might make sense, because they not interfere with the visual representation of the gops.
but when you do stuff, that is actually programming and more complex, i don't think it is a matter of taste then, but a question of what best represents the logic of the patch and i don't think that segmented chords help making the logic of a patch clearer.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, marius schebella hat gesagt: // marius schebella wrote:
segmented patchcords can make patches less readable, but most of the time they make patches more readable, and that is when you use so many unsegmented cords that they hide the objects. also when you want to connect an object at the bottom of the patch to an object at the top, then you can lay the cord at the outside of the patch to make the ~feed-back.
Flamewar bait, but I'll bite: I think, in many of these cases the objects or even the whole patch are laid out in a bad or even wrong way. If a patch has so many cords that everything is black from them, something is wrong on another level than the level segmentation of cords could fix. Then the patch is in need of refactoring.
With feedback it's a slighty different issue, but unless you have a lot of feedback in your patch, you can make your own segments with [t a] or send/receive, and if you have a lot of feedback in your patch, you probably should use more abstractions/subpatches anyway, see above.
Btw.: Even many Max users prefer non-segmented cords, don't they?
Ciao
Frank Barknecht _ ______footils.org__
good design includes more than just personal taste. in real life, you don't want to have cables running diagonally through your room, only because that is the easiest way to do... in pd it is more likely that you accidently delete a line if it runs over an object. plus, in a performance situation you already know what your patch does, the priority of readability will probably get shifted to a priority of usuability, where you want to highlight and concentrate only on the interaction elements. this is not only a matter of "taste". but you are right, there is not always a need for segmented patch cords and max users do not use them all the time. marius.
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
segmented patchcords can make patches less readable, but most of the time they make patches more readable, and that is when you use so many unsegmented cords that they hide the objects. also when you want to connect an object at the bottom of the patch to an object at the top, then you can lay the cord at the outside of the patch to make the ~feed-back.
Flamewar bait, but I'll bite: I think, in many of these cases the objects or even the whole patch are laid out in a bad or even wrong way. If a patch has so many cords that everything is black from them, something is wrong on another level than the level segmentation of cords could fix. Then the patch is in need of refactoring.
With feedback it's a slighty different issue, but unless you have a lot of feedback in your patch, you can make your own segments with [t a] or send/receive, and if you have a lot of feedback in your patch, you probably should use more abstractions/subpatches anyway, see above.
Btw.: Even many Max users prefer non-segmented cords, don't they?
Ciao
On Tue, 2007-12-04 at 18:29 +0100, Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
segmented patchcords can make patches less readable, but most of the time they make patches more readable, and that is when you use so many unsegmented cords that they hide the objects. also when you want to connect an object at the bottom of the patch to an object at the top, then you can lay the cord at the outside of the patch to make the ~feed-back.
Flamewar bait, but I'll bite: I think, in many of these cases the objects or even the whole patch are laid out in a bad or even wrong way. If a patch has so many cords that everything is black from them, something is wrong on another level than the level segmentation of cords could fix. Then the patch is in need of refactoring.
With feedback it's a slighty different issue, but unless you have a lot of feedback in your patch, you can make your own segments with [t a] or send/receive, and if you have a lot of feedback in your patch, you probably should use more abstractions/subpatches anyway, see above.
Btw.: Even many Max users prefer non-segmented cords, don't they?
oh, dear... i sooo much agree with you...
from my experience, whenever segmented patch cords would make a patch more readable, the patch is very unreadable already anyway (even if it had segmented chords). it's very difficult (at least for me with limited brain power) to keep track of all the dataflow and its execution order, if there is so much recursion and chords going from left to right and vice versa. in other words: i am absolutely not against segmented patch cords in general, but they are not a solution for more easily readable patches. they probably just make the problem look nicer, but the problem is still there. so, my recommandations go in the very same direction as franks: whenever readability becomes an issue, try to the restructure the patch.
probably this won't apply to your way of patching, but i used to have a lot of readability problems when using objects like [textfile] or [index] or selfmade abstractions to store and access certain sets of information, because probably a lot of other objects were accessing them, and each of these had a direct connection to [textfile] (or whatsoever). especially, when the reading from [textfile] (..) is dependent from previous outputs from [textfile] you can easily end up with _very_ unreadable spaghetti patches. i would like to show you a structure, that turned out to be used quite often in my patches. maybe this is obvious and well known to you already, it is simply based on the idea by making such objects like [textfile] more easily accessible with sends and receives like this, lets call it the 'provide pattern':
[r $0.textfile.i.0] | [texfile ] | | | [s $0.textfile.o.1] | [s $0.textfile.o.0]
then you can access it with as many of the following structures as you want (lets call it the 'access pattern':
| [t b a] | | | [s $0.textfile.i.0] | | [r $0.textfile.o.0] | | [list ] |
you can easily have as many 'access patterns' in a serie and the patch is still very easy to read. although we actually still have a patch with many recursion, you can read it in one direction, from top to bottom.
my 2¢ (CAD)
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Funny, this is almost *verbatim* the solution i use in my framework
for creating "name spaces" with outlets and instance numbers.
good to know im not (completely) crazy.
Personally I find that use of segmented patch coords can *increase*
readability in patches that are well laid out. I have a much easier
time following segmented patch coords that are laid out with care than
a similarly grouped /laid out patch sans segmentation.
I actually *like* the patch coords being overlaid on the same pixel
row and column, with my patches, when I use this feature it makes it
very easy for me to visibly discern the flow, in a tree like structure
of multiple sources to destinations. I know that all patch coords on
this one pixel row or colum go "here" - I do not have to think about
it at all, and it takes up less space, making way for tighter patches
which take up less screen real estate.
Of course segmentation can be confusing, where many patch coords
originating from multiple locations and GOING to multiple locations
may be overlayed on the same row/column pixel (so it looks as one
patch coord), and this is definitely makes reading a complex patch
harder, but when used wisely it makes (at least for me) reading
patches MUCH easier, more aesthetic and easier to look at for longer
periods.
.. anyway.
They would be a welcome addition to PD imo.
On Dec 4, 2007, at 5:11 PM, Roman Haefeli wrote:
[r $0.textfile.i.0] | [texfile ] | | | [s $0.textfile.o.1] | [s $0.textfile.o.0]
then you can access it with as many of the following structures as you want (lets call it the 'access pattern':
| [t b a] | | | [s $0.textfile.i.0] | | [r $0.textfile.o.0] | | [list ] |
you can easily have as many 'access patterns' in a serie and the patch is still very easy to read. although we actually still have a patch
with many recursion, you can read it in one direction, from top to bottom.
vade wrote:
Personally I find that use of segmented patch coords can *increase*
readability in patches that are well laid out. I have a much easier
time following segmented patch coords that are laid out with care than
a similarly grouped /laid out patch sans segmentation.
while i don't know the real intention behind segmented patch chords, but i have a strong feeling that they are supposed to increase readability.
however, in practice i find that generally they reduce readability. this is most likely a problem with the users and not with the feature per se.
Of course segmentation can be confusing, where many patch coords
originating from multiple locations and GOING to multiple locations
may be overlayed on the same row/column pixel (so it looks as one
patch coord), and this is definitely makes reading a complex patch
harder,
i guess about 95% of patches with segmented patch-chords that i have seen do it like this. this is why i don't want to encourage users to use it.
however, as said before, if there was a flag where i could turn off all the carefully laid-out segmentation (per patch, per pd-instance,...), i could be happy still :-)
fgmasdr IOhannes
On Tue, Dec 04, 2007 at 06:29:00PM +0100, Frank Barknecht wrote:
Btw.: Even many Max users prefer non-segmented cords, don't they?
I think the key point to take from the whole discussion is that Max/MSP users have a choice, whilst under Pd we have no choice. It's all very well justifying how great it is to not have patch chords, but the lack of that feature/bug definately annoys some [potential] users and puts them off Pd. If the people want it, why not give it to them?
Best,
Chris, who feels totally neutral about segmented patch chords.
On Dec 4, 2007, at 8:36 PM, Chris McCormick wrote:
On Tue, Dec 04, 2007 at 06:29:00PM +0100, Frank Barknecht wrote:
Btw.: Even many Max users prefer non-segmented cords, don't they?
I think the key point to take from the whole discussion is that Max/ MSP users have a choice, whilst under Pd we have no choice. It's all very well justifying how great it is to not have patch chords, but the lack of that feature/bug definately annoys some [potential] users and puts them off Pd. If the people want it, why not give it to them?
Patches welcome!
.hc
Best,
Chris, who feels totally neutral about segmented patch chords.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
On Tue, Dec 04, 2007 at 11:39:23PM -0500, Hans-Christoph Steiner wrote:
On Dec 4, 2007, at 8:36 PM, Chris McCormick wrote:
On Tue, Dec 04, 2007 at 06:29:00PM +0100, Frank Barknecht wrote:
Btw.: Even many Max users prefer non-segmented cords, don't they?
I think the key point to take from the whole discussion is that Max/ MSP users have a choice, whilst under Pd we have no choice. It's all very well justifying how great it is to not have patch chords, but the lack of that feature/bug definately annoys some [potential] users and puts them off Pd. If the people want it, why not give it to them?
Patches welcome!
Yes, good call. Code > Words.
Best,
Chris.
Of course we should then the whole way and allow general splines as patch cords like in VVVV. much sexier.
not even worth 2c
tm
On 05/12/2007, at 2:36 AM, Chris McCormick wrote:
On Tue, Dec 04, 2007 at 06:29:00PM +0100, Frank Barknecht wrote:
Btw.: Even many Max users prefer non-segmented cords, don't they?
I think the key point to take from the whole discussion is that Max/ MSP users have a choice, whilst under Pd we have no choice. It's all very well justifying how great it is to not have patch chords, but the lack of that feature/bug definately annoys some [potential] users and puts them off Pd. If the people want it, why not give it to them?
Best,
Chris, who feels totally neutral about segmented patch chords.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On Tue, 4 Dec 2007, Chris McCormick wrote:
I think the key point to take from the whole discussion is that Max/MSP users have a choice, whilst under Pd we have no choice. It's all very well justifying how great it is to not have patch chords, but the lack of that feature/bug definately annoys some [potential] users and puts them off Pd. If the people want it, why not give it to them?
Because it's easier to write a condescending justification for the lack of segmented patchcords than to write the code for segmented patchcords.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Segmenting, coloring, and/or hiding the patch cords aren't going to magically make every patch clear and easy to follow. Once a patch gets to a certain level of density it is time to rethink how the whole thing is structured or find a different tool. Abstractions and subpatches help quite a bit, but at a certain point going 11 windows deep to find or fix something is nearly as ridiculous as cramming everything into a single spider webbed window.
On Dec 5, 2007 1:07 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Tue, 4 Dec 2007, Chris McCormick wrote:
I think the key point to take from the whole discussion is that Max/MSP users have a choice, whilst under Pd we have no choice. It's all very well justifying how great it is to not have patch chords, but the lack of that feature/bug definately annoys some [potential] users and puts them off Pd. If the people want it, why not give it to them?
Because it's easier to write a condescending justification for the lack of segmented patchcords than to write the code for segmented patchcords.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 5 Dec 2007, chris clepper wrote:
Segmenting, coloring, and/or hiding the patch cords aren't going to magically make every patch clear and easy to follow.
I'm not expecting magic. I've never expected magic. I don't see what's the relationship between segmenting/coloring and magic. I don't know why you mention magic.
Any feature that is good enough is going to be abused (but it doesn't mean that anything abusable is good enough). Programming languages are full of very powerful features that you can't fool-proof.
Other features aren't any more magical than segmenting, and yet they are there. So what is your argument trying to say?
Abstractions and subpatches help quite a bit, but at a certain point going 11 windows deep to find or fix something
I envision that there will be a day not too far away from now where I'll get that deep. What it will require is something better than just opening a window per patch and let it all up to the window manager which is usually doesn't have any better policy than letting it all up to the user, which is left with a stack of 11 windows that restacks itself every time you touch it.
is nearly as ridiculous as cramming everything into a single spider webbed window.
There are some excesses in software design sometimes, but for when it's not avoidable, there ought to be a solution for managing it. It's like, the spiderweb kind of window is another excess, and segmented cords can't quite fix it, but there are patchings that are as neat as they can be and yet can't look neat as it is, without involving a detour... there ought to be a solution for managing them.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Yeah, giving people a CHOICE is certainly condescending, what the f*!@?
you do realize not everyone who uses PD is knowledgeable in the
languages, apis and underlying code base to make the modifications
they may request.
If anyone is being condescending, it is you with your attitude of, if
you want that feature, JUST DO IT YOURSELF - part of creating a more
usable tool is to LISTEN to your users, get feedback and consider
implementing those features.
God, I think someone needs to be beaten with a segmented clue stick to
get this point! (har, see what I did there - a joke, ill spell it out
for you so you know im not being absolutely serious).
On Dec 5, 2007, at 2:07 PM, Mathieu Bouchard wrote:
If the people want it, why not give it to them?
Because it's easier to write a condescending justification for the
lack of segmented patchcords than to write the code for segmented
patchcords.
On Wed, 2007-12-05 at 14:33 -0500, vade wrote:
Yeah, giving people a CHOICE is certainly condescending, what the f*!@?
calm down. i have the impression, that you completely misunderstood matju's point. or am i misunderstanding something? i think, he meant, that for (lazy) devs it is easier to find a ('condescending') reason to not implement a certain feature than just implementing straight away.
it seems to me, that you both are on the same track.. :-)
roman
please calm down. i think, that is exactly what matju meant
On Dec 5, 2007, at 2:07 PM, Mathieu Bouchard wrote:
If the people want it, why not give it to them?
Because it's easier to write a condescending justification for the
lack of segmented patchcords than to write the code for segmented
patchcords.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hi guys
As usual a little slow here. I use a segmented patchcord from time to time, its a dummy [sg] object with one inlet and one outlet inserted at the segmentpoint. With PD 0.40-2 you can set the props to 4x4pix and "hide objectname and arguments".
There's a png (120k)here http://steffen.menneske.dk/img/segments.PNG
mvh Stef
On Wed, 5 Dec 2007, Roman Haefeli wrote:
calm down. i have the impression, that you completely misunderstood matju's point. or am i misunderstanding something? i think, he meant, that for (lazy) devs it is easier to find a ('condescending') reason to not implement a certain feature than just implementing straight away.
If you browse the archive of pd-list you will find quite often mails that are basically "you want segmented patchcords just because you can't patch properly". You don't need to put quotes and parens around condescending.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Wed, 5 Dec 2007, vade wrote:
On Dec 5, 2007, at 2:07 PM, Mathieu Bouchard wrote:
If the people want it, why not give it to them?
Because it's easier to write a condescending justification for the lack of segmented patchcords than to write the code for segmented patchcords.
Yeah, giving people a CHOICE is certainly condescending, what the f*!@?
Why don't you READ the damn mail before replying to it? If you weren't trying to skip over half of the words you wouldn't confuse a statement and the exact opposite of it.
Fuddle duddle.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
My apologies. I did infact mis-read this. Sorry Mattieu, I shall put
on my "fucking duddle" cap on immediately - thats what I get for
splitting my attention.
On Dec 5, 2007, at 3:30 PM, Mathieu Bouchard wrote:
On Wed, 5 Dec 2007, vade wrote:
On Dec 5, 2007, at 2:07 PM, Mathieu Bouchard wrote:
If the people want it, why not give it to them?
Because it's easier to write a condescending justification for the
lack of segmented patchcords than to write the code for segmented
patchcords.Yeah, giving people a CHOICE is certainly condescending, what the
f*!@?Why don't you READ the damn mail before replying to it? If you
weren't trying to skip over half of the words you wouldn't confuse a
statement and the exact opposite of it.Fuddle duddle.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
I am trying to subsume what I read so far.
A - READABILITY: readability means that when you look at a patch, you understand its logic and dataflow. readability is important for programmers, when looking at their own patches, but also when looking at other peoples patches. readability is a quality assurance for well written code. it is closely related to documentation and saves time during coding. how do segmented patchcords affect readability?
pro: "makes patches more readable" con: "makes patches less readable"
so what exactly makes a patch less readable?
- lines on top of objects: bad
- overlapping cords from various inlets to various outlets: bad
- overlap cords to save screen real estate: good
- segmented patchcords make you lazy and the general layout of your
patch will suffer. (is that really true?): if yes, then bad
_____
/
[0] |
| |
[+ 1] |
| |
[t i i] |
| __/
B - USEABILITY denotes the ease with which people can employ a particular tool. in some cases the user is a programmer, but I am talking about useability of the patch itself, for example during performance or maintanece (exhibitions, installations...) good user interface is flexible to deal with all kinds of users that may use the program, maybe it allows adoption to certain needs, in general it hides unrelevant information and leads the user to a smooth interaction with the program. how do segmented patchcords affect useability?
if you decide to use cords at all in the UI, then you want to give the user an overall feeling of what parts of the user interface belong together and how the general workflow goes. every additional feature to emphasize that is a plus here. so if you want to do that with colors, then colored cords are a plus, if you want to do that with thickness, then this is a plus, if you want to do it with segmented patchcords, then the availability of them is a plus.
pro: segmented patchcords are a useful feature.
C - GENERAL DESIGN ISSUES: this is about graphical style and interface style. about taste and good looking.
pro: "looks better"
- diagonal lines: look messy (if you are against uniformism that might
be a plus, but then, nature is never uniform... not even with segmented patchcords)
one guideline I hold to in my work is "the user is always right" I think the advantage of segmented patchcords is bigger than the downsides(A2,A4?). This does not solve the problem of how to implement them. feel free to add to this pro/con list... marius.
Mathieu Bouchard wrote:
On Wed, 5 Dec 2007, vade wrote:
On Dec 5, 2007, at 2:07 PM, Mathieu Bouchard wrote:
If the people want it, why not give it to them?
Because it's easier to write a condescending justification for the lack of segmented patchcords than to write the code for segmented patchcords.
Yeah, giving people a CHOICE is certainly condescending, what the f*!@?
Why don't you READ the damn mail before replying to it? If you weren't trying to skip over half of the words you wouldn't confuse a statement and the exact opposite of it.
Fuddle duddle.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Tue, 4 Dec 2007, Chris McCormick wrote:
I think the key point to take from the whole discussion is that Max/MSP users have a choice, whilst under Pd we have no choice. It's all very well justifying how great it is to not have patch chords, but the lack of that feature/bug definately annoys some [potential] users and puts them off Pd. If the people want it, why not give it to them?
Because it's easier to write a condescending justification for the lack of segmented patchcords than to write the code for segmented patchcords.
That's exactly the point: From this thread it seems that many of those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So until someone comes along who wants seg-cords in Pd and at the same time could write the code, the feature stays missing. That's not unusual wiht open source software: features, the developers need, get implemented faster, others maybe never.
Ciao
Frank Barknecht _ ______footils.org__
Le jeudi 06 décembre 2007 à 08:21 +0100, Frank Barknecht a écrit :
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Tue, 4 Dec 2007, Chris McCormick wrote:
I think the key point to take from the whole discussion is that Max/MSP users have a choice, whilst under Pd we have no choice. It's all very well justifying how great it is to not have patch chords, but the lack of that feature/bug definately annoys some [potential] users and puts them off Pd. If the people want it, why not give it to them?
Because it's easier to write a condescending justification for the lack of segmented patchcords than to write the code for segmented patchcords.
That's exactly the point: From this thread it seems that many of those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So until someone comes along who wants seg-cords in Pd and at the same time could write the code, the feature stays missing. That's not unusual wiht open source software: features, the developers need, get implemented faster, others maybe never.
I am a PRO seg-cords as well although I dont miss it since [s/r $0-dingsbums] made my life easier.
Moreover, the code has already been desired and written, "just" not been implemented in vanilla.
Seg-cords + colored box/inlets + pdmtl +pdpedia give the opportunity to really expand the Pd user community, not only the Pd developers side. It took me a while to abandon (definetely I hope, unless the European Community cant resist the lobbying and forbids FLOSS) both traditional sequencers such as Logic (thanks to Pd) and OSes such as OSX (thanks to GNU/Linux), which i did mostly under political reasons (Fight the power :-). Still it would be great that people get _attracted_ to Pd for both its vast possibilities AND usability (including documentation), both low and high level programming prospects.
Cheers! OH
On Thu, 6 Dec 2007, Olivier Heinry wrote:
Moreover, the code has already been desired and written, "just" not been implemented in vanilla.
excuse me, which version of pd really allows you to edit and save cord segmentations?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, Dec 06, 2007 at 04:24:42PM -0500, Mathieu Bouchard wrote:
On Thu, 6 Dec 2007, Olivier Heinry wrote:
Moreover, the code has already been desired and written, "just" not been implemented in vanilla.
excuse me, which version of pd really allows you to edit and save cord segmentations?
Hi Matju,
Didn't I once see screenshots from you of patches that showed segmented and spline curve patch chords?
Best,
Chris.
On Thu, 6 Dec 2007, Chris McCormick wrote:
On Thu, Dec 06, 2007 at 04:24:42PM -0500, Mathieu Bouchard wrote:
On Thu, 6 Dec 2007, Olivier Heinry wrote:
Moreover, the code has already been desired and written, "just" not been implemented in vanilla.
excuse me, which version of pd really allows you to edit and save cord segmentations?
Didn't I once see screenshots from you of patches that showed segmented and spline curve patch chords?
They were all "fake" because they were runtime-generated in order to look funny, instead of being user-generated and savable in order to be useful. They could also be runtime-generated and be useful, but for those who have seen the 3 screenshots and the live demos, it was clearly on the funny side.
Nevertheless, wire segmentations are still on my todo list and if no-one does it for me then i'll do it one day :)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Le jeudi 06 décembre 2007 à 16:24 -0500, Mathieu Bouchard a écrit :
On Thu, 6 Dec 2007, Olivier Heinry wrote:
Moreover, the code has already been desired and written, "just" not been implemented in vanilla.
excuse me, which version of pd really allows you to edit and save cord segmentations?
I trusted your snapshots ;-) What you see isnt always what you get...
On Fri, 7 Dec 2007, Olivier Heinry wrote:
Le jeudi 06 décembre 2007 à 16:24 -0500, Mathieu Bouchard a écrit :
On Thu, 6 Dec 2007, Olivier Heinry wrote:
Moreover, the code has already been desired and written, "just" not been implemented in vanilla.
excuse me, which version of pd really allows you to edit and save cord segmentations?
I trusted your snapshots ;-) What you see isnt always what you get...
The screenshots looked quite random. It didn't look like someone trying to put the wires in any specific place, or an algorithm trying to make them automatically look neat. Drawing the curves is really easy. Making them editable and savable and loadable is more difficult. It's even harder to make them automatically (or semi-automatically) look nice (as in: more understandable).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 6, 2007, at 2:21 AM, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Tue, 4 Dec 2007, Chris McCormick wrote:
I think the key point to take from the whole discussion is that
Max/MSP users have a choice, whilst under Pd we have no choice. It's all
very well justifying how great it is to not have patch chords, but the
lack of that feature/bug definately annoys some [potential] users and
puts them off Pd. If the people want it, why not give it to them?Because it's easier to write a condescending justification for the
lack of segmented patchcords than to write the code for segmented patchcords.That's exactly the point: From this thread it seems that many of those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So until someone comes along who wants seg-cords in Pd and at the same time could write the code, the feature stays missing. That's not unusual wiht open source software: features, the developers need, get implemented faster, others maybe never.
But don't forget, anyone can become a developer, if they want! :D
.hc
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached.
There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape).
I know that Hans' statement re everyone becoming a developer is true in theory, but in reality people who want to rapidly prototype a project with something like Pd or Max are using these applications precisely because they do not want to code in C.
After reading Marius' post re GEM vs. Jitter, it is painfully apparent that the capitalist/consumer model of software engineering has a few aspects to it that are difficult for the FOSS community to compete with. Namely monetary and human resources and the external pressure to meet the requests of the user in order to ensure a continuous flow of financial support. When you code for a hobby or yourself, it is difficult or even impossible to be bothered with these things, and rightly so. Without compensation, there's often little scope (or time) outside one's own projects for developers in the FOSS world. This is unfortunate, but as I see it, true.
Question is, what can be done to change this or compete? Or should Pd just become the thing that hobbyist programmers use, while Max takes the stage as the "serious" tool for rapidly prototyping interactive A/V artworks? I hope that this is not the case...
No flames meant in this mail, just compassionate thought-mulling.
~Kyle
On Dec 6, 2007 1:21 AM, Frank Barknecht fbar@footils.org wrote:
That's exactly the point: From this thread it seems that many of those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So until someone comes along who wants seg-cords in Pd and at the same time could write the code, the feature stays missing. That's not unusual wiht open source software: features, the developers need, get implemented faster, others maybe never.
i read your mail as a pledge for a bounty system - is that right?
Am 06.12.2007 um 20:08 schrieb Kyle Klipowicz:
And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached.
There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape).
I know that Hans' statement re everyone becoming a developer is true in theory, but in reality people who want to rapidly prototype a project with something like Pd or Max are using these applications precisely because they do not want to code in C.
After reading Marius' post re GEM vs. Jitter, it is painfully apparent that the capitalist/consumer model of software engineering has a few aspects to it that are difficult for the FOSS community to compete with. Namely monetary and human resources and the external pressure to meet the requests of the user in order to ensure a continuous flow of financial support. When you code for a hobby or yourself, it is difficult or even impossible to be bothered with these things, and rightly so. Without compensation, there's often little scope (or time) outside one's own projects for developers in the FOSS world. This is unfortunate, but as I see it, true.
Question is, what can be done to change this or compete? Or should Pd just become the thing that hobbyist programmers use, while Max takes the stage as the "serious" tool for rapidly prototyping interactive A/V artworks? I hope that this is not the case...
No flames meant in this mail, just compassionate thought-mulling.
~Kyle
On Dec 6, 2007 1:21 AM, Frank Barknecht fbar@footils.org wrote:
That's exactly the point: From this thread it seems that many of
those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So
until someone comes along who wants seg-cords in Pd and at the same time could write the code, the feature stays missing. That's not unusual wiht open source software: features, the developers need, get implemented faster, others maybe never.--
---- -----
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote:
And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached.
There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape).
Ubuntu, while open source, is a commercial product. Like Redhat Linux and many other commercial FLOSS products. For these kinds of open source software, money of course is one motivation, and if that money comes directly from the user, the user's wishes are a influencing the software more directly. Money is not a bad motivator, and it's even playing a role in our little Pd world, where some projects are or have been funded (like IIRC the early work by Hans on pd-extended, or many docs, which were made for paid workshops etc.)
Ciao
Frank Barknecht _ ______footils.org__
If I were running a commercial software firm and software made by random people in their spare time compared pretty well with my pricey software, I would be a little concerned.
On Dec 6, 2007 1:08 PM, Kyle Klipowicz kyleklip@gmail.com wrote:
And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached.
There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape).
I know that Hans' statement re everyone becoming a developer is true in theory, but in reality people who want to rapidly prototype a project with something like Pd or Max are using these applications precisely because they do not want to code in C.
After reading Marius' post re GEM vs. Jitter, it is painfully apparent that the capitalist/consumer model of software engineering has a few aspects to it that are difficult for the FOSS community to compete with. Namely monetary and human resources and the external pressure to meet the requests of the user in order to ensure a continuous flow of financial support. When you code for a hobby or yourself, it is difficult or even impossible to be bothered with these things, and rightly so. Without compensation, there's often little scope (or time) outside one's own projects for developers in the FOSS world. This is unfortunate, but as I see it, true.
Question is, what can be done to change this or compete? Or should Pd just become the thing that hobbyist programmers use, while Max takes the stage as the "serious" tool for rapidly prototyping interactive A/V artworks? I hope that this is not the case...
No flames meant in this mail, just compassionate thought-mulling.
~Kyle
I think you are mixing up two things, FLOSS can be commercial
software, it often is, think RedHat Enterprise or Digium/Asterisk.
That's free software that they are selling. When people are paid to
work on something, then they can spend more concentrated effort on
it, that's for sure.
To paraphrase Chris, it's unlikely that people doing something in
their spare time would be able to make something as good as people
who are paid fulltime to do the same thing.
As for Pd vs. C, there was a time in the not-so-distant past where
programmers thought that compilers were horribly inefficient, and
that they were only really good for prototyping things. Then you'd
code things for real in assembly. That lasted well into the 80's.
.hc
On Dec 6, 2007, at 2:08 PM, Kyle Klipowicz wrote:
And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached.
There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape).
I know that Hans' statement re everyone becoming a developer is true in theory, but in reality people who want to rapidly prototype a project with something like Pd or Max are using these applications precisely because they do not want to code in C.
After reading Marius' post re GEM vs. Jitter, it is painfully apparent that the capitalist/consumer model of software engineering has a few aspects to it that are difficult for the FOSS community to compete with. Namely monetary and human resources and the external pressure to meet the requests of the user in order to ensure a continuous flow of financial support. When you code for a hobby or yourself, it is difficult or even impossible to be bothered with these things, and rightly so. Without compensation, there's often little scope (or time) outside one's own projects for developers in the FOSS world. This is unfortunate, but as I see it, true.
Question is, what can be done to change this or compete? Or should Pd just become the thing that hobbyist programmers use, while Max takes the stage as the "serious" tool for rapidly prototyping interactive A/V artworks? I hope that this is not the case...
No flames meant in this mail, just compassionate thought-mulling.
~Kyle
On Dec 6, 2007 1:21 AM, Frank Barknecht fbar@footils.org wrote:
That's exactly the point: From this thread it seems that many of
those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So
until someone comes along who wants seg-cords in Pd and at the same time could write the code, the feature stays missing. That's not unusual wiht open source software: features, the developers need, get implemented faster, others maybe never.--
---- -----
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
All information should be free. - the hacker ethic
On Fri, 7 Dec 2007, Hans-Christoph Steiner wrote:
As for Pd vs. C, there was a time in the not-so-distant past where programmers thought that compilers were horribly inefficient, and that they were only really good for prototyping things. Then you'd code things for real in assembly. That lasted well into the 80's.
It even lasted well into the 90's, but it depends for what. The 80's had plenty ofy apps use a blend of asm and C-or-Pascal, while in the 90's it became limited to really needy applications (games, demoscene, etc). The amount of asm code still being written is shrinking but still somewhat present. For example, devel_0_39 has asm code in it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
There are occasional times when segmented patchcords make a patch
more readable, but the vast majority of the time, they are a
distraction at best. I have watched so many Max users spend quite a
bit of time segmenting and organizing their patchcords. If they
instead put that same effort into organizing the code, using
subpatches, etc., the code would be much more readable and maintainable.
There is one thing that a patchcord should clearly communicate, and
that is which two objects are connected. In order to get that
information from a segmented patchcord, you have to follow its path
with your eye. When the patchcord goes straight from one object to
another, the connection is much more apparent and easy to perceive.
.hc
On Dec 4, 2007, at 10:09 AM, marius schebella wrote:
segmented patchcords can make patches less readable, but most of the time they make patches more readable, and that is when you use so many unsegmented cords that they hide the objects. also when you want to connect an object at the bottom of the patch to an object at the top, then you can lay the cord at the outside of the patch to make the ~feed-back. you don't want patchcords in situations where it is not clear anymore which cord is going where. a big problem in max is that there is no undo for segmented
patchcords. once segmented, you can only delete them and redraw to make them not segmented. that might be one of the new features of max 5... as
well as the infinite number of undos. (true?) marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
Hans-Christoph Steiner wrote:
There are occasional times when segmented patchcords make a patch more readable, but the vast majority of the time, they are a distraction at best. I have watched so many Max users spend quite a bit of time segmenting and organizing their patchcords. If they instead put that same effort into organizing the code, using subpatches, etc., the code would be much more readable and maintainable.
There is one thing that a patchcord should clearly communicate, and that is which two objects are connected. In order to get that information from a segmented patchcord, you have to follow its path with your eye. When the patchcord goes straight from one object to another, the connection is much more apparent and easy to perceive.
Yes, I have trouble in Max when the segmented patch cords are all laid on top of each other for neatness.
From my little experiments with pd the connections are even easier to see
when the cords are all coloured differently.
Martin
On Tue, 4 Dec 2007, Martin Peach wrote:
Yes, I have trouble in Max when the segmented patch cords are all laid on top of each other for neatness.
At no time the patchcords ought to overlay themselves exactly above other patchcords. In my idea of segmentation implementation, I'm seriously thinking about introducing mandatory correction to ensure at least a one pixel separation (blank) between parallel patchcords to prevent any accidental confusion. Not that this can't happen with regular patchcords (unless I make exceptions to my layout that might seem contrived... often I don't know where to place things so that it doesn't look ambiguous, and it doesn't take me that many objects to get there)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
There are occasional times when segmented patchcords make a patch more readable, but the vast majority of the time, they are a distraction at best. I have watched so many Max users spend quite a bit of time segmenting and organizing their patchcords. If they instead put that same effort into organizing the code, using subpatches, etc., the code would be much more readable and maintainable.
I agree, with the addition that using segmented patch chords also encourages people to optimise for readability too early on in the patch programming process. A lot of time can be wasted if people focus too much on making things look good early on in patch creation, only to find it needs to be reorganised at some later point.
Jamie
Ah segmented patch coords again.
How about a real solution to the problem of routing objects in diagrams? In PD this could mean a few things:
- Best patching practise!!! Often you can choose not to overlap objects
and connections just by arranging objects as the connections force you to, which gives you the valuable side-effect of having the position of object show the flow of the patch more clearly.
- Empirical tests have shown that curved (spline) connections between
nodes are actually the best way to make them easier to follow, so yay for spline/curved connections and nay for segments! (See p193, figure 6.8 in "Information Visualization: Perception for Design" by Colin Ware.)
- I noticed the new inkscape has some very fancy graph drawing
features, one of which is the ability to tell connections to automatically route around nodes. They are not curved, but the idea of a PD where connections simply avoid objects themselves has a lot of potential.
Of course I'm not saying adding the choice is necessarily a bad thing, but the real question is what nurtures best practise? That remains to be seen, but I'd be very surprised if segmented connections were it.
.b.
marius schebella wrote:
segmented patchcords can make patches less readable, but most of the time they make patches more readable, and that is when you use so many unsegmented cords that they hide the objects. also when you want to connect an object at the bottom of the patch to an object at the top, then you can lay the cord at the outside of the patch to make the ~feed-back. you don't want patchcords in situations where it is not clear anymore which cord is going where. a big problem in max is that there is no undo for segmented patchcords. once segmented, you can only delete them and redraw to make them not segmented. that might be one of the new features of max 5... as well as the infinite number of undos. (true?) marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
B. Bogart wrote:
Ah segmented patch coords again.
How about a real solution to the problem of routing objects in diagrams? In PD this could mean a few things:
- Best patching practise!!! Often you can choose not to overlap objects
and connections just by arranging objects as the connections force you to, which gives you the valuable side-effect of having the position of object show the flow of the patch more clearly.
- Empirical tests have shown that curved (spline) connections between
nodes are actually the best way to make them easier to follow, so yay for spline/curved connections and nay for segments! (See p193, figure 6.8 in "Information Visualization: Perception for Design" by Colin Ware.)
- I noticed the new inkscape has some very fancy graph drawing
features, one of which is the ability to tell connections to automatically route around nodes. They are not curved, but the idea of a PD where connections simply avoid objects themselves has a lot of potential.
Of course I'm not saying adding the choice is necessarily a bad thing, but the real question is what nurtures best practise? That remains to be seen, but I'd be very surprised if segmented connections were it.
And how about patch cords that start out one colour and end up another with a smooth blend all the way along? Then you could identify different cords as well as know which way they were going. The ability to raise or lower objects as in Max ("bring to front", "send to back") and also to have the cords run behind them would be nice. Not sure how much of this is feasible in tk though...also the pd file format would need to be modified to include patch cord colours and object drawing order.
Martin
Dear god, please, no.
no no no no no. No gradiated patch coords. *please*
I would not mind self routing patch coords, but somehow, whenever a
computer/algorithm/programmer tries to do things for me, like
intelligently re-arrange "x", it ends up getting in my way. I suspect
this will be the case for all but the simplest routing around objects
scenario.
But really - Segmented patch coord are a decent solution - I insist
they can help readability, if used correctly.
I mean, whats the difference between a poorly laid out patch WITHOUT
patch segmentation to one WITH segmentation, both are spaghetti! Hard
to read, and will need to be re-laid out /refactored to make any sense.
With segmented patch coords users have the choice to use them, and
well laid out patches with segmentation (again, I really insist), can
be more readable and less visually distracting than those without.
VIVA LLA SEGMENTED PATCH COORD REVOLUTION!
On Dec 5, 2007, at 1:04 PM, Martin Peach wrote:
And how about patch cords that start out one colour and end up
another with a smooth blend all the way along? Then you could identify different
cords as well as know which way they were going. The ability to raise or lower objects as in Max ("bring to front",
"send to back") and also to have the cords run behind them would be nice. Not sure how much of this is feasible in tk though...also the pd
file format would need to be modified to include patch cord colours and object
drawing order.
Segmented patch cords fall somewhere between deferred maintenance and turd polish on the continuum of practicality. Of course in Max you can always resort to sweeping the whole mess under the rug as a last resort.
Stick that in your revolution!
On Dec 5, 2007 12:42 PM, vade doktorp@mac.com wrote:
VIVA LLA SEGMENTED PATCH COORD REVOLUTION!
I say we meet in a back alleyway and beat the crap out of one another
over this.
:)
On Dec 5, 2007, at 2:04 PM, chris clepper wrote:
Segmented patch cords fall somewhere between deferred maintenance
and turd polish on the continuum of practicality. Of course in Max
you can always resort to sweeping the whole mess under the rug as a
last resort.Stick that in your revolution!
On Dec 5, 2007 12:42 PM, vade doktorp@mac.com wrote:
VIVA LLA SEGMENTED PATCH COORD REVOLUTION!
On Dec 5, 2007, at 1:04 PM, Martin Peach wrote:
B. Bogart wrote:
Ah segmented patch coords again.
How about a real solution to the problem of routing objects in
diagrams? In PD this could mean a few things:
- Best patching practise!!! Often you can choose not to overlap
objects and connections just by arranging objects as the connections force
you to, which gives you the valuable side-effect of having the
position of object show the flow of the patch more clearly.
- Empirical tests have shown that curved (spline) connections
between nodes are actually the best way to make them easier to follow, so yay for spline/curved connections and nay for segments! (See p193, figure 6.8 in "Information Visualization: Perception for Design" by Colin
Ware.)
- I noticed the new inkscape has some very fancy graph drawing
features, one of which is the ability to tell connections to automatically route around nodes. They are not curved, but the
idea of a PD where connections simply avoid objects themselves has a lot of potential.Of course I'm not saying adding the choice is necessarily a bad
thing, but the real question is what nurtures best practise? That remains
to be seen, but I'd be very surprised if segmented connections were it.And how about patch cords that start out one colour and end up
another with a smooth blend all the way along? Then you could identify different
cords as well as know which way they were going.
Color really makes things stand out, especially in a black and white
patch. So my question is, what would this color fade be
communicating? A fade would stand out even more than a solid color,
IMHO. What is that fade communicating and is it more important that
other elements, like the object box, the inlets/outlets, the text in
the boxes, etc.
The ability to raise or lower objects as in Max ("bring to front",
"send to back") and also to have the cords run behind them would be nice. Not sure how much of this is feasible in tk though...also the pd
file format would need to be modified to include patch cord colours and object
drawing order.
It's easy to do in Tk, the hard part would be to make Pd handle it,
meaning save and restore that information. That wouldn't be so hard
to code, I suspect it would be harder to get it accepted into core.
.hc
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Hans-Christoph Steiner wrote:
And how about patch cords that start out one colour and end up another with a smooth blend all the way along? Then you could identify different cords as well as know which way they were going.
Color really makes things stand out, especially in a black and white
patch. So my question is, what would this color fade be communicating? A fade would stand out even more than a solid color, IMHO. What is that fade communicating and is it more important that other elements, like the object box, the inlets/outlets, the text in the boxes, etc.
I guess just a quick way to tell which end is which. For instance the originating end could be redder and the terminating end could be bluer (and outlets would be red and inlets blue). Or colour saturation could decline along the cord. It may be more useful if a mouseover made the colours appear, otherwise everything stays black.
Martin
Martin Peach wrote:
Hans-Christoph Steiner wrote:
Color really makes things stand out, especially in a black and white
patch. So my question is, what would this color fade be communicating? A fade would stand out even more than a solid color, IMHO. What is that fade communicating and is it more important that other elements, like the object box, the inlets/outlets, the text in the boxes, etc.I guess just a quick way to tell which end is which. For instance the originating end could be redder and the terminating end could be bluer (and outlets would be red and inlets blue). Or colour saturation could decline along the cord. It may be more useful if a mouseover made the colours appear, otherwise everything stays black.
Martin
I don't know what made me think of this from reading your post, Martin, but it suddenly occurred to me that a good use for color would be red (or orange, or yellow... ) for "hot" inputs to objects. I'm not sure if it could be practically implemented without modifying the object's source, though. While for 99% of objects, it would be the left inlet, in the exceptional cases like [timer], the visual reminder would be particularly valuable.
Phil Stone pkstonemusic.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Dec 5, 2007, at 4:46 PM, Phil Stone wrote:
Martin Peach wrote:
Hans-Christoph Steiner wrote:
Color really makes things stand out, especially in a black and white patch. So my question is, what would this color fade be
communicating? A fade would stand out even more than a solid color, IMHO. What
is that fade communicating and is it more important that other elements,
like the object box, the inlets/outlets, the text in the boxes, etc.I guess just a quick way to tell which end is which. For instance the originating end could be redder and the terminating end could be
bluer (and outlets would be red and inlets blue). Or colour saturation could
decline along the cord. It may be more useful if a mouseover made the colours appear, otherwise everything stays black.Martin
I don't know what made me think of this from reading your post,
Martin, but it suddenly occurred to me that a good use for color would be red (or orange, or yellow... ) for "hot" inputs to objects. I'm not
sure if it could be practically implemented without modifying the object's source, though. While for 99% of objects, it would be the left inlet, in the exceptional cases like [timer], the visual reminder would be particularly valuable.
That is a nice idea, it would be good to have on the GUI Ideas wiki
page:
http://puredata.info/dev/GuiIdeas
I've been playing with a color a bit in Pd-extended recently, I think
a little bit of color used judiciously can definitely make things
more readable. Here are two examples of where I think it helps
(check the inlets/outlets and the error box):
The audio inlets are colored and solid, the message inlets are black/ white box.
.hc
Phil Stone pkstonemusic.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If you are not part of the solution, you are part of the problem.
I think some inlets take both, dsp and messages (throw~ for example). also, did you think about changing the look between edit and run mode? marius.
Hans-Christoph Steiner wrote:
On Dec 5, 2007, at 4:46 PM, Phil Stone wrote:
Martin Peach wrote:
Hans-Christoph Steiner wrote:
Color really makes things stand out, especially in a black and white patch. So my question is, what would this color fade be
communicating? A fade would stand out even more than a solid color, IMHO. What is that fade communicating and is it more important that other elements, like the object box, the inlets/outlets, the text in the boxes, etc.I guess just a quick way to tell which end is which. For instance the originating end could be redder and the terminating end could be bluer (and outlets would be red and inlets blue). Or colour saturation could decline along the cord. It may be more useful if a mouseover made the colours appear, otherwise everything stays black.
Martin
I don't know what made me think of this from reading your post, Martin, but it suddenly occurred to me that a good use for color would be red (or orange, or yellow... ) for "hot" inputs to objects. I'm not sure if it could be practically implemented without modifying the object's source, though. While for 99% of objects, it would be the left inlet, in the exceptional cases like [timer], the visual reminder would be particularly valuable.
That is a nice idea, it would be good to have on the GUI Ideas wiki page:
http://puredata.info/dev/GuiIdeas
I've been playing with a color a bit in Pd-extended recently, I think a little bit of color used judiciously can definitely make things more readable. Here are two examples of where I think it helps (check the inlets/outlets and the error box):
The audio inlets are colored and solid, the message inlets are black/white box.
.hc
Phil Stone pkstonemusic.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you are not part of the solution, you are part of the problem.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yes, definitely, I am thinking of something that combines the two,
like a black box with blue inside. I am going to play with that
more. The problem is that it's trickier to program that, hopefully
it's not too tricky.
.hc
On Dec 6, 2007, at 10:48 AM, marius schebella wrote:
I think some inlets take both, dsp and messages (throw~ for example). also, did you think about changing the look between edit and run mode? marius.
Hans-Christoph Steiner wrote:
On Dec 5, 2007, at 4:46 PM, Phil Stone wrote:
Martin Peach wrote:
Hans-Christoph Steiner wrote:
Color really makes things stand out, especially in a black and
white patch. So my question is, what would this color fade be
communicating? A fade would stand out even more than a solid color, IMHO. What
is that fade communicating and is it more important that other
elements, like the object box, the inlets/outlets, the text in the boxes, etc.I guess just a quick way to tell which end is which. For
instance the originating end could be redder and the terminating end could be
bluer (and outlets would be red and inlets blue). Or colour saturation
could decline along the cord. It may be more useful if a mouseover made the
colours appear, otherwise everything stays black.Martin
I don't know what made me think of this from reading your post,
Martin, but it suddenly occurred to me that a good use for color would be
red (or orange, or yellow... ) for "hot" inputs to objects. I'm not
sure if it could be practically implemented without modifying the object's source, though. While for 99% of objects, it would be the left
inlet, in the exceptional cases like [timer], the visual reminder would be particularly valuable.That is a nice idea, it would be good to have on the GUI Ideas
wiki page: http://puredata.info/dev/GuiIdeas I've been playing with a color a bit in Pd-extended recently, I
think a little bit of color used judiciously can definitely make
things more readable. Here are two examples of where I think it
helps (check the inlets/outlets and the error box):
The audio inlets are colored and solid, the message inlets are
black/white box. .hcPhil Stone pkstonemusic.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
------- If you are not part of the solution, you are part of the
problem.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If you are not part of the solution, you are part of the problem.
On Dec 5, 2007, at 12:45 PM, B. Bogart wrote:
Ah segmented patch coords again.
How about a real solution to the problem of routing objects in
diagrams? In PD this could mean a few things:
- Best patching practise!!! Often you can choose not to overlap
objects and connections just by arranging objects as the connections force you to, which gives you the valuable side-effect of having the position of object show the flow of the patch more clearly.
- Empirical tests have shown that curved (spline) connections between
nodes are actually the best way to make them easier to follow, so yay for spline/curved connections and nay for segments! (See p193, figure 6.8 in "Information Visualization: Perception for Design" by Colin
Ware.)
This is the kind of stuff I am trying to get at. I think that there
is a lot that we can do with Pd to make it feel a lot more natural.
I really want to get into how humans are wired to perceive the world,
and try to reuse some of that existing circuitry to communicate
aspects of Pd on a really low level, like unconscious.
For example, you don't need to think about it to know that you see
something moving. You can actually get substantial amount of data
about a moving object without even being conscious that you paying
attention to it. There is a ton of circuitry in the brain that is
constantly processing the input from all of the senses, and only a
minute fraction of that information is ever brought forth to your
conscious mind. The key part is that you are not ignoring that data,
but processing it in the background. You don't need to be
consciously listening to all sounds to hear your name being called.
I'm going to get that book from the library now, if anyone else knows
some good materials on applying knowledge of persception to design,
please let me know! I haven't found many good resources. Lots of
ideas and attempts, but very few clear concepts or even examples.
.hc
- I noticed the new inkscape has some very fancy graph drawing
features, one of which is the ability to tell connections to automatically route around nodes. They are not curved, but the idea
of a PD where connections simply avoid objects themselves has a lot of potential.Of course I'm not saying adding the choice is necessarily a bad thing, but the real question is what nurtures best practise? That remains
to be seen, but I'd be very surprised if segmented connections were it..b.
marius schebella wrote:
segmented patchcords can make patches less readable, but most of the time they make patches more readable, and that is when you use so
many unsegmented cords that they hide the objects. also when you want to connect an object at the bottom of the patch to an object at the top, then you can lay the cord at the outside of the patch to make the ~feed-back. you don't want patchcords in situations where it is not clear anymore which cord is going where. a big problem in max is that there is no undo for segmented
patchcords. once segmented, you can only delete them and redraw to make them not segmented. that might be one of the new features of max 5... as
well as the infinite number of undos. (true?) marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
In reactable, objects are connected together when inlet/outlet matches the good kind of data, it would be possible to do it also with PureData, without breaking the rules. If a box is dragged nearly another box, the connection would happen when an inlet/outlet passes into the area of another inlet/outlet.
On Dec 4, 2007 10:09 AM, marius schebella marius.schebella@gmail.com wrote:
a big problem in max is that there is no undo for segmented patchcords. once segmented, you can only delete them and redraw to make them not segmented.
That's not true. Ctl-click on a segmented patchcord, unsegments it. I found this "shortcut" by mistake once. Caveat, it does not work on all segemented patchcords. IIRC it works if the patchcord has a minimum of 2 "knees". Or something like that (my max demo expired a while ago).
./MiS
hi lis this is a big discussion :) im a long term pd user, and no max user I vote YES for the segmented patchcords. i belive that it is not good to use them ALWAYS but i came i the situatuon when they come in handy and the user have a chance to choose... if you dont like them do not use them :-), if you need them, they are there. so i hope to see them soon in PD...
greets, n
On Dec 6, 2007 4:58 AM, Michal Seta mis@artengine.ca wrote:
On Dec 4, 2007 10:09 AM, marius schebella marius.schebella@gmail.com wrote:
a big problem in max is that there is no undo for segmented patchcords. once segmented, you can only delete them and redraw to make them not segmented.
That's not true. Ctl-click on a segmented patchcord, unsegments it. I found this "shortcut" by mistake once. Caveat, it does not work on all segemented patchcords. IIRC it works if the patchcord has a minimum of 2 "knees". Or something like that (my max demo expired a while ago).
./MiS
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Michal Seta wrote:
On Dec 4, 2007 10:09 AM, marius schebella marius.schebella@gmail.com wrote:
a big problem in max is that there is no undo for segmented patchcords. once segmented, you can only delete them and redraw to make them not segmented.
That's not true. Ctl-click on a segmented patchcord, unsegments it. I found this "shortcut" by mistake once. Caveat, it does not work on all segemented patchcords. IIRC it works if the patchcord has a minimum of 2 "knees". Or something like that (my max demo expired a while ago).
not on my machine with my max version :( marius.
you have to command click on OS X - it works, and on patch coords with
only one knee too. (select the half towards the inlet).
On Dec 6, 2007, at 10:48 AM, marius schebella wrote:
Michal Seta wrote:
On Dec 4, 2007 10:09 AM, marius schebella
marius.schebella@gmail.com wrote:a big problem in max is that there is no undo for segmented
patchcords. once segmented, you can only delete them and redraw to make them not segmented.That's not true. Ctl-click on a segmented patchcord, unsegments it. I found this "shortcut" by mistake once. Caveat, it does not work on all segemented patchcords. IIRC it works if the patchcord has a minimum of 2 "knees". Or something like that (my max demo expired a while ago).
not on my machine with my max version :( marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
oh! it depends WHERE you click. thanks! marius.
vade wrote:
you have to command click on OS X - it works, and on patch coords with only one knee too. (select the half towards the inlet).
On Dec 6, 2007, at 10:48 AM, marius schebella wrote:
Michal Seta wrote:
On Dec 4, 2007 10:09 AM, marius schebella marius.schebella@gmail.com wrote:
a big problem in max is that there is no undo for segmented patchcords. once segmented, you can only delete them and redraw to make them not segmented.
That's not true. Ctl-click on a segmented patchcord, unsegments it. I found this "shortcut" by mistake once. Caveat, it does not work on all segemented patchcords. IIRC it works if the patchcord has a minimum of 2 "knees". Or something like that (my max demo expired a while ago).
not on my machine with my max version :( marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
B. Bogart -
chris clepper -
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
Jamie Bullock -
Joe Reinsel -
Kyle Klipowicz -
marius schebella -
Martin Peach -
Mathieu Bouchard -
Max Neupert -
Michal Seta -
Nikola Jeremic -
Olivier Heinry -
Patrice Colet -
Phil Stone -
Roman Haefeli -
Steffen Leve Poulsen -
Tim Boykett -
vade