Nice new M4LAPI effects, great but flawed?

[Macrostructure]

The new version of Live / M4L ships with some amazing effects and in particular some API tools for automating the action of a live set, for example the device animator and randomisers, the LFOs etc etc. Too many to mention really and very nicely designed they are, addressing a lot of control issues. Thanks to the developers.

However, all these devices have two problems:

1. they take exclusive control of the parameter in Live, so to adjust it manually at any time you first have to disconnect the device from the control manually or turn the device off. This is a pain.
2. they do not write automation data into the arrangement. This means that for adjustment of the result you either have to record the audio and fiddle with that, or work out a way of making the M4L device produce a fractionally different result on the next run through, and record that to audio or lock that nuance in somehow and always run the M4L device when you want that sound. You can't tweak the parameter automation data like you could if you had done the control manually, because there isn't any.

What does everyone think about this?

ms

[hoffman2k]

The new version of Live / M4L ships with some amazing effects and in particular some API tools for automating the action of a live set, for example the device animator and randomisers, the LFOs etc etc. Too many to mention really and very nicely designed they are, addressing a lot of control issues. Thanks to the developers.

However, all these devices have two problems:

1. they take exclusive control of the parameter in Live, so to adjust it manually at any time you first have to disconnect the device from the control manually or turn the device off. This is a pain.
2. they do not write automation data into the arrangement. This means that for adjustment of the result you either have to record the audio and fiddle with that, or work out a way of making the M4L device produce a fractionally different result on the next run through, and record that to audio or lock that nuance in somehow and always run the M4L device when you want that sound. You can't tweak the parameter automation data like you could if you had done the control manually, because there isn't any.

What does everyone think about this?

ms

1) The tradeoff there is that otherwise you have the connected parameter flooding the undo history. Without this fixed connection, you get into an endless undo loop.

2) The difference between having control over automation/modulation in a device or not, is nothing more than setting an option for the parameters you want to control. The parameter visibility is probably set to "Stored" while you want "Automated and Stored".

[pepezabala]

I am still starting to explore the new effects, but yesterday I had a very nice combo of InstantHaus and DeviceAnimator going.

I still did not record into Arrangement, and I can see that there might be lots of issues regarding automation not being recorded or being overwritten by an active DeviceAnimator during playback. But I believe that you need to treat some devicecombinations just like real musicians - sometimes they play a magnificient take, and it's up to you to be there and record it right away to audio ...

[Poster]

why is it you can only map to 1 parameter?
I run into a lot of situations where I want one device controlling multiple parameters..

[hoffman2k]

why is it you can only map to 1 parameter?
I run into a lot of situations where I want one device controlling multiple parameters..

Because that is how they were designed. Nobody made an LFO that maps to 10 things yet, but that doesn't make it an impossible feature.
Its much more an issue of interface design than feature implementation imho.

[Poster]

why is it you can only map to 1 parameter?
I run into a lot of situations where I want one device controlling multiple parameters..

Because that is how they were designed. Nobody made an LFO that maps to 10 things yet, but that doesn't make it an impossible feature.
Its much more an issue of interface design than feature implementation imho.

aah.. so it's just a question of multiplying the whole mapping section inside the device?

edit: yes! works like a charm..

[Macrostructure]

actually there is a device for mirroring one control onto another, I forget what it's called, but the scenario is catered for....

[Macrostructure]

The new version of Live / M4L ships with some amazing effects and in particular some API tools for automating the action of a live set, for example the device animator and randomisers, the LFOs etc etc. Too many to mention really and very nicely designed they are, addressing a lot of control issues. Thanks to the developers.

However, all these devices have two problems:

1. they take exclusive control of the parameter in Live, so to adjust it manually at any time you first have to disconnect the device from the control manually or turn the device off. This is a pain.
2. they do not write automation data into the arrangement. This means that for adjustment of the result you either have to record the audio and fiddle with that, or work out a way of making the M4L device produce a fractionally different result on the next run through, and record that to audio or lock that nuance in somehow and always run the M4L device when you want that sound. You can't tweak the parameter automation data like you could if you had done the control manually, because there isn't any.

What does everyone think about this?

ms

1) The tradeoff there is that otherwise you have the connected parameter flooding the undo history. Without this fixed connection, you get into an endless undo loop.

2) The difference between having control over automation/modulation in a device or not, is nothing more than setting an option for the parameters you want to control. The parameter visibility is probably set to "Stored" while you want "Automated and Stored".

