Hi,
I would suggest to implement a 'send' message into send. Then one could do something like this:
This way we could also send messages starting with 'set' and would still be able to send messages starting with 'send'. A workaround would be to prepend all messages with, lets say, 'dummy' and throw this first element away on the receive side....
Olaf
Peter Lunden schrieb:
I think I have to more specific about the problem. In some of the GUI objects there is built in receivers and senders that you set the name of in its preferences. This mechanism is now partly broken because of the new message implemented in [send]
This is how I like to do it, to be able to build nice user interfaces:
float --> [set $0 ( --> [s directly_to_GUI] [r directly_from_GUI]-> same float
It is nesesery to use a set to avoid loops. This makes it possible to have several syncronized sliders at different places controling the same value using the same message.
--PLu
Hans-Christoph Steiner wrote:
You could do it like this:
float --> [s volume] -> [r volume] --> [prepend set] --> [vsl]
.hc
On Thursday, Apr 3, 2003, at 06:46 America/New_York, Peter Lunden wrote:
set message to change the address of the send box is nice but how do you send the message "set 10" to a vsl now. I think it is good to keep the possibility to send set messages to vsl using a send box so the message to change the send should have another name.
--PLu
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
hi Olaf, hi all,
I think c74's solution of having a separate 'forward' object, while keeping the 'send' simple and clean, is a wise one.
Even if it was not, please! do not make incompatibilities even worse than they are now.
Although I think c74's concern was mainly about not breaking existing patches, there are other reasons, why I would lobby for not changing the canonical 'send' behaviour --
In most cases the need for retargetting is the consequence of a bad design. In the rare other cases, it would be nice, if any dangerous, dynamically changing connection in a patch was clearly indicated by the use of a special object name.
Krzysztof
Olaf Matthes wrote: ...
I would suggest to implement a 'send' message into send. Then one could do
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
In most cases the need for retargetting is the consequence of a bad design.
I guess, I never encountered a need for send-setting, that wasn't solvable with [; $1 $2( in my patches.
Frank Barknecht _ ______footils.org__
On Thu, 3 Apr 2003, Frank Barknecht wrote:
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
In most cases the need for retargetting is the consequence of a bad design.
I guess, I never encountered a need for send-setting, that wasn't solvable with [; $1 $2( in my patches.
If I have intruduced this in the CVS version (the send set), I am willing to throw it out again and put the settable send/receive stuff into the externals again.
Votes ?
Guenter
I think its a nice idea to have the functionality but there is problems with the naming. I vote for a change of the name of the "set address" message in [send].
--PLu
guenter geiger wrote:
On Thu, 3 Apr 2003, Frank Barknecht wrote:
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
In most cases the need for retargetting is the consequence of a bad design.
I guess, I never encountered a need for send-setting, that wasn't solvable with [; $1 $2( in my patches.
If I have intruduced this in the CVS version (the send set), I am willing to throw it out again and put the settable send/receive stuff into the externals again.
Votes ?
Guenter
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi all,
I really think having a "forward" object would be the way to do it compatibly with Max/MSP, so it's probably better not to add a "set" or other message to the send object.
cheers Miller
On Sat, Apr 05, 2003 at 04:55:55PM +0200, Peter Lundén wrote:
I think its a nice idea to have the functionality but there is problems with the naming. I vote for a change of the name of the "set address" message in [send].
--PLu
guenter geiger wrote:
On Thu, 3 Apr 2003, Frank Barknecht wrote:
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
In most cases the need for retargetting is the consequence of a bad design.
I guess, I never encountered a need for send-setting, that wasn't solvable with [; $1 $2( in my patches.
If I have intruduced this in the CVS version (the send set), I am willing to throw it out again and put the settable send/receive stuff into the externals again.
Votes ?
Guenter
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi all, as another wish i'd really like to have a built-in [prepend] object. It's the object that i miss most.
best greetings, T
Zitat von Thomas Grill t.grill@gmx.net:
Hi all, as another wish i'd really like to have a built-in [prepend] object. It's the object that i miss most.
yes, but which one ? there are 3 different ones (at least) and unfortunately they behave different. for example i use cyclone's "prepend" that uses a "set" mesage (again ;-) to change its argument rather than with a second inlet...
might lead to problems regarding backwards compatibility (although not that bad...)
ciao
oliver
best greetings, T
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
This mail sent through IMP: http://horde.org/imp/
Hallo, stotz hat gesagt: // stotz wrote:
yes, but which one ? there are 3 different ones (at least) and unfortunately they behave different. for example i use cyclone's "prepend" that uses a "set" mesage (again ;-) to change its argument rather than with a second inlet...
might lead to problems regarding backwards compatibility (although not that bad...)
I would prefer a solution, that is compatible to Max, whichever that is. The rest can be fixed with a wrapper abstraction.
Frank Barknecht _ ______footils.org__
I think that we should generally avoid breaking established behaviors whenever possible. The old behavoir seems decently established, in Pd and Max, so we should probably keep it that way.
.hc
On Saturday, Apr 5, 2003, at 06:18 America/New_York, guenter geiger wrote:
On Thu, 3 Apr 2003, Frank Barknecht wrote:
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
In most cases the need for retargetting is the consequence of a bad design.
I guess, I never encountered a need for send-setting, that wasn't solvable with [; $1 $2( in my patches.
If I have intruduced this in the CVS version (the send set), I am willing to throw it out again and put the settable send/receive stuff into the externals again.
Votes ?
Guenter
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
I second this.
Chris.
On Sat, 5 Apr 2003 14:17:54 -0500 Hans-Christoph Steiner hans@eds.org wrote:
I think that we should generally avoid breaking established behaviors whenever possible. The old behavoir seems decently established, in Pd and Max, so we should probably keep it that way.
.hc
On Saturday, Apr 5, 2003, at 06:18 America/New_York, guenter geiger wrote:
On Thu, 3 Apr 2003, Frank Barknecht wrote:
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
In most cases the need for retargetting is the consequence of a bad design.
I guess, I never encountered a need for send-setting, that wasn't solvable with [; $1 $2( in my patches.
If I have intruduced this in the CVS version (the send set), I am willing to throw it out again and put the settable send/receive stuff into the externals again.
Votes ?
Guenter
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list