max4live+midi controller/keystroke problem. bug?
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
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.....
Ben
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.
Christoph
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 ???
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.
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?
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.
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...
I wonder if turning toggle into trigger would also be possible for key assignments..
Of course, have a look a stripnote...
Sorry, I meant keys from computer keyboard, so called key mapping in Live.
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.
Thanks! I'll try this later but looks like it's going to work. This Max community is so cool :)
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?
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.
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...
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?
Thanks, I'm going to try this! Also thanks for the hint concerning the start time, didn't think about that before.
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.
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.
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!