hi!
i need to send OSC messages to a number of smartphones via UDP. the phones are used as remote controls for the patch, so i send the status of the patch to the phones every second. since the phones are sometimes out of WLAN reach or switched off, i send a [connect( message to [netsend] every second to keep in touch. and i get loads of “already connected” errors.
this might have caused to fill up the ram on the raspi on which pd runs, so i sent stderr to devnull.
still, do you think it is better to disconnect every time before connecting, or might this cause some other problems?
cheers! mkl
Yes, do disconnect each time before re-connecting. This shouldn't hurt.
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le ven. 25 janv. 2019 à 11:31, michael strohmann itsnotfair9@gmail.com a écrit :
hi!
i need to send OSC messages to a number of smartphones via UDP. the phones are used as remote controls for the patch, so i send the status of the patch to the phones every second. since the phones are sometimes out of WLAN reach or switched off, i send a [connect( message to [netsend] every second to keep in touch. and i get loads of “already connected” errors.
this might have caused to fill up the ram on the raspi on which pd runs, so i sent stderr to devnull.
still, do you think it is better to disconnect every time before connecting, or might this cause some other problems?
cheers! mkl
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Fri, 2019-01-25 at 11:31 +0100, michael strohmann wrote:
i need to send OSC messages to a number of smartphones via UDP. the phones are used as remote controls for the patch, so i send the status of the patch to the phones every second. since the phones are sometimes out of WLAN reach or switched off, i send a [connect( message to [netsend] every second to keep in touch. and i get loads of “already connected” errors.
Reconnecting is not necessary, since you are using UDP. UDP has no notion of connection. Packets are still sent, even if you switch off the receiving devices or if they go out of WLAN reach. Reconnecting would only be necessary with a TCP connection and only when one of the ends has terminated the connection.
this might have caused to fill up the ram on the raspi on which pd runs, so i sent stderr to devnull.
still, do you think it is better to disconnect every time before connecting, or might this cause some other problems?
Although UDP has no notion of connection, the [netsend -u] has. When you send another 'connect' message without a previous 'disconnect' message, the 'connect' message actually has no effect at all. The same connection is still used. The error indicates that a destination has already been configured and you need to 'disconnect' first before changing the destination.
To answer your question: If you want to change destination, you _need_ to disconnect first. However, in your example neither is necessary. Just leave the Pd side connected.
Roman
thanks for the answer! but, in order to show that there is a connection betwenn the app to pd i do:
[metro 1000]
|
[toggle(
|
[oscformat BlinkingButton/value]
|
[list prepend send]
|
[list trim]
|
| [t b]
| |
| [disconnect, connect 192.168.178.189 8000(
| /
[netsend -u -b]
now everytime the phone is not available i get: recv: Connection refused (111) netsend: Bad file descriptor (9) warning: 35 removed from poll list but not found
if i dont disconnect before sending i get the “already connected” error. and if i only connect once and leave the pd side connected, no messages are received on the phone once it leaves the wlan.
messages sent from the phone are almost always received.
in any case it get a console message, either “connecting to port 8000” or “already connected”
i am just concerned because my patch crashes or freezes or create glitchy digital artefacts from time to time, and since it is a 24/7 audio installation i would like it to work. how to find these bugs...
On 25 Jan 2019, at 11:50, Roman Haefeli reduzent@gmail.com wrote:
On Fri, 2019-01-25 at 11:31 +0100, michael strohmann wrote:
i need to send OSC messages to a number of smartphones via UDP. the phones are used as remote controls for the patch, so i send the status of the patch to the phones every second. since the phones are sometimes out of WLAN reach or switched off, i send a [connect( message to [netsend] every second to keep in touch. and i get loads of “already connected” errors.
Reconnecting is not necessary, since you are using UDP. UDP has no notion of connection. Packets are still sent, even if you switch off the receiving devices or if they go out of WLAN reach. Reconnecting would only be necessary with a TCP connection and only when one of the ends has terminated the connection.
this might have caused to fill up the ram on the raspi on which pd runs, so i sent stderr to devnull.
still, do you think it is better to disconnect every time before connecting, or might this cause some other problems?
Although UDP has no notion of connection, the [netsend -u] has. When you send another 'connect' message without a previous 'disconnect' message, the 'connect' message actually has no effect at all. The same connection is still used. The error indicates that a destination has already been configured and you need to 'disconnect' first before changing the destination.
To answer your question: If you want to change destination, you _need_ to disconnect first. However, in your example neither is necessary. Just leave the Pd side connected.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Fri, 2019-01-25 at 15:01 +0100, michael strohmann wrote:
thanks for the answer! but, in order to show that there is a connection betwenn the app to pd i do:
[metro 1000]
[toggle(
[oscformat BlinkingButton/value]
[list prepend send]
[list trim]
[t b] | [disconnect, connect 192.168.178.189 8000( /[netsend -u -b]
now everytime the phone is not available i get: recv: Connection refused (111) netsend: Bad file descriptor (9) warning: 35 removed from poll list but not found
if i dont disconnect before sending i get the “already connected” error. and if i only connect once and leave the pd side connected, no messages are received on the phone once it leaves the wlan.
messages sent from the phone are almost always received.
in any case it get a console message, either “connecting to port 8000” or “already connected”
i am just concerned because my patch crashes or freezes or create glitchy digital artefacts from time to time, and since it is a 24/7 audio installation i would like it to work. how to find these bugs...
Oh, I see. That's much messier than I thought. I always believed an UDP socket stays open regardless of the presence of the other end. But seems to be not fully true. I'm not sure what's going on but it looks like the OS closes the socket without [netsend] actually noticing it.
I would try what Antoine suggested and send a 'disconnect' each time before you connect again. There should be no harm in 'disconnect'ing and 'connect'ing many times.
Roman
What you found, challenged my understanding of UDP and it seems, depending on implementation, the sender socket is in some cases notified about the termination of the receiving socket.
When I connect [netsend -u] to a small python script that opens a listening socket, i can kill the script and start it again and [netsend -u] can still send packets. When I connect to 'nc -v -u -l -p 11579' instead, [netsend -b] can send packets only as long as the process is running. When I kill nc and start it again, no messages reach their destination anymore. I have to 'disconnect' and 'connect'.
So what kind of software is opening the listening socket on the phone?
Roman
On Fri, 2019-01-25 at 15:14 +0100, Roman Haefeli wrote:
On Fri, 2019-01-25 at 15:01 +0100, michael strohmann wrote:
thanks for the answer! but, in order to show that there is a connection betwenn the app to pd i do:
[metro 1000]
[toggle(
[oscformat BlinkingButton/value]
[list prepend send]
[list trim]
[t b] | [disconnect, connect 192.168.178.189 8000( /[netsend -u -b]
now everytime the phone is not available i get: recv: Connection refused (111) netsend: Bad file descriptor (9) warning: 35 removed from poll list but not found
if i dont disconnect before sending i get the “already connected” error. and if i only connect once and leave the pd side connected, no messages are received on the phone once it leaves the wlan.
messages sent from the phone are almost always received.
in any case it get a console message, either “connecting to port 8000” or “already connected”
i am just concerned because my patch crashes or freezes or create glitchy digital artefacts from time to time, and since it is a 24/7 audio installation i would like it to work. how to find these bugs...
Oh, I see. That's much messier than I thought. I always believed an UDP socket stays open regardless of the presence of the other end. But seems to be not fully true. I'm not sure what's going on but it looks like the OS closes the socket without [netsend] actually noticing it.
I would try what Antoine suggested and send a 'disconnect' each time before you connect again. There should be no harm in 'disconnect'ing and 'connect'ing many times.
Roman
Thanks for looking into this. The listener is an app called Lemur which receives and sends OSC messages . I don’t know too much about the workings of this app though...
Am 25.01.2019 um 15:35 schrieb Roman Haefeli reduzent@gmail.com:
What you found, challenged my understanding of UDP and it seems, depending on implementation, the sender socket is in some cases notified about the termination of the receiving socket.
When I connect [netsend -u] to a small python script that opens a listening socket, i can kill the script and start it again and [netsend -u] can still send packets. When I connect to 'nc -v -u -l -p 11579' instead, [netsend -b] can send packets only as long as the process is running. When I kill nc and start it again, no messages reach their destination anymore. I have to 'disconnect' and 'connect'.
So what kind of software is opening the listening socket on the phone?
Roman
On Fri, 2019-01-25 at 15:14 +0100, Roman Haefeli wrote:
On Fri, 2019-01-25 at 15:01 +0100, michael strohmann wrote: thanks for the answer! but, in order to show that there is a connection betwenn the app to pd i do:
[metro 1000]
[toggle(
[oscformat BlinkingButton/value]
[list prepend send]
[list trim]
[t b] | [disconnect, connect 192.168.178.189 8000( /[netsend -u -b]
now everytime the phone is not available i get: recv: Connection refused (111) netsend: Bad file descriptor (9) warning: 35 removed from poll list but not found
if i dont disconnect before sending i get the “already connected” error. and if i only connect once and leave the pd side connected, no messages are received on the phone once it leaves the wlan.
messages sent from the phone are almost always received.
in any case it get a console message, either “connecting to port 8000” or “already connected”
i am just concerned because my patch crashes or freezes or create glitchy digital artefacts from time to time, and since it is a 24/7 audio installation i would like it to work. how to find these bugs...
Oh, I see. That's much messier than I thought. I always believed an UDP socket stays open regardless of the presence of the other end. But seems to be not fully true. I'm not sure what's going on but it looks like the OS closes the socket without [netsend] actually noticing it.
I would try what Antoine suggested and send a 'disconnect' each time before you connect again. There should be no harm in 'disconnect'ing and 'connect'ing many times.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
the sender socket is in some cases notified about the termination of the receiving socket.
this what happens in Pd with [netsend -u], but it's *not* what one would expect from UDP. on all the socket libraries I've used, "connect" doesn't do much on a UDP socket, it only sets the default address, so you don't have to provide it explicitly for every datagram you send, and you can change it whenever you like. see also: http://man7.org/linux/man-pages/man2/connect.2.html
So UDP shouldn't really know if the destination socket actually exists because there is no established connection. I actually filed a bug report which is somehow related to this: https://github.com/pure-data/pure-data/issues/373
Note that [udpsend] from iemlib / mrpeach behaves correctly in that it doesn't stop working if the destination doesn't exist.
I promised to look at the code and find out what's really going on in [netsend -u] but I didn't have time yet :-(
Christof
Gesendet: Freitag, 25. Januar 2019 um 15:35 Uhr Von: "Roman Haefeli" reduzent@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] ugly "already connected" errors
What you found, challenged my understanding of UDP and it seems, depending on implementation, the sender socket is in some cases notified about the termination of the receiving socket.
When I connect [netsend -u] to a small python script that opens a listening socket, i can kill the script and start it again and [netsend -u] can still send packets. When I connect to 'nc -v -u -l -p 11579' instead, [netsend -b] can send packets only as long as the process is running. When I kill nc and start it again, no messages reach their destination anymore. I have to 'disconnect' and 'connect'.
So what kind of software is opening the listening socket on the phone?
Roman
On Fri, 2019-01-25 at 15:14 +0100, Roman Haefeli wrote:
On Fri, 2019-01-25 at 15:01 +0100, michael strohmann wrote:
thanks for the answer! but, in order to show that there is a connection betwenn the app to pd i do:
[metro 1000]
[toggle(
[oscformat BlinkingButton/value]
[list prepend send]
[list trim]
[t b] | [disconnect, connect 192.168.178.189 8000( /[netsend -u -b]
now everytime the phone is not available i get: recv: Connection refused (111) netsend: Bad file descriptor (9) warning: 35 removed from poll list but not found
if i dont disconnect before sending i get the “already connected” error. and if i only connect once and leave the pd side connected, no messages are received on the phone once it leaves the wlan.
messages sent from the phone are almost always received.
in any case it get a console message, either “connecting to port 8000” or “already connected”
i am just concerned because my patch crashes or freezes or create glitchy digital artefacts from time to time, and since it is a 24/7 audio installation i would like it to work. how to find these bugs...
Oh, I see. That's much messier than I thought. I always believed an UDP socket stays open regardless of the presence of the other end. But seems to be not fully true. I'm not sure what's going on but it looks like the OS closes the socket without [netsend] actually noticing it.
I would try what Antoine suggested and send a 'disconnect' each time before you connect again. There should be no harm in 'disconnect'ing and 'connect'ing many times.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Fri, 2019-01-25 at 21:09 +0100, Christof Ressi wrote:
the sender socket is in some cases notified about the termination of the receiving socket.
this what happens in Pd with [netsend -u], but it's *not* what one would expect from UDP. on all the socket libraries I've used, "connect" doesn't do much on a UDP socket, it only sets the default address, so you don't have to provide it explicitly for every datagram you send, and you can change it whenever you like. see also: http://man7.org/linux/man-pages/man2/connect.2.html
So UDP shouldn't really know if the destination socket actually exists because there is no established connection. I actually filed a bug report which is somehow related to this: https://github.com/pure-data/pure-data/issues/373
Note that [udpsend] from iemlib / mrpeach behaves correctly in that it doesn't stop working if the destination doesn't exist.
I promised to look at the code and find out what's really going on in [netsend -u] but I didn't have time yet :-(
If I understand you correctly, you observe a difference between [netsend -u] and [iemnet/udpsend].
Contrary to your observation, I observe that both behave similar, but only [netsend -u] shows an appropriate error.
It seems that sending UDP datagrams to an unreachable destination causes the internal socket of [udpsend] or [netsend -u] to be closed. [netsend -u] even reflects that by sending '0' to its outlet. But you can tell that the socket of [udpsend] is closed, because when you fire up the listening socket again, messages sent with [udpsend] still don't reach their destination. You have to first 'disconnect' and'connect' again, before messages are actually sent. Also here, [netsend -u] is more consistent in that you have to only 'connect' (it is already in a disconnected state).
From reading a bit more about protocols, particularly about ICMP [1], I think what happens is that the receiving host sends a ICMP error packet to the sending host, telling that the destination port is unreachable.
It's important to note that merely sending 'connect' to [udpsend]/[netsend -u] doesn't trigger a ICMP error message. You have to actually send a datagram for that to happen. So the notion that UDP has no notion of a connection is still valid.
You can send data to a destination, close the socket on the destination, open it again and still send data. However, when you send data at the time the receiving socket is closed, the ICMP message is triggered.
Also, not all firewalls let such a ICMP response pass, so you might find some setups where the socket of [netsend -u] and [udpsend] is not shut down.
I don't think [netsend] has a bug in this regard. The only inconsisteny I can see with [netsend] is that you need to send actually two messages to an unreachable destination before it outputs a '0' (the first message only triggers the error: 'recv: Connection refused (111)').
[udpsend] doesn't even show an error or reports anything to its outlet, although its socket was shut down. That might be worth writing a bug report for.
Roman
[1] https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Destination_...
From reading a bit more about protocols, particularly about ICMP [1], I think what happens is that the receiving host sends a ICMP error packet to the sending host, telling that the destination port is unreachable.
thanks, this might explain what happens. note, though, that this is not required behaviour for a UDP socket (and I haven't encountered this outside Pd), so I would rather make this optional (or add an option to deactivate this). The reason is that sometimes you just want to broadcast messages no matter if something is actually listening and you don't want that the sender to shut down just because the receiver is temporarily unavailable. of course you can wrap each message in a [connect( [disconnect( pair, but I think it's only an ugly workaround.
can tell that the socket of [udpsend] is closed, because when you fire up the listening socket again, messages sent with [udpsend] still don't reach their destination.
I can't confirm this. I just tested with a pair of [udpsend] and [udpreceive] (both iemlib and mrpeach) and I can change ports in [udpreceive] or delete/recreate it without [udpsend] closing its socket. only tested via localhost, though.
The only inconsisteny I can see with [netsend] is that you need to send actually two messages to an unreachable destination before it outputs a '0' (the first message only triggers the error: 'recv: Connection refused (111)').
that's true. I have observed this too.
Christof
Gesendet: Freitag, 25. Januar 2019 um 22:25 Uhr Von: "Roman Haefeli" reduzent@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list@lists.iem.at Betreff: Re: Aw: Re: [PD] ugly "already connected" errors
On Fri, 2019-01-25 at 21:09 +0100, Christof Ressi wrote:
the sender socket is in some cases notified about the termination of the receiving socket.
this what happens in Pd with [netsend -u], but it's *not* what one would expect from UDP. on all the socket libraries I've used, "connect" doesn't do much on a UDP socket, it only sets the default address, so you don't have to provide it explicitly for every datagram you send, and you can change it whenever you like. see also: http://man7.org/linux/man-pages/man2/connect.2.html
So UDP shouldn't really know if the destination socket actually exists because there is no established connection. I actually filed a bug report which is somehow related to this: https://github.com/pure-data/pure-data/issues/373
Note that [udpsend] from iemlib / mrpeach behaves correctly in that it doesn't stop working if the destination doesn't exist.
I promised to look at the code and find out what's really going on in [netsend -u] but I didn't have time yet :-(
If I understand you correctly, you observe a difference between [netsend -u] and [iemnet/udpsend].
Contrary to your observation, I observe that both behave similar, but only [netsend -u] shows an appropriate error.
It seems that sending UDP datagrams to an unreachable destination causes the internal socket of [udpsend] or [netsend -u] to be closed. [netsend -u] even reflects that by sending '0' to its outlet. But you can tell that the socket of [udpsend] is closed, because when you fire up the listening socket again, messages sent with [udpsend] still don't reach their destination. You have to first 'disconnect' and'connect' again, before messages are actually sent. Also here, [netsend -u] is more consistent in that you have to only 'connect' (it is already in a disconnected state).
From reading a bit more about protocols, particularly about ICMP [1], I think what happens is that the receiving host sends a ICMP error packet to the sending host, telling that the destination port is unreachable.
It's important to note that merely sending 'connect' to [udpsend]/[netsend -u] doesn't trigger a ICMP error message. You have to actually send a datagram for that to happen. So the notion that UDP has no notion of a connection is still valid.
You can send data to a destination, close the socket on the destination, open it again and still send data. However, when you send data at the time the receiving socket is closed, the ICMP message is triggered.
Also, not all firewalls let such a ICMP response pass, so you might find some setups where the socket of [netsend -u] and [udpsend] is not shut down.
I don't think [netsend] has a bug in this regard. The only inconsisteny I can see with [netsend] is that you need to send actually two messages to an unreachable destination before it outputs a '0' (the first message only triggers the error: 'recv: Connection refused (111)').
[udpsend] doesn't even show an error or reports anything to its outlet, although its socket was shut down. That might be worth writing a bug report for.
Roman
[1] https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Destination_...
On Fri, 2019-01-25 at 22:44 +0100, Christof Ressi wrote:
From reading a bit more about protocols, particularly about ICMP [1], I think what happens is that the receiving host sends a ICMP error packet to the sending host, telling that the destination port is unreachable.
thanks, this might explain what happens. note, though, that this is not required behaviour for a UDP socket (and I haven't encountered this outside Pd), so I would rather make this optional (or add an option to deactivate this). The reason is that sometimes you just want to broadcast messages no matter if something is actually listening and you don't want that the sender to shut down just because the receiver is temporarily unavailable. of course you can wrap each message in a [connect( [disconnect( pair, but I think it's only an ugly workaround.
Yeah, I see how the current behavior is impractical. I'm just saying it is probably not a bug.
can tell that the socket of [udpsend] is closed, because when you fire up the listening socket again, messages sent with [udpsend] still don't reach their destination.
I can't confirm this. I just tested with a pair of [udpsend] and [udpreceive] (both iemlib and mrpeach) and I can change ports in [udpreceive] or delete/recreate it without [udpsend] closing its socket. only tested via localhost, though.
The key is that you send something between deletion and recreation. Otherwise you won't trigger an ICMP response. I tested also on localhost with a [udpreceive] and still get same behaviour I described. BTW, that's on Linux, maybe other platforms behave differently?
Roman
The key is that you send something between deletion and recreation.
I do!
BTW, that's on Linux, maybe other platforms behave differently?
Could be, I'm currently on windows but I'll check on my linux and osx machines.
Gesendet: Freitag, 25. Januar 2019 um 23:48 Uhr Von: "Roman Haefeli" reduzent@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] ugly "already connected" errors
On Fri, 2019-01-25 at 22:44 +0100, Christof Ressi wrote:
From reading a bit more about protocols, particularly about ICMP [1], I think what happens is that the receiving host sends a ICMP error packet to the sending host, telling that the destination port is unreachable.
thanks, this might explain what happens. note, though, that this is not required behaviour for a UDP socket (and I haven't encountered this outside Pd), so I would rather make this optional (or add an option to deactivate this). The reason is that sometimes you just want to broadcast messages no matter if something is actually listening and you don't want that the sender to shut down just because the receiver is temporarily unavailable. of course you can wrap each message in a [connect( [disconnect( pair, but I think it's only an ugly workaround.
Yeah, I see how the current behavior is impractical. I'm just saying it is probably not a bug.
can tell that the socket of [udpsend] is closed, because when you fire up the listening socket again, messages sent with [udpsend] still don't reach their destination.
I can't confirm this. I just tested with a pair of [udpsend] and [udpreceive] (both iemlib and mrpeach) and I can change ports in [udpreceive] or delete/recreate it without [udpsend] closing its socket. only tested via localhost, though.
The key is that you send something between deletion and recreation. Otherwise you won't trigger an ICMP response. I tested also on localhost with a [udpreceive] and still get same behaviour I described. BTW, that's on Linux, maybe other platforms behave differently?
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I can confirm that both [iemnet/udpsend] [mrpeach/udpsend] (from Pd extended) close the socket on Linux but only [mrpeach/udpsend] gives a warning and sends a 0. I'll do a bug report.
Christof
Gesendet: Samstag, 26. Januar 2019 um 00:15 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Roman Haefeli" reduzent@gmail.com Cc: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] ugly "already connected" errors
The key is that you send something between deletion and recreation.
I do!
BTW, that's on Linux, maybe other platforms behave differently?
Could be, I'm currently on windows but I'll check on my linux and osx machines.
Gesendet: Freitag, 25. Januar 2019 um 23:48 Uhr Von: "Roman Haefeli" reduzent@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] ugly "already connected" errors
On Fri, 2019-01-25 at 22:44 +0100, Christof Ressi wrote:
From reading a bit more about protocols, particularly about ICMP [1], I think what happens is that the receiving host sends a ICMP error packet to the sending host, telling that the destination port is unreachable.
thanks, this might explain what happens. note, though, that this is not required behaviour for a UDP socket (and I haven't encountered this outside Pd), so I would rather make this optional (or add an option to deactivate this). The reason is that sometimes you just want to broadcast messages no matter if something is actually listening and you don't want that the sender to shut down just because the receiver is temporarily unavailable. of course you can wrap each message in a [connect( [disconnect( pair, but I think it's only an ugly workaround.
Yeah, I see how the current behavior is impractical. I'm just saying it is probably not a bug.
can tell that the socket of [udpsend] is closed, because when you fire up the listening socket again, messages sent with [udpsend] still don't reach their destination.
I can't confirm this. I just tested with a pair of [udpsend] and [udpreceive] (both iemlib and mrpeach) and I can change ports in [udpreceive] or delete/recreate it without [udpsend] closing its socket. only tested via localhost, though.
The key is that you send something between deletion and recreation. Otherwise you won't trigger an ICMP response. I tested also on localhost with a [udpreceive] and still get same behaviour I described. BTW, that's on Linux, maybe other platforms behave differently?
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Antoine Rousseau -
Christof Ressi -
michael strohmann -
Roman Haefeli