Frustrating Max 4 Live Bug since installing SerialOSC - Video to show - Help Needed! Raja, Dove?

  • Hello,

    Having a horrible couple of days trying to write some new code for my M4L Control project. Seem to have created, or run into an incredibly frustrating bug that I've been stuck with for the last few days. I've deleted and reinstalled both Ableton and Max and I've gone through the patch, debugged and deleted any extra stuff to test it, just doesn't seem to work.

    I've made a video to demonstrate the bug as it's quite hard to explain without seeing it. For the first day and few hours of debugging I thought I'd just made a mistake somewhere but I've stripped it down to the most basic functionality I can and it's still not working.

    Some background, I've had my M4L Control Project working and in a continual state of development for about 9 months now. I've had a Clip Launcher working for over 6 months, used it for numerous gigs and never had a problem.

    A few days ago I finally delved into SerialOSC, wrote a little abstraction based on tehn's and got it working perfectly. (Having loads of fun with SerialOSC, great options for app discovery etc, definitely the way forward). The next day I actually tested the abstraction out with M4L Control and at first it looked like everything was working fine. I tried out all of the other apps ie Clip Chopper, Mixer, Device Control and they all work perfectly. Button presses all working perfectly etc.

    Then I tried out the Clip Launcher app. When I try to launch a Clip the first press does nothing, the second press does launch a clip, but the one that was pressed previously. the next press launches the clip i pressed previously, etc.

    It's like it's getting delayed somewhere, storing the clip id if that was pressed previously and banging it through on the next press.. but it's not.

    Here's where it gets weirder. In the video you'll see I hooked up a matrixctrl object to act as a virtual monome. I put it at the one point of entry for monome presses and I've routed the monome presses through it. When I press on the matrixctrl with the mouse it launches the right clip straight away but as soon as I press with the monome, which lights up the right button on the matrixctrl it launches the wrong clip.

    Hard to explain but check the video and see if you can spot what's wrong. I've been working on it for soo long now my brain is starting to fry. I'm hoping it's a really small mistake on my part, but it's got the stage where I just don't think it is. Either SerialOSC is doing something weird to my button presses (printing the output shows it isn't) or I've somehow broke Max 4 Live in a way that a clean reinstall won't fix.

    Any help would be much appreciated!

  • EDIT: actually, could you just post the relevant patches?

    Also, try moving the print to behind the mtrxctrl

  • Sorry, in such a rush to put it up I forgot to include the patch!

    Here's a frozen cut down copy of the device. Deleted all the applications just to check they weren't interfering. Also deleted the main Monome Handling patch and just included the basic serialOSC abstraction.

    Drop the device on a midi track.
    Click the second button down which should open a floating window. There you will see the serialOSC abstraction. Select the monome, click connect and check the presses are coming through to the matrixctrl. Then go back to the main device gui in ableton and click the Get button right at the top, then the Set button (the third one down).

    Now if you click in the matrixctrl, or click keys 1 - 9 on your laptop keyboard it will launch clips perfectly fine. If you now try clicking some buttons on your monome it will launch clips wrong in the manner I described above.

    Or at least it should do. If it works fine for you at least I know it's something wrong with my laptop.

    I've also included a previous revision which works perfectly with an old Monome Serial type of monome connection.

  • have you tried backtracking to monomeserial?

  • Magic. (which is to say, i deferlow is magic.) I don't know how serialosc factors into this, but i think you were/are firing before the object is done going to the new id. which is why it would happen 1 late.

  • Ah! Griot, thank you so much! I owe you a one.

    Was wondering if it was something to do with message priority or thread (is that the correct term?). It's an area of programming I don't really know much about, or fully understand. I checked the order the messages were sending with a trigger object and the max window, but I guess it was just sending the message to quickly for max and ableton?

    Odd that this happened after putting in the serialosc abstraction. I wonder how the messages in that came into a higher priority thread than when I was using monome serial? Because it is nestled within another subpatch maybe?

    I've put the patch back together with the proper MonomeHandling/Routing patch and the proper Live Clip Launching application, all works perfectly now. Going to try adding the other applications back in after some sleep and hope deferring the monome presses doesn't have an adverse effect on any of the other applications, they were previously unaffected.

    Am I right in thinking using a deferlow has no noticeable effect on performance or latency on button presses? It's such a tiny difference as to be unnoticeable to humans?

    @ tehn
    i thought the problem was with my programming not serialosc, as it turned out to be. sorry for worrying.
    having a great time with serialosc otherwise, very well designed. going to be delving into some app discovery and a router application soon.
    i've been keeping up with the visual basic thread and it looks like cassiel's got the zeroconf externals on the way for windows, so I'll work with those.
    heard some bad things about oscbonjour when i was using it with autoconfig in the live clip chopper device. the device with it in was causing crashes for some people, the oscbonjour external was flagged up by ableton staff as a possible culprit.

  • It is threading but honestly, i don't know exactly how deferlow does what it does. It really is magical. I think that there may be some noticeable jitter/delay when things get hectic if it really does push it off of the high priority thread.