we've never had any trouble running two different chucks under 10.5, and that error is common, but doesn't seem to affect things. in 10.6, it either doesn't run at all, or very badly... i don't have 10.6 here, so i'm mostly responding to feedback i'm getting from others... dt On Jan 6, 2010, at 3:28 PM, Hans Aberg wrote:

On 6 Jan 2010, at 21:17, dan trueman wrote:

...

hey any OSX 10.6 users out there?

it seems that it's impossible to run two chucks in separate Terminal windows under 10.6. can anyone confirm or refute this?

What happens? On 10.5, I get [chuck]: cannot bind to tcp port 8888... but the program is still running. The first chuck grabs the port 8888, so the next one can't use it.

Hans

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

it's not a port problem; setting the port differently doesn't help. and chuck --probe doesn't really indicate anything of interest that we can tell. just seems that two chucks aren't happy running at the same time in 10.6... dt p.s. manual looks great!! On Jan 6, 2010, at 4:03 PM, Kassen wrote:

2010/1/6 dan trueman we've never had any trouble running two different chucks under 10.5, and that error is common, but doesn't seem to affect things. in 10.6, it either doesn't run at all, or very badly...

Might this be a combination of a undocumented change to CoreAudio, combined with our RTAudio being out of date? Does a "chuck --probe" after starting the first session yield anything that might explain the situation? I seem to remember reading something about changes to CoreAudio.

If it's the port then that can -of course- be changed with a command line flag. This may be a good moment to announce that I think I found and compiled all of those flags on a single page; http://en.flossmanuals.net/bin/view/ChucK/OnTheFlyCommands I'm quite happy with that as they were scattered all over the place.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

2010/1/7 Brad Garton

Jeez this is weird. I don't think it's an "older code" issue -- I can run two independent CMIX processes with no problems, and our code is downright *ancient*. I don't understand how two independent processes from two independent shells can interfere.

Well, clearly they aren't independent then. We know for sure that they are trying to claim the same port at localhost and we also know they are both trying to connect to the audio system. I just tried and I get the same on Linux (though for me the dac being taken on Alsa is also a issue). Even with --silent the second instance fails to start claiming about a port issue. Starting the second with "--port7777" works, aside from the main dac being taken. This is with both instances being 1.2.1.3 can that behaviour be replicated on OSX? Yours, Kas.

2010/1/7 Brad Garton

The ports are probably for control info like OSC or audicle or something, I imagine.

I think the main usage is for the otf commands, which do need to run between instances of your shell (most likely Bash), and use ports at localhost for that

Tried the --port7777, no go on OSX.

I picked that at random. You could try a few others or check your firewall settings.

They both have different pids (and I even tried renaming the executable just for the heck of it in one try).

I don't think two things can have the same pid at all, actually, but the renaming was a good thing to test.

Something's going on in CoreAudio...

May well be, yes, but I suspect it's significant that I got the same error with the same symptoms on Linux. Quite weird. Are people using this to make the most of multi-core CPU's? Yours, Kas.

On Jan 7, 2010, at 7:18 PM, Tom Lieber wrote:

On Wed, Jan 6, 2010 at 4:36 PM, Brad Garton wrote:

...

Jeez this is weird. I don't think it's an "older code" issue -- I can run two independent CMIX processes with no problems, and our code is downright *ancient*. I don't understand how two independent processes from two independent shells can interfere.

Does it use RtAudio? (An RtAudio as ancient as ChucK's?)

The language certainly predates that, but I do have to admit that Doug Scott and John Gibson have done a good job of keeping the audio drivers updated for various OSes. brad http://music.columbia.edu/~brad

I just did a project where I ran two instances of Chuck each listening to different sound cards, since Chuck (or RTaudio) has problems with aggregate devices for some reason. I just used the --port flag to separate one of them, and didn't get the complaint. The complaint, of course, won't ever bother you unless you're doing chuck + myfile.ck in another window. to choose a specific chuck instance to send code to, you'll need to specify the port as well: chuck --port8686 + myfile.ck like that. then, you're sending myfile.ck to the Chuck instance listening on port 8686 and not the one listening to the default port (8888). I was doing this on Snow Leopard... that's 10.6, right? is it the case that you're not even able to get the other instance to run? -Mike On Fri, Jan 8, 2010 at 1:05 PM, Tom Lieber wrote:

2010/1/6 Kassen :

...

Might this be a combination of a undocumented change to CoreAudio, combined with our RTAudio being out of date?

I just tested an app that uses the latest RtAudio, and when it's launched twice they share the sound card. So either ChucK uses RtAudio differently, or it's the version difference.

-- Tom Lieber http://AllTom.com/ http://ckvlang.org/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org