small problem with m4l lemur and OSC

hello,

finally i learned a few bits and pieces about how to set up osc to receive from my lemur and send to m4l, so far everything works fine, except for one thing. as soon as i close the edit windw of m4l and switch to the normal view of the m4l plug in in ableton my OSC connection stops working, i can no longer edit the device from the lemur, eventhough i locked and freezed the device before saving the patch and it still doesn´t work.

does anyone have an idea how i could solve this problem?

thanks!

dbk

Try deleting and reloading the device in Live. Better yet, instead of just saving the device - "save as" to a diifferent location then load this new instance.

This *might* resolve your issue, no guarantees. The whole live editing of devices in M4L isn't quite as issue-free as the marketing would lead one to believe.

thanks but sadly it doesn´t work. as soon as i leave the presentation mode within the max4live app i loose the functionality of my template

Bummer.

This happens to me too sometimes, and I think it's a result of the environments being a bit different between the "editor" (Max) and the "runtime" (Max for Live, in Live).

It may be that what you're trying to achieve simply isn't possible within the constraints of the "runtime" - or it could be entirely solvable (with the presentation-mode symptom as a clue) . . . I'll have to demur here to more knowledgeable heads. I'm a Max newb myself, stuff like this trips me up all the time .

hey, i got it to work. after a simple restart oflive it was fixed, didn´t know that this stuff can be so flakey

thanks for thelp!

cheers,
dbk

Actually, thank you - this helps me troubleshoot something I'm working on that has a couple of similar (and more besides!) issues. Adding a simple restart of Live to the routine is something I should have tried - cannot brain sometimes.

Cannot brain at all.

Cheers!

this is usual for almost everything computer-based except military. I even have to reboot modern MIDI controllers before a session just to make them fully functional. Absolutely primitive technology, a shame actually. I don't care, I reboot devices/machines regularly to make them work, but I know this could be prevented with today's available technology. It's about sales and market, not efficiency. Sad, this is the first time in human history where development goes backwards. "De-evolution", like the band "Devo" have prophesised decades ago.

Concerning computers, we're in the stone age. Remember those words if you are young. You'll know what that meant when you're older and computers/devices will be really good and reliable.

The iConnect is an absolute b*astard for this.

Novation, take a bow.

We could go on.

Hi All

Concerning computers, we're in the stone age. Remember those words . . . regardless of age . .. .

But I think its more like the Bronze age now, computers are pretty much domesticated etc . . .
Stone Age was last century, if you were ever on BBS's at less than 2400 baud you'll know what I mean . . .
And Max 3 or less qualifies you as well I suppose . .
Cheeers
MM

hi,

i have to admit that i´m pretty unsatisfied with m4l, max and lemur. i know i´m a noob to this and the possibilities are amazing but it´s timeconsuming and enerving. i´m working with bpatchers and m4l, 5 out of 4 times, just doesn´t see them anymore and therefore all connections within the mainpatch are lost, i´m dealing with an high amount of outlets here and it sucks to have to repconnect them. aside that i have to almost everytime restart ableton to have the changes take effect.

i´m new to m4l and this might be a usererror but it´s strange nonetheles, becasue i had the impression that once you gain knowledge these things just work, anyway, it´s great to have this possibilities, i just wish it would be a tad simpler

cheers,
dbk

If you're losing inlet / outlet connections and having to reconnect them I think you're probably doing something wrong.

Try my advice to "save as" your device (patcher / .amxd) to a different directory (sidestepping any file-lock issues) and load the newly saved version. Any changes like connections should be exactly as you saved them.

Same advice applies to saving Lemur templates. Anyone who's saved their template only to find that nope . . . it didn't save . . . well, it did. But it saved to a hidden temp dir buried deep in the Windows directory structure never to be seen again. < More on this later.

Joe Soap wrote:If you're losing inlet / outlet connections and having to reconnect them I think you're probably doing something wrong.

Try my advice to "save as" your device (patcher / .amxd) to a different directory (sidestepping any file-lock issues) and load the newly saved version. Any changes like connections should be exactly as you saved them.

Same advice applies to saving Lemur templates. Anyone who's saved their template only to find that nope . . . it didn't save . . . well, it did. But it saved to a hidden temp dir buried deep in the Windows directory structure never to be seen again. < More on this later.

yes, most likely it´s a user error, will try your advice!.

cheers,
dbk

I just came across this issue with OSC and max for live. Running wndows 7, max 5, and live 8.3.

Here is a thread on the cycling '74 forum about it:

http://cycling74.com/forums/topic.php?id=36165#post-215527

Supposedly this happens because only 1 program can be connected to the udp port at a time. When the max editor is opened from inside live, the port switches from m4l to max. The problem seems it doesn't always switch back quickly once the max editor is closed and you're back in m4l.

This is pretty annoying and there doesn't seem to be a clear solution to it. I'm also surprised more people haven't run into this.

I've run into this too.

We need a smarter udpsend / udpreceive for Max generally, and more specifically the handoff between Live and Max could use some refinement.