Hi all,
It seems that both the mrpeach and iemnet udpreceive implementations are designed to not handle multiple object instances receiving on the same port.
What I want to do is instantiate [udpreceive 5000] and then another [udpreceive 5000] I get the same data to both objects.
Instead, in the case of mrpeach, the second object can't be instantiated, and iemnet/udpreceive just fails silently.
Would the respective authors of these objects consider adding this 'multiple instances with same port' functionality?
Alternatively, can anyone suggest away to achieve the same result with the existing objects?
All best,
Jamie
On 04/05/11 12:32, Jamie Bullock wrote:
What I want to do is instantiate [udpreceive 5000] and then another [udpreceive 5000] I get the same data to both objects. Alternatively, can anyone suggest away to achieve the same result with the existing objects?
You could (but see caveat below) make an abstraction [myudpreceive]:
----8<---- [udpreceive $1] | [send MYUDPRECEIVE-$1]
[receive MYUDPRECEIVE-$1] | [outlet] ----8<----
The top half will only work in one instance but the bottom half will work in all of them.
But: expect problems if you delete the original instance with the working/instantiated [udpreceive]... so probably better to have one "toplevel" / "master" [udpreceive] that sends to a global receive name.
Claude
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-05-04 14:02, Claude Heiland-Allen wrote:
You could (but see caveat below) make an abstraction [myudpreceive]:
----8<---- [udpreceive $1] | [send MYUDPRECEIVE-$1]
[receive MYUDPRECEIVE-$1] | [outlet] ----8<----
The top half will only work in one instance but the bottom half will work in all of them.
But: expect problems if you delete the original instance with the working/instantiated [udpreceive]...
iemnet's [udpreceive] should take over in this case (at least that's what it does here; i cannot remember having designed this)
dfmsr IOhannes
On 4 May 2011, at 13:29, IOhannes m zmoelnig wrote:
But: expect problems if you delete the original instance with the working/instantiated [udpreceive]...
iemnet's [udpreceive] should take over in this case (at least that's what it does here; i cannot remember having designed this)
Ah yes, just checked and you're right - nice feature!
Jamie
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-05-04 13:32, Jamie Bullock wrote:
Instead, in the case of mrpeach, the second object can't be instantiated, and iemnet/udpreceive just fails silently.
with iemnet, it's not so "silently". rather, you can query the object whether it was able to bind to the port (and eventually change it)
Would the respective authors of these objects consider adding this 'multiple instances with same port' functionality?
well, problem is that ports are designed to be used exclusively (e.g. if you have a web-server running on port 80, you cannot have another webserver running on port 80.
fgmasdr IOhannes
On 4 May 2011, at 13:26, IOhannes m zmoelnig wrote:
well, problem is that ports are designed to be used exclusively (e.g. if you have a web-server running on port 80, you cannot have another webserver running on port 80.
I get that, but it doesn't mean our Pd externals have to mirror the behaviour of lower-level operations.
Currently [udpreceive 5000] means 'open a UDP socket on port 5000 and give me the received data', but that's not the only way.
I'd like it to behave a little higher level: 'give me data received over UDP on port 5000'. In my version, we don't care if the object is creating a new socket, or giving us data from an already established socket.
Jamie
I like this idea, since [udpreceive ] mirrors [receive], it makes
sense that it would act like it too.
I implemented something like this for [hidio] which never really made
it out of SVN. The code is there in externals/io/hidio for anyone to
see. Basically, the first instance will do the actual work, in this
case receiving data from UDP port 5000 and write it to a chunk of
memory. Then all instances output that chunk of memory.
.hc
On May 4, 2011, at 7:32 AM, Jamie Bullock wrote:
Hi all,
It seems that both the mrpeach and iemnet udpreceive implementations
are designed to not handle multiple object instances receiving on
the same port.What I want to do is instantiate [udpreceive 5000] and then another
[udpreceive 5000] I get the same data to both objects.Instead, in the case of mrpeach, the second object can't be
instantiated, and iemnet/udpreceive just fails silently.Would the respective authors of these objects consider adding this
'multiple instances with same port' functionality?Alternatively, can anyone suggest away to achieve the same result
with the existing objects?All best,
Jamie _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
¡El pueblo unido jamás será vencido!
-
Claude Heiland-Allen -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jamie Bullock