Struggling with udpreceive and Max for Live
I've been developing a plugin that utilizes [udpreceive] for receiving OSC data from a hardware device, and I wish the OSC support in Max was more robust. The general problem is that both Max and Ableton cannot receive OSC data at the same time, and usually you have to quit Max in order to get the OSC to work back in Ableton. But it is often the case that Ableton will not pass off the OSC to Max. When this happens, I've noticed that sometime even when you quit Max, the data won't even go back to Ableton until you quit everything and restart. I would like to see a far more robust OSC system where multiple instances of [udpreceive] can work in tandem across Ableton and Max. With this degree of bugginess it is very difficult to work.
Yes it’s a big hassle.
There is nothing wrong with udp reception in Max.
Only in integration of Max in Live.
In case max4live device was opened in Max used as max4Live editor,
and then you want independent Max version which should listen to same udp port ...
resend port message to reactivate udp receive object in Max.
max4live device opened for editing is never going to
behave same way as when it is just loaded in Live.
made a patch using udp send and receive all works fine even with multiple devices inside the ableton session.
Yes the problem is with editing a max for live device. It does seem to work smoothly once the device is produced and edited, but during the process of switching back and forth between Live and Max, this is a major problem that many people working with this object experience.
If the problem lies squarely with Ableton, what exactly is the disconnect that is preventing it from working correctly. Does Ableton need to fix this bug?
A workaround I use is to have a button on the interface that changes the port of the udpreceive object. Press the button to change ports before clicking the 'edit' button, then switch back once it's open in Max. Clunky, but it works
I do the same as Ben, and it works well. Worth coding up to save your sanity!
Thanks guys. At least there’s a workaround to try. I’ll give that a shot.
The ’universal’ object can help if you have lots of udpreceive scattered around your patch
Do you guys know if there is a way to bang before it switches to edit mode, like an [editbang]? I tried closebang and freebang and those don't seem to work.
that is a funny idea and could be quite useful.
I guess you can use the right-most outlet on [live.thisdevice]. It seems to work.
Unfortunately, it seems that this solution of changing ports to resolve the binding issue no longer works with the latest version of Max and the latest version of Live 10 (not sure about Live 11). Any other solutions? Really it’s time they resolve this so we don’t have to use a work around!
I entirely sympathise with your experience. It's been a persistent nightmare with MusicTribe (Behringer/Midas) kit, which uses the same port for both send and receive. [udpreceive] simply does not play ball with any other software using the identical port numbers like this, at least, not in Windows. I've got around it by using the Sadam library but I don't know whether that's available to M4L users.
Here's the solution that I came up with:
It might look like a sledgehammer to crack a nut but it totally fixes all my problems.
There are basically two identical handlers on the left that control my OSC interface to two separate mixers (X-32 and XR-18) that use ports 10023 and 10024 by default. [sadam.udpclient] can be set to send and receive on the same port without any problems. The problem with [sadam.udpreceiver] and [sadam.udpsender] is that they only handle raw OSC data bundles and I have yet to find a suitable encoder/decoder. However, if I then connect them to [updsend] and [udpreceive] respectively via the "localhost" loopback address (127.0.0.1), the [updsend] and [udpreceive] objects conveniently provide the encoding and decoding routines.
To ensure that the [updsend] and [udpreceive] objects work, they are assigned randomised port numbers in a rarely used block (15000 to 20000), managed by the initialisation routine top centre. Incidentally, I used the [qmetro] - [counter] - [route] method here to ensure that all the port assignments happened at evenly spaced intervals in the correct order to make sure that everything happens smoothly. Using an [Uzi], [bang] or [trigger] for this regulary caused the port assignments to fail, probably because either Max or Windows couldn't hack it that fast!
So, the left hand routines handle the actual data flow (input and output is both using standard OSC alphanumeric address and data strings), the middle chunk does the port assignments and the right hand block checks that it's all working for the rest of my (much larger) application. I also have an [OSCDebug] module (bottom centre) that can display the incoming and outgoing messages as well as sending test messages if needed.
If you can make use of the idea, then be my guest!
Trying to distill what you have accomplished in make it work. I think what makes it work is the delay in initializing the new udpreceive so that the old one gets a chance to unbind first. Is that correct? I think I got it working in this simple little patchwork. When switching a Max for Live device between edit mode and Live mode, this seems to allow the data stream to pass from one to the other. At least it works at the very moment!
A delay might be one way to fix it but the method I use continues to work after a single initialisation. I’ve simply found that [udpreceive] is not robust enough for anything more than really simple use, especially when using it in a Windows environment.