jit.net.* woes.
Hello list,
I've been working on a multiple location installation that requires the use of multiple jit.net.send/recv objects in each patch. Basically, Patch A sends Jitter matrices to Patch B. Patch B then responds by sending audio back to Patch A. This should be possible according to the tutorials as long as I supply unique ports for each data stream. Here's the problem: Once I get one pair of jit.net.send/recv objects talking to one another (i.e. both return a "connected 1" message) I cannot get the other pair to bind to the appropriate ports. I keep getting a "binding method unsuccessful" and something like "port is probably in use" messages in the max window. The thing is, no matter what values I change the ports to, this message persists. So, it seems, I can send audio in one direction or video in the other, but not both at the same time.
Has anybody encountered this? Alternatively, has anybody made a working video-conferencing patch that would have had to overcome this problem? Please help!
All my best,
i used max for "low-tech video-conferencing", but with quite strange
workarounds... the advantage is that this would work not only on a
LAN but also through the internet.
for audio (patch B), i did for example send the audio as mp3 stream,
with olaf matthes' shoutcast object, to a local icecast server (if
connected to the net, you could also create a channel on giss.tv
which would get you running in a few minutes). the receiving computer
can then listen to it with VLC (unfortunately to my knowledge there's
no object to route an mp3 stream directly into max, so you'd need to
use soundflower or Jack...)
for the image, the following could be a "primitive" solution: your
video sender (patch A) repeatedly exports the video as a JPG, which
is made accessible through the osx apache server. in patch B, the mxj
jitwebimage reads this JPG file as fast as it can...
you could of course combine this with jit.net.*, either for video or audio.
>Hello list,
>
>I've been working on a multiple location installation that requires
>the use of multiple jit.net.send/recv objects in each patch.
>Basically, Patch A sends Jitter matrices to Patch B. Patch B then
>responds by sending audio back to Patch A. This should be possible
>according to the tutorials as long as I supply unique ports for each
>data stream. Here's the problem: Once I get one pair of
>jit.net.send/recv objects talking to one another (i.e. both return a
>"connected 1" message) I cannot get the other pair to bind to the
>appropriate ports. I keep getting a "binding method unsuccessful"
>and something like "port is probably in use" messages in the max
>window. The thing is, no matter what values I change the ports to,
>this message persists. So, it seems, I can send audio in one
>direction or video in the other, but not both at the same time.
>
>Has anybody encountered this? Alternatively, has anybody made a
>working video-conferencing patch that would have had to overcome
>this problem? Please help!
>
>All my best,
>--
>Jeremy Wagner
>----UofM----
>Minneapolis, MN
Thanks for the response...
That would work well for the audio stream. But I forgot to mention that I am also utilizing the data inlet on the jit.net.send/recv objects in conjunction with the matrix inlet to communicate settings that must arrive in sync with the audio and video streams--although this could be accomplished easily enough with the mxj net.tcp.* objects in your scenario the syncronization of the streamed webcast with the max control data would be problematic.
Is there any more detailed documentation on these objects other than that found in the tutorials and html references? I find all of those sources somewhat lacking.
u can view their source using the "viewsource" command. even if your not a
java programmer those functions are understandable. basically the net.tcp is
a wrapper for java's built in net.tcp package. which is extensively
documented on the web.
On 8/29/07, Jeremy Wagner wrote:
>
>
> Thanks for the response...
>
> That would work well for the audio stream. But I forgot to mention that I
> am also utilizing the data inlet on the jit.net.send/recv objects in
> conjunction with the matrix inlet to communicate settings that must arrive
> in sync with the audio and video streams--although this could be
> accomplished easily enough with the mxj net.tcp.* objects in your scenario
> the syncronization of the streamed webcast with the max control data would
> be problematic.
>
> Is there any more detailed documentation on these objects other than that
> found in the tutorials and html references? I find all of those sources
> somewhat lacking.
>
>
> --
> Jeremy Wagner
> ----UofM----
> Minneapolis, MN
>
***UPDATE***
I ran a series of test patches between computers with similar results; that is, whenever two or more instances of jit.net.send and recv are present in a patch only the first to be passed an ip address and port will successfully connect. After beating my head against the wall for hours I tried triggering an int into the message inlet of jit.net.send with each change of the port and ip settings and **shazam** jit.net.send and its corresponding recv object both reported "connected 1". Success!
Is it possible that the operation of the rest of the patch was superceding the reporting of the connected status? Its as if the object were asleep and only after receiving a "priority" message does it bother to wake up. (Much like myself)
Thanks to all of you who have written with your suggestions. You've been a tremendous help.
Jeremy, disregard my comments. there are misleading at best ;)
On 8/29/07, Jeremy Wagner wrote:
>
>
> ***UPDATE***
>
> I ran a series of test patches between computers with similar results;
> that is, whenever two or more instances of jit.net.send and recv are
> present in a patch only the first to be passed an ip address and port will
> successfully connect. After beating my head against the wall for hours I
> tried triggering an int into the message inlet of jit.net.send with each
> change of the port and ip settings and **shazam** jit.net.send and its
> corresponding recv object both reported "connected 1". Success!
>
> Is it possible that the operation of the rest of the patch was superceding
> the reporting of the connected status? Its as if the object were asleep and
> only after receiving a "priority" message does it bother to wake up. (Much
> like myself)
>
> Thanks to all of you who have written with your suggestions. You've been
> a tremendous help.
> --
> Jeremy Wagner
> ----UofM----
> Minneapolis, MN
>