hanging server client & mA?
Clixserver has been so temperamental. It often happens when new clients are added, that a couple of people will have their CliX get hung up in between "mouse ready" and "keyboard ready". (Everyone else will be fine and clicking away.) I can't identify an obvious reason (e.g., they are listening on the wrong port number). It seems more likely to happen if mini-Audicle is on or was used recently. Is that plausible? (Obviously we're not running CliX in mA, since KBHit doesn't work there.) thanks in advance, david David Loberg Code School of Music Western Michigan University Kalamazoo, MI 49008 code@wmich.edu
David; Clixserver has been so temperamental.
I'd like to help you, or at least reproduce the issue but I have no idea at all what you mean here. I Googled "Clixserver" and mostly got results about online advertising. That's probably not what you meant :-). Let's take a step back. If you could describe what you are trying to accomplish on what sort setup and how you are going about this? I'm getting the feeling a network is involved and that you are getting issues with something that formerly worked? Yours, Kas.
Kas,
It's in the Smelt pack, under smelt-1.0/pieces/CliX
-Andrew
2009/10/31 Kassen
David;
Clixserver has been so temperamental.
I'd like to help you, or at least reproduce the issue but I have no idea at all what you mean here. I Googled "Clixserver" and mostly got results about online advertising. That's probably not what you meant :-).
Let's take a step back. If you could describe what you are trying to accomplish on what sort setup and how you are going about this? I'm getting the feeling a network is involved and that you are getting issues with something that formerly worked?
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
David,
Looks like all there is in between is the port stuff, but I'd suggest
doing some caveman debugging on your machines and see if you can
recreate it. (Defining "caveman debugging") Just throw in <<< "Made it
to 1" >>>; <<< "Made it to 2" >>>; etc., statements after every line
and see what the problem line is.
The only two things would be if listen() is screwing up or if your
event clock never arrives. One possibility could be that your server
isn't transmitting to the new computers. I'm only suggesting this
because it seems like you've been looking in the player computers, not
the server-multi computer. So, you'd just have to add an extra line to
the xmit[i].setHost ("....", port); part of the server-multi.ck. Just
taking a stab, though--try out the OSC test app here:
http://code.google.com/p/vvopensource/downloads/list and see if
anything's coming through. Good luck.
Andrew
On Sat, Oct 31, 2009 at 11:55 AM, Andrew C. Smith
Kas,
It's in the Smelt pack, under smelt-1.0/pieces/CliX
-Andrew
2009/10/31 Kassen
: David;
Clixserver has been so temperamental.
I'd like to help you, or at least reproduce the issue but I have no idea at all what you mean here. I Googled "Clixserver" and mostly got results about online advertising. That's probably not what you meant :-).
Let's take a step back. If you could describe what you are trying to accomplish on what sort setup and how you are going about this? I'm getting the feeling a network is involved and that you are getting issues with something that formerly worked?
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
if mA has been running (or anything else that might be using OSC) and using similar port #s, things will get hung. definitely make sure all other OSC things are quit on those machines; sometimes they aren't so good about releasing ports. also, make sure that the System Preferences:Security:Firewall settings are set to "Allow all incoming connections," which shouldn't be a security issue if you are running a LAN, and probably not much to worry about regardless (mine are all always set that way). dt On Oct 31, 2009, at 11:03 AM, David Loberg Code wrote:
Clixserver has been so temperamental. It often happens when new clients are added, that a couple of people will have their CliX get hung up in between "mouse ready" and "keyboard ready". (Everyone else will be fine and clicking away.) I can't identify an obvious reason (e.g., they are listening on the wrong port number). It seems more likely to happen if mini-Audicle is on or was used recently. Is that plausible? (Obviously we're not running CliX in mA, since KBHit doesn't work there.)
thanks in advance,
david
David Loberg Code School of Music Western Michigan University Kalamazoo, MI 49008 code@wmich.edu
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Dan; "Allow all incoming connections," which shouldn't be a security issue if you
are running a LAN, and probably not much to worry about regardless (mine are all always set that way).
I really wouldn't do that on a open network. Of course the chances of you personally being targeted by something malicious are quite low but the consequences could be devastating, think not just of what could be downloaded (creditcard numbers, etc) but also of the kind of thing that could be planted on your computer. A thing like that could easily devastate your life, even if you could demonstrate you were unaware of it. I'd instead white-list all relevant peers like -say- all of plork. That should significantly reduce the risks while preserving most of the convenience. Back on topic; David, these stuck computers, does Chuck take excessive amounts of cpu on them while they are stuck? If relatively little cpu is used it's probably stuck waiting for some event, if a lot is used it'll be something else. Yours, Kas.
PLOrk virtually always works on a closed LAN, not connected to the outside world. dt On Oct 31, 2009, at 1:22 PM, Kassen wrote:
Dan;
"Allow all incoming connections," which shouldn't be a security issue if you are running a LAN, and probably not much to worry about regardless (mine are all always set that way).
I really wouldn't do that on a open network. Of course the chances of you personally being targeted by something malicious are quite low but the consequences could be devastating, think not just of what could be downloaded (creditcard numbers, etc) but also of the kind of thing that could be planted on your computer. A thing like that could easily devastate your life, even if you could demonstrate you were unaware of it. I'd instead white-list all relevant peers like -say- all of plork. That should significantly reduce the risks while preserving most of the convenience.
Back on topic; David, these stuck computers, does Chuck take excessive amounts of cpu on them while they are stuck? If relatively little cpu is used it's probably stuck waiting for some event, if a lot is used it'll be something else.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
sorry, just reread your email, and your reference to open networks... yes you are probably right. On Oct 31, 2009, at 1:24 PM, Daniel Trueman wrote:
PLOrk virtually always works on a closed LAN, not connected to the outside world.
dt
On Oct 31, 2009, at 1:22 PM, Kassen wrote:
Dan;
"Allow all incoming connections," which shouldn't be a security issue if you are running a LAN, and probably not much to worry about regardless (mine are all always set that way).
I really wouldn't do that on a open network. Of course the chances of you personally being targeted by something malicious are quite low but the consequences could be devastating, think not just of what could be downloaded (creditcard numbers, etc) but also of the kind of thing that could be planted on your computer. A thing like that could easily devastate your life, even if you could demonstrate you were unaware of it. I'd instead white-list all relevant peers like -say- all of plork. That should significantly reduce the risks while preserving most of the convenience.
Back on topic; David, these stuck computers, does Chuck take excessive amounts of cpu on them while they are stuck? If relatively little cpu is used it's probably stuck waiting for some event, if a lot is used it'll be something else.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
2009/10/31 Daniel Trueman
sorry, just reread your email, and your reference to open networks... yes you are probably right.
Yes. On closed networks it probably doesn't matter unless you are really paranoid and concerned with stuff like passive wireless packet sniffers. I don't think that's a real issue for experimental music performance :-). On the open internet a bit of security just makes sense; you'd zip up your bag and probably button up your back-pocket before entering a crowd as well. We are trading convenience for safety (and vise-versa) and should strive for a trade that makes sense in our context. Opening everything makes perfect sense on closed Lans, not so much -to me- out in the open. Just some well-intended advice. Kas.
participants (4)
-
Andrew C. Smith
-
Daniel Trueman
-
David Loberg Code
-
Kassen