Hello,
I am looking for some advice on a possible rewrite of the PureData GUI. I am
a member of a team of student developers at Virginia Tech. We are looking to
improve the usability and reliability of Pd for integration with Virginia
Tech's Linux Laptop Orchestra ("l2ork," if you like witty acronyms). The
creator and director of the orchestra, Dr. Ico Bukvic, has expressed to us
his dissatisfaction with the current TCL/TK GUI. One possible solution we
are discussing is to rewrite the GUI using either the Juce toolkit or the QT
toolkit.
It would be very helpful to us if anyone could offer any suggestions,
criticism, or comments on this project. Does anyone know of any similar
projects? What could be some possible issues/consequences?
Some basic info about the Laptop Orchestra can be found at
http://l2ork.music.vt.edu/. A goal of the project is to be as cost-efficient
as possible, so commercial software like Max/MSP is not an option. PureData
is being used as an interface for the performers and also as a compositional
tool.
Again, any input or comments would be much appreciated.
Cheers,
Paul Kohlhoff
Senior, B.S. Computer Science
Virginia Tech
Bugs item #2974702, was opened at 2010-03-22 13:28
Message generated for change (Comment added) made by mrpeach
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2974702&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Martin Peach (mrpeach)
Summary: tcpserver: couldn't create sender thread
Initial Comment:
i'm currently testing [tcpserver] under more or less heavy loads, and find it slightly unreliable.
broadcasting a lot of messages will eventually stop sending.
tcpserver will output an error like "tcpserver: couldn't create sender thread (11)" and that's it.
test scenario: 5048 bytes messages (osc stream), banged every 10ms
after 435 successfull broadcasts, things stop; pstree shows 325 open pd threads
quiting Pd will not free the port (but that might be due to the hung tcpclient )
trying the same thing again, will roughly yield the same results (448 successfull broadcasts; 382 hung threads; tcpclient hung again)
PS: this all happens on a debian squeeze/sid machine (2.6.32-3-686) with a dual core processor and 2GB of ram)
PPS: this might be a duplicate of #2905508
----------------------------------------------------------------------
>Comment By: Martin Peach (mrpeach)
Date: 2010-03-24 15:16
Message:
testpatch3.pd shows how tcpserver restarts after being blocked. On my
machine (dual P4, 2.4GHz, WinXP, Pd version 0.42.5-extended-20100324) I
can't get the metro below 120ms without blocking, but with todays' version
of [tcpserver] sending restarts properly once the [unblock( message is
sent.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-03-24 05:42
Message:
hmm, don't know what you mean with the problem shutting down tcpserver...
in this case, tcpserver spawns threads and doesn't close them anymore.
i think the problem is the consumer: if the consumer is too slow (e.g.
[tcpclient] on localhost) then the problem will appear (more reliable)
if the consumer is fast (eg. netcat on localhost), then the tcpserver
seems to work fine.
however, tcpserver should never stop working, regardless of the speed of
the consumer (i'm involved in a project with really low bandwidth; a
hanging Pd is no option there)
why can't i attach a patch at the same time as writing a comment?
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2010-03-23 12:38
Message:
I think I fixed the problem with shutting down tcpserver, tcpserver_free()
was not checking for null pointers, so some clients were not disconnected
as Pd segfaulted before they could be serviced.
I don't see anything in [tcpserver] that would result in hundreds of hung
threads. Can you post a patch that does that?
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-03-22 13:33
Message:
btw, networking is done to localhost
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2974702&group_…
Bugs item #2974702, was opened at 2010-03-22 18:28
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2974702&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Martin Peach (mrpeach)
Summary: tcpserver: couldn't create sender thread
Initial Comment:
i'm currently testing [tcpserver] under more or less heavy loads, and find it slightly unreliable.
broadcasting a lot of messages will eventually stop sending.
tcpserver will output an error like "tcpserver: couldn't create sender thread (11)" and that's it.
test scenario: 5048 bytes messages (osc stream), banged every 10ms
after 435 successfull broadcasts, things stop; pstree shows 325 open pd threads
quiting Pd will not free the port (but that might be due to the hung tcpclient )
trying the same thing again, will roughly yield the same results (448 successfull broadcasts; 382 hung threads; tcpclient hung again)
PS: this all happens on a debian squeeze/sid machine (2.6.32-3-686) with a dual core processor and 2GB of ram)
PPS: this might be a duplicate of #2905508
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-03-24 10:42
Message:
hmm, don't know what you mean with the problem shutting down tcpserver...
in this case, tcpserver spawns threads and doesn't close them anymore.
i think the problem is the consumer: if the consumer is too slow (e.g.
[tcpclient] on localhost) then the problem will appear (more reliable)
if the consumer is fast (eg. netcat on localhost), then the tcpserver
seems to work fine.
however, tcpserver should never stop working, regardless of the speed of
the consumer (i'm involved in a project with really low bandwidth; a
hanging Pd is no option there)
why can't i attach a patch at the same time as writing a comment?
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2010-03-23 17:38
Message:
I think I fixed the problem with shutting down tcpserver, tcpserver_free()
was not checking for null pointers, so some clients were not disconnected
as Pd segfaulted before they could be serviced.
I don't see anything in [tcpserver] that would result in hundreds of hung
threads. Can you post a patch that does that?
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-03-22 18:33
Message:
btw, networking is done to localhost
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2974702&group_…
Bugs item #2975654, was opened at 2010-03-24 03:54
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2975654&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
Group: None
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Feedback glitch
Initial Comment:
Can't run any PD patches without a persistent beeping glitching sound. Internal and external sound card.
Any help is appreciated.
Thanks!
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-03-24 09:39
Message:
did you try pd-vanilla? how does it work there?
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-03-24 09:39
Message:
Please provide as detailed information as possible including which
operating system (OS), CPU type, specific hardware, and the exact distro
and version of Pd itself, etc.
For example:
Pd version 0.41.4-extended
Mac OS X 10.5.7/Intel
built-in sound
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2975654&group_…
Bugs item #2975654, was opened at 2010-03-24 02:54
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2975654&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pd-extended
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: Feedback glitch
Initial Comment:
Can't run any PD patches without a persistent beeping glitching sound. Internal and external sound card.
Any help is appreciated.
Thanks!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2975654&group_…
Bugs item #2966186, was opened at 2010-03-09 10:19
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2966186&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
>Status: Closed
Resolution: Fixed
Priority: 8
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Martin Peach (mrpeach)
Summary: tcpserver: crashes when disconnecting several clients
Initial Comment:
when connecting to clients to a single tcpserver, and then disconnecting (via the "disconnectclient 1" message to tcpserver) both of them, Pd crashes
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2010-03-24 02:20
Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2010-03-09 17:37
Message:
OK, and I have also moved the client-related info into the same struct.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-03-09 10:29
Message:
for what it is worth: i have submitted the fix as rev13197 to trunk
i hope this is ok for martin
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-03-09 10:27
Message:
attached patch fixes the problem (one of the connection-specific elements
was not copied when a client was removed from the beginning of the list)
i really think that all connection-info should live in a single array of a
client-specific structure, rather than 5 different arrays...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2966186&group_…
Bugs item #2974702, was opened at 2010-03-22 13:28
Message generated for change (Comment added) made by mrpeach
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2974702&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Martin Peach (mrpeach)
Summary: tcpserver: couldn't create sender thread
Initial Comment:
i'm currently testing [tcpserver] under more or less heavy loads, and find it slightly unreliable.
broadcasting a lot of messages will eventually stop sending.
tcpserver will output an error like "tcpserver: couldn't create sender thread (11)" and that's it.
test scenario: 5048 bytes messages (osc stream), banged every 10ms
after 435 successfull broadcasts, things stop; pstree shows 325 open pd threads
quiting Pd will not free the port (but that might be due to the hung tcpclient )
trying the same thing again, will roughly yield the same results (448 successfull broadcasts; 382 hung threads; tcpclient hung again)
PS: this all happens on a debian squeeze/sid machine (2.6.32-3-686) with a dual core processor and 2GB of ram)
PPS: this might be a duplicate of #2905508
----------------------------------------------------------------------
>Comment By: Martin Peach (mrpeach)
Date: 2010-03-23 12:38
Message:
I think I fixed the problem with shutting down tcpserver, tcpserver_free()
was not checking for null pointers, so some clients were not disconnected
as Pd segfaulted before they could be serviced.
I don't see anything in [tcpserver] that would result in hundreds of hung
threads. Can you post a patch that does that?
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-03-22 13:33
Message:
btw, networking is done to localhost
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2974702&group_…
Bugs item #2905508, was opened at 2009-11-29 00:20
Message generated for change (Settings changed) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 20:09
Message:
Hi Martin
Thanks a lot for providing a fix so quickly.
Things looks very good. I was putting the tcpserver based netpd-server
under the heaviest load i can get, which is limited by the bandwidth of my
home internet connection. While constantly sending messages with ~50 kB/s
bandwidth up to the server and ~350kB/s receiving from it, all messages
come through intact. It is stable also when connecting and disconnecting a
lot of clients at the same time, while constantly broadcasting messages.
The cpu usage is *much* lower than with the select() based tcpserver; with
the bandwidth load mentioned above, it is about 12%, whereas it reached
100% with much less load before.
Thanks again for all your work spent on this issue.
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 17:50
Message:
oops, thought I was logged in...anyhow I'll try it on a linux box tomorrow.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-11-29 17:47
Message:
It was probably the handles that reached a limit, the threads disappear
after the data has been sent but their handles were not being cleaned up.
Now the threads are created in the detached state so their handles are
freed on exit. On WinXP the handles and threads are fairly constant now.
I'll leave the patch running to see if it ever hangs, but t seems to be
working OK here.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 14:18
Message:
Actually, i couldn't figure out, why it stops working after 380 messages.
I'd like to know, whether it hit some max number of threads limit. I also
couldn't figure out how to display the number of threads being started by a
certain process.I found /proc/sys/kernel/threads-max, which is set to 32491
on my system. However, changing the value doesn't effect the behaviour of
the test-patch.
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 06:03
Message:
The threads are supposed to terminate themselves after they have sent their
buffer. I don't see a need to use threads apart from sending messages. The
rest of [tcpserver] works just fine in one thread.
Here on WinXP the patch is still running at 66000+.
The system is adding handles at about twice the rate as the threads are
being created, but the amount of available memory is not decreasing and the
number of threads is staying about the same.
I'm not sure if that's a bug.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 00:30
Message:
Hm.. from the svn log of revision 12760: "Using pthreads to send each
message to each client in its own thread." That probably explains, why it
stops working after sending X times 'broadcast 97 59 10' to [tcpserver]. Do
i understand right, that literally each pd message opens its own <number of
clients> threads? Wouldn't it be sufficient to have one thread per socket?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Bugs item #2974702, was opened at 2010-03-22 18:28
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2974702&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Martin Peach (mrpeach)
Summary: tcpserver: couldn't create sender thread
Initial Comment:
i'm currently testing [tcpserver] under more or less heavy loads, and find it slightly unreliable.
broadcasting a lot of messages will eventually stop sending.
tcpserver will output an error like "tcpserver: couldn't create sender thread (11)" and that's it.
test scenario: 5048 bytes messages (osc stream), banged every 10ms
after 435 successfull broadcasts, things stop; pstree shows 325 open pd threads
quiting Pd will not free the port (but that might be due to the hung tcpclient )
trying the same thing again, will roughly yield the same results (448 successfull broadcasts; 382 hung threads; tcpclient hung again)
PS: this all happens on a debian squeeze/sid machine (2.6.32-3-686) with a dual core processor and 2GB of ram)
PPS: this might be a duplicate of #2905508
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-03-22 18:33
Message:
btw, networking is done to localhost
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2974702&group_…
Bugs item #2974702, was opened at 2010-03-22 18:28
Message generated for change (Tracker Item Submitted) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2974702&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Martin Peach (mrpeach)
Summary: tcpserver: couldn't create sender thread
Initial Comment:
i'm currently testing [tcpserver] under more or less heavy loads, and find it slightly unreliable.
broadcasting a lot of messages will eventually stop sending.
tcpserver will output an error like "tcpserver: couldn't create sender thread (11)" and that's it.
test scenario: 5048 bytes messages (osc stream), banged every 10ms
after 435 successfull broadcasts, things stop; pstree shows 325 open pd threads
quiting Pd will not free the port (but that might be due to the hung tcpclient )
trying the same thing again, will roughly yield the same results (448 successfull broadcasts; 382 hung threads; tcpclient hung again)
PS: this all happens on a debian squeeze/sid machine (2.6.32-3-686) with a dual core processor and 2GB of ram)
PPS: this might be a duplicate of #2905508
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2974702&group_…