Can't open your patch for now so it's just a guess but I think you should trick Live by using the IAC port if you're on a mac, that could imply some latency though...

That's exactly what I tried just after sending my post and it works. But it's pretty complex: requires one midi track + one audio track + send to IAC out + receive in IAC in, etc... In that case it is even simpler to create an external max patch. I'm trying to put all the elements on the same track in Live. But, from what I understand, the issue is that midi mapping in Live can only be addressed from an external midi input, am I right?

Thanks for your answer though and any other idea is welcome! Best, F.

That's what I finally did when I wanted to build a device to use a joystick as a midi input for instruments : built a standalone app sending midi to live via IAC.

use an audio plugin. connect it to the parameter via a map button via one of the m4l API building blocks. midi map it to your midi controller in live. I did that in this patch:

thanks Ryan, that's what I needed to do, works great!

I had misunderstood what you wanted to achieve, this is simply the way to go !

Problem: it eats a lot of CPU to do this and I'll use at least 16 of these controllers intensively (even though I have the most powerful MBP to date). Try to move quickly a patched M4L API controller with an eye on cpu and you'll see what I mean. This might be explained by the fact that M4L API uses the object sig~ which generates way more informations than midi. Is there a way to reduce the data flow? Or to trigger automation via midi only using an object like "sig" (without the ~)? I've searched for a "sig" objet sending just midi data but it does't seem to exist. As of now, my best solution remains using an external max patch to send midi via IAC to Live: much wiser in terms of cpu consumption... Though, having a M4L plug integrated in a Live file sounds very nice. Any ideas?