Nice new M4LAPI effects, great but flawed?

[chapelier fou]

Sorry to ask this, but where are these effects. I don't see them anywhere, is this because i downloaded "software only" of 8.2.2 ?

[ark]

It seems to me that if 3phase were to stop using Live entirely, everyone would be happier including 3phase.

[S4racen]

Look at the deferlow object if your currently using delays to get things working in the right order with live.remotes... And as for the parameters being wrong using the live.number box, not at all, you can even name you live.number boxes so they have the correct title for when you check for their automation lines...

Cheers
D

[barstu]

Is there a way having the numbox or even a live.dial change it's unit style or name (Long Name or Short Name) at runtime?

[hoffman2k]

Is there a way having the numbox or even a live.dial change it's unit style or name (Long Name or Short Name) at runtime?

Only by faking it with extra text-boxes to display the values and names.
You can't change the range, name and unit style of a parameter when the device is loaded.

[barstu]

That's a shame. I hope that is something that is addressed in future versions.

[hoffman2k]

That's a shame. I hope that is something that is addressed in future versions.

It probably wont be because of the nature of parameters. A parameter on a MFL device is absolute, just like a parameter on any other Live device.
It has a fixed name and a fixed range. 2 bits of data that are used to enable the Automation and Modulation envelopes. There is no way it could technically work out and it not causing lots of problems in patches that are dependent on those parameters at load.

But that doesn't mean its completely impossible.



I basically made 1 knob that does exactly what I want and I'm using it in 16 bpatchers. If you're not familiar with that object, it basically allows you load other patches inside this object.
I can use the same patch 16 times.
The only downside is that on Automap devices, the parameter reads "Dial 1, Dial 2, etc." instead of the displayed parameter name. And the Range is always 0. to 1. with scaling done in the patch that contains the knob. The only way to get the custom readouts to an external device is with OSC.

[barstu]

I'm using a bpatcher for each of my nobs. So how are you getting the correct units there? I guess I should open your patch and have a look

I understand that renaming might currently be technically hard, but if you to a ctl-R and rename something does that doesn't break things as far as I know.

You've touched on exactly why I wanted this, the automap function of the Novation RemoteSL and it's ability to get the names/units of the parameters onto the LED.

I've worked around this by selecting the device (blue hand) and then fudging the hardware lock device command with max runtime loopback patch.

[hoffman2k]

I'm using a bpatcher for each of my nobs. So how are you getting the correct units there? I guess I should open your patch and have a look

I understand that renaming might currently be technically hard, but if you to a ctl-R and rename something does that doesn't break things as far as I know.

You've touched on exactly why I wanted this, the automap function of the Novation RemoteSL and it's ability to get the names/units of the parameters onto the LED.

I've worked around this by selecting the device (blue hand) and then fudging the hardware lock device command with max runtime loopback patch.

The units come from a "call __str__" function. Its exactly the same function used for getting the unit for the Automap/Mackie controllers with python.

There is really no way to get this functionality out of the box. Its just a big technical issue to change loaded parameters. The name comes from the same place as the value information.
You could work around it by adding Sysex support to a device like 16 Macros and build upon that to effectively bypass Ableton's automap functionality. But this is definitely one of those easier said than done jobs.

[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 stores it as a parameter in the max plugin not in the controlled device, which is not what is wanted....

[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

But it stores it as a parameter in the max plugin not in the controlled device, which is not what is wanted....

I don't see that as a problem? You either use a live.object that records all the time but doesn't have the speed of live.remote or use a live.remote for audio rate updates and record it's motion using a live.number.....

In an ideal world we'd have a live,remote that didn't grey out a parameter so you'd simply record it's own automation, it doesn't work like that though so you need a workaround...

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 stores it as a parameter in the max plugin not in the controlled device, which is not what is wanted....

I don't see that as a problem? You either use a live.object that records all the time but doesn't have the speed of live.remote or use a live.remote for audio rate updates and record it's motion using a live.number.....

In an ideal world we'd have a live,remote that didn't grey out a parameter so you'd simply record it's own automation, it doesn't work like that though so you need a workaround...

Cheers
D

The problem comes when you play back your set. The live.number box may be automated but unless your max plug is running the data won't get out to the live parameter, and if you max plug is running it will over write the live.number data. You can copy/paste the automation onto the parameter in Live, but this is exactly the nuisance that I am trying to avoid. Incidentally, I'm not clear on whether live.object records continuously, it certainly does not produce continuous data, it only sends data when it changes.

[S4racen]

Agreed, you can't use it with dynamic changes during the set to what the live.remote is mapped to... This is why i don't change the mappings and hard code everything per template....

Not sure on the Live.object thing, but isn't any automation only reported when it changes, until the change the values remain the same?? And i think the live.object now has a speedlim variable so you can set it to a reasonable time frame and save some of the undo record being clogged up?

Cheers
D

[queglay]

@ hoffman2k

in your 16 macros patch, I can see you use a live.observer value to go into a live.object which then calls the value again and goes through the fit/scale routine. but isn't this expensive? maybe its unnecessary, would it be better for the obeserved value to just go straight into the scale which has already had its max and min ranges set correctly when the dial is mapped? then you arent makeing a call to the LOM every time a dial changes.

on another note you may find interesting to lighten your code, you can send the message

Code: Select all

_parameter_shortname "Dial Name"

to dynamically rename the actual dials. Then you don't have to use osc so long as your controller picks up the parameter name which by default is called dial 1, dial 2 etc, until you use that function. pretty sure any automap controller would be fine. I've started to implement this in my repurposed version of 16 macros which its great you did to give me a launch pad from.

I'm starting to adapt it to a specific function for the push controller, and trying to make it as lightweight as I can. I'm doing this to give more comprehensive parameter mapping over all the maschine 2.0 kits, about 8 parameters per sound from the push controller in my Push VST Bridge.

To achieve this I originall wanted to have a m4l device on every chain of a 16 chain drum rack to have crazy mapping pointing back to a single maschine 2.0 instance. but just a single m4l device is so heavy i had to scrap that option, i wish they could make it more efficient. its actually better in terms of cpu to just have 16 empty racks, and one m4l device to read them all and do the mapping from that single device. this uses a mere fraction of the cpu than 16 totally empty m4l midi devices do. i dont know whats going on there under the hood for m4l to be so heavy but I'm sure they could makes things a little nicer in terms of cpu consumption.

[hoffman2k]

The scale changes with each parameter. One goes from 0 to 1, the next from -36 to +36, etc..

It can definitely be leaner, you should have seen 1.0

I did not know that we can now send names to controllers from a simple call. This will be interesting for Push and all the Novation stuff with displays.

Doing it all from one device is pretty much the point. We only have 2 hands, why would we need 32+ knobs?
It also goes back to playing a groovebox. Those things have limited controls, but the best ones allowed you to develop muscle memory for playing parts. It meant that after a specific button, you know what the knobs are going to control.

I was close to putting out a new version, but it basically needs a rewrite. If Ableton isn't going to fix that Undo bug, I'm going to have to deploy a workaround. In order to not have to work with storing external files, I'll probably need to find a way to compress a big Coll to store as a Blob.
Instead of using a polyphonic matrix of live.remotes that store ID's.
I prefer keeping Live.remote~ because it behaves much smoother.