I often find myself wanting to connect multiple messages to a single object, or one outlet to several receivers, or what not. Since someone brought up the subject of making editing easier, what about being able to select multiple objects/messages/guis and draw one connection, and have PD duplicate that connection from or to all of the selected objects with the corresponding inlet/outlet? Sometimes I actually open a patch in a text editor and manually copy and paste connections.
-Chuckk
-- "It is not when truth is dirty, but when it is shallow, that the lover of knowledge is reluctant to step into its waters." -Friedrich Nietzsche, "Thus Spoke Zarathustra"
or one outlet to several receivers, or what not.
actually max has a nice sollution for that: pressing shift while making a connection automatically brings up another cable from the same output. It would be good to have something like that on pd as well.
I think he wants the reverse of this: to have multiple outputs from messages to a single input.
On 3/14/06, João Miguel Pais jmmmpais@googlemail.com wrote:
or one outlet to several receivers, or what not.
actually max has a nice sollution for that: pressing shift while making a connection automatically brings up another cable from the same output. It would be good to have something like that on pd as well.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- http://perhapsidid.blogspot.com (((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
or one outlet to several receivers, or what not.
actually max has a nice sollution for that: pressing shift while making a connection automatically brings up another cable from the same output. It would be good to have something like that on pd as well.
... and then people will complain that their patches do strange things because they created fanning-connections with undefined execution order instead of properly using the trigger-object.
I don't think it's a good idea to encourage outlet-fanning with a keyboard shortcut.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Tue, 14 Mar 2006, Frank Barknecht wrote:
I don't think it's a good idea to encourage outlet-fanning with a keyboard shortcut.
What if outlet-fanning's behaviour was actually defined? that cords could be ordered? (numbered or otherwise)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
What if outlet-fanning's behaviour was actually defined? that cords could be ordered? (numbered or otherwise)
An interesting approach could be to automatically extrude a [trigger] object as soon as one tries to fan from an outlet. You know, extruding like in an old movie by David Cronenberg. The new object flesh. That would be fun.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Why not let multiple objects be selected at once, and then when holding shift, all of their first outlets "extrude" a cord that can be connected to a single inlet?
~Kyle
On 3/14/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
What if outlet-fanning's behaviour was actually defined? that cords could be ordered? (numbered or otherwise)
-- http://perhapsidid.blogspot.com (((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
... and then people will complain that their patches do strange things because they created fanning-connections with undefined execution order instead of properly using the trigger-object.
I don't think it's a good idea to encourage outlet-fanning with a keyboard shortcut.
you don't need trigger for all occasions. sometimes it doesn't matter in
which order the messages are sent, only that they arrive - like in come
cases where building a spider web is necessary because of lots of
inputs/outputs to connect (for one example look at the hide-show subpatch
on my gui-edit abstraction). I don't do anything without trigger, when
it's necessary.
But it's also not that bad to let people make mistakes. Then they'll learn
quite faster.
João Miguel Pais wrote:
... and then people will complain that their patches do strange things because they created fanning-connections with undefined execution order instead of properly using the trigger-object.
I don't think it's a good idea to encourage outlet-fanning with a keyboard shortcut.
you don't need trigger for all occasions. sometimes it doesn't matter in which order the messages are sent, only that they arrive - like in come cases where building a spider web is necessary because of lots of
this is true, but it is a special case where the programmer has to know that the order does not matter. it is a bad design for a programming language, if it tends to create programs that behave "somehow".
But it's also not that bad to let people make mistakes. Then they'll learn quite faster.
allowing people to make mistakes is something different than helping (enforcing) people to make mistakes. the former could be considered as some (weird) form of education, while the latter is just offending.
mfg.asdr. IOhannes
you don't need trigger for all occasions. sometimes it doesn't matter in which order the messages are sent, only that they arrive - like in come cases where building a spider web is necessary because of lots of
this is true, but it is a special case where the programmer has to know that the order does not matter. it is a bad design for a programming language, if it tends to create programs that behave "somehow".
how about forbiding more than one connection per outlet? I'm sure it's
quite easy to do, that would make the language perfect, no mistakes
allowed.
I don't know, I think that there are more bad users than bad languages
(I'm not a programmer and this is an exageration). But removing one's
options so that the user makes no "mistakes" seems to me to be in the end
just too restrictive. everyone has the right to make mistakes, and the
documentation is there to show which is the best way.
But it's also not that bad to let people make mistakes. Then they'll learn quite faster.
allowing people to make mistakes is something different than helping (enforcing) people to make mistakes. the former could be considered as some (weird) form of education, while the latter is just offending.
helping (and enforcing) people to do mistakes would be to advise them to
ignore the advantages of the toggle, and tell them not to use it (that I
find also offensive to the guys that programmed this object, and to the
users).
I don't find it weird to make people learn through mistakes, I do it and
with good results so far, I think (a personal choice). If you burn
yourself on fire, you'll for sure never more be near it (no need to burn a
whole arm, though). If someone tells you that fire is bad, you will
believe it and remember the information, but until you experience it
yourself you won't know exactly why.
João Miguel Pais wrote:
(I'm not a programmer and this is an exageration). But removing one's options so that the user makes no "mistakes" seems to me to be in the end just too restrictive. everyone has the right to make mistakes, and the documentation is there to show which is the best way.
i have not said that i want to remove the option to make mistakes. i just said, that we should not _enforce_ the user to make mistakes.
it seems to me a "feature", the sole purpose of which is to slap the user on their forehead until they learn that they should take care. and even if they had learned to take care, they will still be slapped. so why should anyone want to implement this?
But it's also not that bad to let people make mistakes. Then they'll learn quite faster.
allowing people to make mistakes is something different than helping (enforcing) people to make mistakes. the former could be considered as some (weird) form of education, while the latter is just offending.
at least in austria, slapping children for educational purposes is - while still practiced by several individuals - officially forbidden, and i am glad it is...;-)
helping (and enforcing) people to do mistakes would be to advise them to ignore the advantages of the toggle, and tell them not to use it (that I find also offensive to the guys that programmed this object, and to the users).
did i say that?
mfg.asdr. IOhannes
i have not said that i want to remove the option to make mistakes. i just said, that we should not _enforce_ the user to make mistakes.
it seems to me a "feature", the sole purpose of which is to slap the user on their forehead until they learn that they should take care. and even if they had learned to take care, they will still be slapped. so why should anyone want to implement this?
how about a flag for that at program start to make everybody happy? this
discussion is going too far, maybe it isn't worth it.
at least in austria, slapping children for educational purposes is - while still practiced by several individuals - officially forbidden, and i am glad it is...;-)
oh, I can never get enough from a good slaping, specially if leather is
envolved.
helping (and enforcing) people to do mistakes would be to advise them to ignore the advantages of the toggle, and tell them not to use it (that I find also offensive to the guys that programmed this object, and to the users).
did i say that?
no, I don't think so.
-
Chuckk Hubbard -
Frank Barknecht -
IOhannes m zmoelnig -
João Miguel Pais -
Kyle Klipowicz -
Mathieu Bouchard