max4live+midi controller/keystroke problem. bug?

    Jan 17 2011 | 11:12 am
    Hi everybody,
    I made a little looper in max4live that works fine as long as I don't use a midi controller or keystroke within Ableton itself to control it. I really don't get it. If I click on the looper's record button with my mouse everything works fine. If I assign a midi controller (korg nano kontrol or behringer fcb1010) to the same button, the button lights up and the looper starts recording. If I view the buffer I can also see that it is recording. But: If I hit the button again to end recording, it erases the buffer! If I use the controller to start recording and click with the mouse to stop it also works fine. If I just assign a keystroke in Ableton to the button I have exactly the same problem.
    I thought it shouldn't make any difference if I click a button or use a midi control or key assigned within Ableton itself? I have a gig coming thursday and would love to use the patch there. Any help greatly appreciated! I'm pretty new to max so sorry if it looks messy. Here's my patch:
    Thanks!! Christoph

    • Jan 17 2011 | 2:45 pm
      The behringer 1010 crash a lot with max and Ableton....I'm at work and can't check your patch... But use the foot pedal carefully.....
    • Jan 17 2011 | 10:30 pm
      Thanks! Maybe I wasn't precise enough in my first post but the behringer doesn't seem to be the problem. I have the same strange thing when using my korg nanokontrol. Even if I'm not using external gear at all but simply assign a key from my laptop keyboard to the button in Ableton (using the standard cmd-k method) the problem doesn't change.
      If I'm "pushing" a button in my patch using a midi controller or just a simple key on my computer my patch doesn't work. If I use my mouse instead to click the button everything is fine. I can see the button going on and off in all three cases named above. I also restarted my computer about a hundred times but nothing seemed to change.
    • Jan 19 2011 | 12:55 am
      no solution - sorry! - but a similar problem: i wanted to use the prgmchng output provided by x-15 ultrafoot to control recording clipslots while muting the track during recording. the patch works fine using the GUI but works erratic using midi input. what bothers me most is the impossibility to debug this.... what could be difference in "quality" of an integer produced via midi or by the GUI ???
    • Jan 19 2011 | 9:14 pm
      Yes, this is really frustrating. Funny thing is that I don't even have to involve midi and external gear, even assigning a key right on my laptop causes the same problems.
    • Jan 20 2011 | 12:53 am
      tried your patch: it also erases the buffer when when controlled via an assigned key. only if you use the "key"-object in the m4l patch and assign a key thru "select" to the "record" button it works, but for that the patch has to be in focus which renders it unsuable....
      geeiltes leid ist halbes leid - as we say in german...but is still sucks big time. how could we debug this?
    • Jan 20 2011 | 12:39 pm
      I think the problem is that Live's midi/key mapping only supports toggle mode. So it doesn't work for buttons which would require trigger mode. You may find some related discussions on this forum.
    • Jan 20 2011 | 1:41 pm
      A controller usually sends two values, 1 or 127 for down, 0 for up. You can get only the down as a bang with a select object... (which is turning a toggle into a trigger, its easy to program these modes...) To analyze these kind of problems, its good to attach a print object and watch the printed output in the Max window...
      hope this helps...
    • Jan 20 2011 | 2:45 pm
      I wonder if turning toggle into trigger would also be possible for key assignments..
    • Jan 20 2011 | 2:55 pm
      Of course, have a look a stripnote...
    • Jan 20 2011 | 3:14 pm
      Sorry, I meant keys from computer keyboard, so called key mapping in Live.
    • Jan 20 2011 | 6:46 pm
      To answer my own question, here is a simple workaround using a dummy button in toggle mode for key mapping that triggers a momentary button.
    • Jan 21 2011 | 5:19 pm
      Thanks! I'll try this later but looks like it's going to work. This Max community is so cool :)
    • Jan 21 2011 | 7:15 pm
      Now that I wanted to try it I realize that I actually don't need something with a trigger function. Toggle is right what I need I think: Record on / Record off. Or not? I don't get it, can someone explain?
    • Jan 25 2011 | 7:19 pm
      Yes, for switching between 2 states on/off you need a toggle, not a trigger.
      The toggle button sends 1 and 0. This should happen regardless of clicking or midi/key mapping. To investigate the issue you may check the actual output with print or a message box.
    • Jan 27 2011 | 12:50 pm
      I already checked the output of my toggle button with print. It is 1 and 0 when I click the button AND 1 and 0 if I use a midi controller. So in both situations the button seems to send the same data. Only when using midi instead of my computer mouse it erases the buffer and there is no recording. Same with keymapping. Weird...
    • Jan 27 2011 | 2:22 pm
      In the meantime I've tried running your patch and noticed the inconsistent behavior exactly as described. I can only imagine that it's caused by timing issues, ie. subtle variations in timing depending on how the button is activated. This may affect the execution order, in particular when operations are involved that are executed on the low-priority GUI thread.
      So the goal would be to make the patch "immune" to such variations, ie. finding the critical points (for example with time measurement using [cputime]) and possibly inserting some [delay] or [pipe] objects. No doubt it's a tricky issue.
      Btw, I've noticed that the record button is connected to the left inlet of the waveform~ objects. This way you are setting start time to 1 resp. 0 ms. Is this really intended?
    • Jan 28 2011 | 10:31 am
      Thanks, I'm going to try this! Also thanks for the hint concerning the start time, didn't think about that before.
    • Jan 28 2011 | 4:37 pm
      For investigating the issue it would be helpful to clean up the layout first. A well structured patch may motivate other people (myself included) to have a closer look..
      PS. Remember that you can use send/receive to replace confusing patch cords.
    • Jan 29 2011 | 3:15 pm
      Good news! After some general tests with button mapping it seems that I've found a possible solution of your problem: For the Record button in the inspector 'Defer Automation Output' must be checked.
      Please try it and report back.
    • Jan 30 2011 | 11:47 am
      Broc, you did it!! It's working now, thanks a lot!
      Also I googled "defer automation output" and found some guidelines by Ableton that said: "If parameter automation causes high CPU load, then try enabling “Defer Automation Output” in the parameter inspector". Since I had exactly this problem in another patch (that I really needed to get working) I tried it there also and it works now.
      Seems like your info solved two max problems at once :) Thanks again!