max4live+midi controller/keystroke problem. bug?

Jan 17, 2011 at 11:12am

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:

– Pasted Max Patch, click to expand. –

Thanks!!
Christoph

#54450
Jan 17, 2011 at 2:45pm

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

#196108
Jan 17, 2011 at 10:30pm

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

#196109
Jan 19, 2011 at 12:55am

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 ???

Attachments:
  1. pgminTest.maxpat
#196110
Jan 19, 2011 at 9:14pm

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.

#196111
Jan 20, 2011 at 12:53am

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?

#196113
Jan 20, 2011 at 12:39pm

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.

#196114
Jan 20, 2011 at 1:41pm

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…

#196115
Jan 20, 2011 at 2:45pm

I wonder if turning toggle into trigger would also be possible for key assignments..

#196116
Jan 20, 2011 at 2:55pm

Of course, have a look a stripnote…

#196117
Jan 20, 2011 at 3:14pm

Sorry, I meant keys from computer keyboard, so called key mapping in Live.

#196118
Jan 20, 2011 at 6:46pm

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.

– Pasted Max Patch, click to expand. –
#196119
Jan 21, 2011 at 5:19pm

Thanks! I’ll try this later but looks like it’s going to work. This Max community is so cool :)

#196120
Jan 21, 2011 at 7:15pm

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?

#196121
Jan 25, 2011 at 7:19pm

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.

#196122
Jan 27, 2011 at 12:50pm

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…

#196123
Jan 27, 2011 at 2:22pm

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?

#196124
Jan 28, 2011 at 10:31am

Thanks, I’m going to try this! Also thanks for the hint concerning the start time, didn’t think about that before.

#196125
Jan 28, 2011 at 4:37pm

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.

#196126
Jan 29, 2011 at 3:15pm

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.

#196127
Jan 30, 2011 at 11:47am

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!

#196128

You must be logged in to reply to this topic.