I’m working on trying to send information to a running mrmr app on my iphone. Am using oscbonjour, from here:
trying to find the source, but the svn site is gone.
the article was writting in November 2006.
i’m wondering if this is the latest news in using bonjour in Max/Msp?
Any help or advise would be great. Thanks!
I’m pretty sure this is the source here (just found it today):
I’ve been looking into the same thing. The new update of mrmr will work with the oscbonjour object but not as tightly as the MrmrServer software. I believe this is because oscbonjour registers and reads services of type _osc._udp. However, the Mrmr client is looking for services of type _mrmrsrvr._udp. Info can be found here:
So what we need is a revamped oscbonjour object that is actually a mrmrsrvrbonjour object. I’ve just started working on this problem myself.
In the meantime, I’ve got a working patch that establishes two-way communication between a single Mrmr client (ver 1.12) and Max. I’ll attach it to this post.
looks great clavendar, I’ll start looking into this right away!
looking at the source from teh svn above, I see the constant defined:
static void oscbonjour_browse(t_oscbonjour *x, t_symbol *s, short ac, t_atom *at)
const char *type = "_osc._udp";
const char *domain = "local";
maybe it’s just a matter of changing that constant, or making it an argument to the patch?
what I want to do, is be able to push a new interface to the mrmr client, using max/msp, not the mrmr server.
hey clavender (oh, hey you!)
source line: var a = arguments.split(":"); //"a" is the arguments split between the ":" sign.
though that line looks fine to me; I can’t really see the source.
Essentially, I’m working on the same thing as you are (uploading interfaces). The patch that I’ve created allows one to upload not only interfaces but also messages to the Mrmr Client. However, right now I’ve only got it working for one client at a time so if you’re hoping to have two way communication between a central server and multiple clients (like I am) it’s not the final solution.
I’m on the same train of thought regarding the oscbonjour code adjustments. "_osc._udp" actually happens in three different places in the code. However, I’m just working on a hunch.
Essentially, Mrmr transmits OSC over UDP (port 1337) but receives data over TCP (port 31337). This means that you have to have the device IP address to be able to send info to the client. The client presents its IP address when you open a bank which is how I’m making it work.
However, the MrmrServer software doesn’t need this extra step. Which is why I’m thinking it’s an issue of registering a bonjour service of _mrmrsrvr._udp rather than _osc._udp. My hunch is that the client is listening for the former and will announces it’s IP when it see’s it. This is only a hunch though.
Also, I haven’t really had a close look at the MrmrServer code. There could be some clues on how to do a Max implementation of the server there?
yeah, I’m trying to do the same thing; upload interfaces to multiple clients.
I haven’t been successful, though, at even the single client connect.
using the oscbonjour help examples, I can make my iPhone mrmr app see that there’s a server available, which is as far as I’ve gotten.
However, using your app, which seems to be put together the same way
(passing "register" message to oscbonjour external), it doesn’t work.
though now that I’ve got yer source, I’ll be able to sy something more concrete, once I get in front of my home computer.
I’ve never written/compiled a Max/Msp external, in c++ or any other language. Have you? I’ve got no idea what kind of setup I need to do it; don’t think I’ve ever written any c++.
Got any links to good tutorials?
Your group "In C" performance really got me excited about getting started up with this again. Let’s get this working!
and btw, is this really the latest and greatest tech for communicating btw mrmr and max? oscbonjour seems kind of old to me (last update in 2006?).
To answer my own question,
here’s what looks like a great tutorial on creating max/msp externals in cpp,
for mac or windows:
Don as in "Donny" friend of Koven?
Thanks for the link. I’m fairly new to coding as well. Lately I’ve been working in Xcode and getting used to the layout. I’m auditing a class at UCI that is programming w/ the iPhone SDK (Objective C) and I’m barely hanging on. That being said, I’m pretty sure Max externals are written in straight C rather than C++. At any rate, having the code, Xcode, and some tutorials is plenty to start taking it apart and seeing how it works.
As far as your success with my app… try this:
1) Delete Mrmr from your phone
2) Redownload it from the App Store
3) Try the app again and let me know what happens
Some possible reasons it’s not working for you:
1) You’ve changed the UDP port in the client to something other than 1337
2) You’re on a network that is heavily firewalled
3) In the client preferences make sure you’ve set the Namespace to /mrmr
Try re-downloading first as that should reinitialized all of the settings like they would be for a random participant.
Let me know how it goes!
Yep, that’s me.
Thanks, I’ll try that. (reinstalling mrmr), though I’ve got all those settings as you’ve described.
Right now I’m playing with the oscbonjour.cpp source (doesn’t cpp mean it’s in c++?) from that link you sent me, trying to get it to compile.
looks like I need zeroconf, too. wonder where I can find that.
ah, got yer stuff working. made an interface load on my phone. yay!
now gotta go celebrate my birthday weekend. yay me!
so what’s your hangup in dealing with multiple mrmr clients at this point?
I think I’ve worked up something that could load multiple phones, automatically when the user hits "play" or "new"
I’m trying to use poly~, so that multiple phones can be receiving at the same time.
well, i HAD it working, and now I’m getting "address: bad number" errors when I try to send "address" messages to teh mxj object.
Any ideas what I’m doing wrong?
autoload_mrmr_network_singleclient is where I’m trying to autoload just one mrmrclient.
autoload_mrmr_network attempts to use poly for handling multiple clients
but I donn’t know where these "bad number" messages are coming from…
It seems I’ve got it working, more or less.
then in your client, connect to the found server, and hit "new" or "play"
I’ve been playing with it with two phones, and it works most of the time.
when it does fail to load, I generally have to just go back and hit "play" again in the client.
Those problems seem to happen when multiple phones hit load at exactly the same time.
So I’d think in a room of people coming in and out of the app, it would be pretty easy to say "if it doesn’t work, try again"
what do you think?
I’m not going to have time to look at this in depth this weekend (I’m swamped) but what you’ve got going is essentially where I’m at right now.
Yes, the solution is to use poly~ but the current problem is that each device’s IP is being sent to ALL the net.tcp.send objects. If you’ve connected two different devices but when you send the interface only one updates, this is the reason. Of course if you send a "Present" message (via New or Open) with the other device it will update as well right? But not the other. You’re essentially only connected to one device at a time.
What we need is a way to bind each player’s IP to a unique ID that references the net.tcp.send object in a specific instance of the poly~ patch.
OR, on the todo list is to peruse the MrmrServer code to see how it’s doing it. A mrmrbonjour object may be the ultimate solution. I’m working on getting my programming up to snuff to be able to do such a thing.
That being said you’re right… .cpp is C++. I guess I wasn’t paying attention.
sorry, I guess I don’t understand what you’re saying.
I’ve got both my phones loading a new interface, and then each is sending info to different instances of the instrument running in max. so it all "works"
what i haven’t tried, and probably wouldn’t work, is sending more information back to specific phones. ie, if I wanted to dynamically set text messages on the clients or something.
but other than that, it seems to be good.
give it a try when you get a chance, let me know what’s wrong with it.
I just checked it out and it is slick! The automatic upload is very nice. However it’s doing exactly what I was talking about. Try opening a new interface simultaneously on multiple devices. OR you can create a button that bangs the interface in all instances of poly~ so that all devices connected should update at close to the same time. In either case you’ll see that only one device will receive info. This is because ALL of the net.tcp.send objects are set to the same IP at any one time.
Every time you choose New or Play in a Mrmr client it resets all of the net.tcp.send objects to that single device’s IP address. This setup will work as long as everybody joins one at a time. So the issue is that currently we do not have in place a way to send the IP addresses to a single instance of the ploy~.
To put it another way, the .js file is generating a target command that is creating duplicate patches but each patch is collecting exactly the same IP information. Does that make sense?
I’ve attached what you previously posted with a global bang to send the interface to all devices. Check it out and you’ll see what I’m talking about.
Only the last device to log on will receive when you resend via the global bang because it’s the only IP that’s registered.
I think I get what you’re saying; that basically that "mxj net.tcp.send" object is "global"; each separate poly patch’s version of that object is technically the "same one," internally ?
for my purposes, since it only takes a few seconds to load an interface, I think this approach can still work practically speaking. After the interface is loaded, my patches are only interested in receiving information. but yeah, I don’t have two-way communication.
will look into this more soon.
The original code for oscbonjour is available from sourceforge here:
Since then I’ve refactored it, to be a more general purpose zeroconf toolkit. There is now 3 externals zeroconf.browse, zeroconf.resolve and zeroconf.register. You can browse/register iTunes services, local Ftp, etc… not just _osc._udp. It’s also more Max5 friendly with attributes
the code is available there:
sorry only XCode projects will compile at the moment.
Wow thanks Remy! I’ll definitely check them out asap. If we can register any service than "problem solved" (in theory :-)
Thank you Remy! You kicked my ass to help figure out how to compile max objects. this is VERY exciting…
any change the compiled .mxo files are posted somewhere? hoping to test this out.
I’m getting a lot of crashes with the zeroconf objects. They all look like this:
Thread 23 Crashed:
0 libSystem.B.dylib 0x901a2603 DNSServiceRefDeallocate + 241
1 org.osctools.zeroconf.resolve 0x3213c797 ZeroConf::NetServiceThread::~NetServiceThread() + 83
2 org.osctools.zeroconf.resolve 0x3213be11 ZeroConf::NetService::stop() + 59
3 org.osctools.zeroconf.resolve 0x3213c3c6 resolve_reply(_DNSServiceRef_t*, unsigned int, unsigned int, int, char const*, char const*, unsigned short, unsigned short, char const*, void*) + 180
4 libSystem.B.dylib 0x902a880e handle_resolve_response + 401
5 libSystem.B.dylib 0x901a181c DNSServiceProcessResult + 831
6 org.osctools.zeroconf.resolve 0x3213c8ed ZeroConf::NetServiceThread::run() + 295
7 org.osctools.zeroconf.resolve 0x3213c99c ZeroConf::Thread::threadEntryPoint(ZeroConf::Thread*) + 18
8 org.osctools.zeroconf.resolve 0x3213c9bb threadEntryPoint(void*) + 17
9 libSystem.B.dylib 0x9019381d _pthread_start + 345
10 libSystem.B.dylib 0x901936a2 thread_start + 34
I was wondering whether you have time to look at this
Hm… so when I press ‘Upload’ the forum automatically posts my message. :P
Anyway: I was wondering whether you have time to look at this issue. If not, maybe I should try to have a look at your code myself.
I attached the patch that I am working on (devicelist.zip). The crash occurs when I add a new osc device to the system, since I am scripting a bpatcher containing a zeroconf resolver, I assume that’s the killer.
I’m on Mac OS 10.6.4, Max 5.1.6 (43576).