Actually if you use live.object instead of live.remote (I haven't delved, but from the functionality I would assume the former to be the case) and only set the updates to happen every 50ms or so, or even only when the parameter is actually changed, then the amount of data generated is not overly cumbersome.

[hoffman2k]

The new version of Live / M4L ships with some amazing effects and in particular some API tools for automating the action of a live set, for example the device animator and randomisers, the LFOs etc etc. Too many to mention really and very nicely designed they are, addressing a lot of control issues. Thanks to the developers.

However, all these devices have two problems:

1. they take exclusive control of the parameter in Live, so to adjust it manually at any time you first have to disconnect the device from the control manually or turn the device off. This is a pain.
2. they do not write automation data into the arrangement. This means that for adjustment of the result you either have to record the audio and fiddle with that, or work out a way of making the M4L device produce a fractionally different result on the next run through, and record that to audio or lock that nuance in somehow and always run the M4L device when you want that sound. You can't tweak the parameter automation data like you could if you had done the control manually, because there isn't any.

What does everyone think about this?

ms

1) The tradeoff there is that otherwise you have the connected parameter flooding the undo history. Without this fixed connection, you get into an endless undo loop.

2) The difference between having control over automation/modulation in a device or not, is nothing more than setting an option for the parameters you want to control. The parameter visibility is probably set to "Stored" while you want "Automated and Stored".

Actually if you use live.object instead of live.remote (I haven't delved, but from the functionality I would assume the former to be the case) and only set the updates to happen every 50ms or so, or even only when the parameter is actually changed, then the amount of data generated is not overly cumbersome.

In some cases if you control a parameter with live.object with something like live.dial that is getting value updates from live.observer, you get an infinite loop of 2 setting updating each other.

However, with Kapture there's no need for observers, so the undo history is probably not a problem here. People just tend to use live.remote because its supposedly faster.

[Macrostructure]

In some cases if you control a parameter with live.object with something like live.dial that is getting value updates from live.observer, you get an infinite loop of 2 setting updating each other.

However, with Kapture there's no need for observers, so the undo history is probably not a problem here. People just tend to use live.remote because its supposedly faster.

Yup, it is faster and smoother, but yeah, not always what you want. I have written some devices and ended up using live.object for some of the reasons outlined above. Not 100% smooth though.

I can't find Kapture - where is it please?

By the way, despite the above, I am becoming impressed with M4L now in ways that I haven't been for the last 18 months. It feels like some maturity has arrived.

[S4racen]

If you use a live.number box before the live.remote and set this to be automated and stored you will indirectly record the automation of the end control and can then change it with envelopes after recording, best of both worlds....

Cheers
D

[Macrostructure]

If you use a live.number box before the live.remote and set this to be automated and stored you will indirectly record the automation of the end control and can then change it with envelopes after recording, best of both worlds....

Cheers
D

But it get's stored as a different parameter to the one you want leading to multiplication of parameters etc etc...no?

[3phase]

the biggest flaw is that they come with a L8.22 that is highly inferior to its previous version.. so the struggle with L8 continues even 24 month after its release..
And all max fans claim that theire max integration has nothing to do with that as the jnes declares that radio activity does no harm..

[hoffman2k]

In some cases if you control a parameter with live.object with something like live.dial that is getting value updates from live.observer, you get an infinite loop of 2 setting updating each other.

However, with Kapture there's no need for observers, so the undo history is probably not a problem here. People just tend to use live.remote because its supposedly faster.

Yup, it is faster and smoother, but yeah, not always what you want. I have written some devices and ended up using live.object for some of the reasons outlined above. Not 100% smooth though.

I can't find Kapture - where is it please?

By the way, despite the above, I am becoming impressed with M4L now in ways that I haven't been for the last 18 months. It feels like some maturity has arrived.

My bad, I was mixing up threads in regards to what plugins where being discussed. Kapture can be download from the feature on Ableton.com.

[barstu]

Currently debating whether to use live.remote~ vs live.object. I have a patch that automaps 8 dials to the 1st device in a given rack chain, when I use live.remote~ it crunches the whole sound up. I am having to use the delay object to map each dial, one at a time, in staggered fashion. I find I don't get this with the live.object/live.observer combo, but then I get loads of undo history. Saying that changing live.remote~ gives an undo history doesn't it? but it's only 1 per nob twist I guess rather than 1 per unit?

It's nice being able to still change the slaved parameter.