Ableton Forum

crumhorn wrote:

jeremydb wrote:

crumhorn wrote:A similar question:

Can MFL automate the controls on other devices?

Funny, I have a beer riding on the fact that I was certain that no one would ask this question at NAMM. You're not at NAMM, are you? Because I really want that beer.

The short answer is yes. The long answer is that it's not as easy as it sounds, but that it should be possible, with some work on the part of the user.

jb

No I'm not at NAMM so your beer is still safe.

I guess it would involve going through the Live API - right... wrong?

Good guess.

jb

Hi,

I am not missing anything. What I have been trying to say is remote MIDI mapping. You were the one who talked about Live instruments receiving MIDI data directly And I understand Crumhorn's issue about routing MIDI data to Live via MIDI Yoke. It's not a prefered way of doing things. I wouldn't mind going that way, though, if it allows me to process MIDI in many different ways in Max and then route it to Live. I will probably not use this that much anyway, when I can already automate pluggo-based plugins within Live using MFL. Many Live effects already have dedicated LFOs. What I would use this for is mainly transforming MIDI data received from an external MIDI controller (like mapping curves, certain thresholds that trigger other midi data to change things in other instruments, effects)... Let's say I'm controlling a cutoff parameter with a knob. When the midi CC reaches, say 64, it triggers another midi event (note on off, midi cc) that turns a delay on (or turns the resonance down).

Korhan wrote:Hi,

I am not missing anything.

Well...

Korhan wrote: If MFL effects can send MIDI over internal MIDI busses, then they can automate every parameter in any MFLi Live or AU/VST effect/instrument, either through Max messages (a la Pluggos) or by sending MIDI CC over internal MIDI busses that can easily be mapped to Live/Plugin parameters by Live's MIDI assign feature.

.. is not correct since you cannot send CC data over any internal bus to Lives own devices and you say "any".

But if you're happy, I'm happy.

Man you are difficult, aren't you!

Let's forget about Live 8, MFL, etc.

- I have Live 6.
- Live 6 can assign midi cc's to any Live parameter (such as controlling filter cutoff with a midi controller sending midi data to Live over a MIDI input defined in Live's preferences and activated as Remote).
- I have Max
- I have an Sine LFO patch in Max that sends out a midi cc (let's say midi cc#12) to Midi Yoke #1
- I have Midi Yoke #1 activated as Remote in Live's preferences
- In Live, I to Ctrl-M to go to MIDI assignment mode
- I select any parameter in Live, e.g. the Pitch parameter in Graindelay and it's instantly mapped to midi cc#12 sent by the Max LFO over Midi Yoke #1

So, you now have a MIDI LFO in Max controlling the Pitch parameter in Graindelay, which is a Live device.

I've done similar things using Pure Data and Live before so I know!

I hope it's clear now because I cannot make this any clearer. Maybe someone else can.

I know what you're saying. I myself do the same thing with sending midi over loopback into live from Max.

I KNOW you can do that.

But the question that started this thread is not about doing that! It was about doing that inside of Live itself!

So I agree with you, you can do what you describe, but that's not the question at hand.

Let's not fight baby. I love you.

I am soooo happy for remembering that nanokontrol coupon, that, it turned out, gave me a 50 USD discount for Live 7, which I immediately purchased (10 minutes ago). Now the upgrade price page on Ableton.com tells me I can upgrade to Live 8 for 59 USD! Sweet!!

If you have a discount coupon for Live and haven't used it yet, now is the time.

I did the same thing with the Live version that came with my Trigger Finger.

Best purchase ever! (until the Live 8/APC40 one that is)

jeremydb wrote:

crumhorn wrote:A similar question:

Can MFL automate the controls on other devices?

Funny, I have a beer riding on the fact that I was certain that no one would ask this question at NAMM. You're not at NAMM, are you? Because I really want that beer.

The short answer is yes. The long answer is that it's not as easy as it sounds, but that it should be possible, with some work on the part of the user.

jb

And possibly also with some work on the Live part. An important technical term here is *realtime*. In other words, the question is how tight the timing might be if it goes via the Max->Live API. It is not by chance that the mapping of midi controllers to Ableton device controls is done in the realtime domain and thus much faster than anything you can *see*.

I'm sure we will not hesitate to do some experiments and improvements with time, and what we already presented is just the beginning.

Ralf wrote:In other words, the question is how tight the timing might be if it goes via the Max->Live API. It is not by chance that the mapping of midi controllers to Ableton device controls is done in the realtime domain and thus much faster than anything you can *see*.

right, so the interesting questions are how do things like the max scheduler and high / low priority events work withing the MfL environment?

Do you still have the usual set of scheduler options? (poll throttle, queue throttle etc)

mdk wrote:

Ralf wrote:In other words, the question is how tight the timing might be if it goes via the Max->Live API. It is not by chance that the mapping of midi controllers to Ableton device controls is done in the realtime domain and thus much faster than anything you can *see*.

right, so the interesting questions are how do things like the max scheduler and high / low priority events work withing the MfL environment?

Do you still have the usual set of scheduler options? (poll throttle, queue throttle etc)

M4L is 'stuck' in Scheduler in Audio Interrupt mode. This means that there are essentially 2 threads of operation: GUI and Audio (with the scheduler running in the audio thread, which is synced to Live's transport). There's no reason why you can't send messages to ";max" or ";dsp" to make changes to the GUI throttling and stuff like that, but you probably won't need to. Objects like 'defer' and 'deferlow' continue to work as you'd expect.

jb