HUGE DISSAPOINTMENT - Still no automation midi clip record!

[Machinate]

I suspect this automation issue is one of the latter - ie not fixable via MFL.

Oh, I definitely suspect it WILL be something fixable via MFL. That and "DUAL MONITOR SUPPORT" will be the big ones, I think.

[Khazul]

I suspect this automation issue is one of the latter - ie not fixable via MFL.

Oh, I definitely suspect it WILL be something fixable via MFL. That and "DUAL MONITOR SUPPORT" will be the big ones, I think.

Live (AFAIK) is not written using the same runtime as MAX. Live will therefore probably expose a finite feature set to the MAX run time.

So if a feature you should want to manipulate isnt exposed, then you cant interfere with it. The best you can do is approximinate is and hope your approximation doesnt clash with live's internal workings, and again that is only if alternative functionality is exposed through MFL.

To actually intercept and replace a feature, live has to choose to enable this behaviour by making available some kind of callouit or event into the MAX runtime along with a means to access all necessary state data that may be required in order to incepts the feature. Even then, the most you may be able to do is influence the feature rather than replace it. It will be a choice made for every feature and state data item they want to expose.

To start with, I expect that clip data will be exposed, along with audio streams and if we are lucky, phsyical device (audio midi) ports and selection menus. this would be sufficient say to implemnent menu based processing tools to perform offline editing functions on midi and audio clips. (MIDI clips has allready been confirm as being availabel for this to some degree or other), though access to automation parameters AFAIK has not been confirmed. Neither has clip audio data, nor clip metadata (tempo, length, start, end etc), but I would guess is might be.

Also the communications between Live and a controller devices has been confirmed as changable - for eg so you could change the behaviour of the APC-40 and perhaps write your own custom controller mappers.

We know its is possible to implement MIDI processing plugins and audio processing plugins along with access to Live native UI elements (though whether that is all native UI elements remain to be seen, but lets hope it is). I would guess though these plugin interfeaces you can implement Live style extende plugins (live seems to expose more functionality to its native plugins than it can to VST and AU plugins).

Some of the hinted at cooler stuff that you can do with MFL basically just needs acces to UI elements, control srface comminications, live host clocks and song pos and midi/audio streams - ie no where near enough to replace core live functionality - for eg, like automation envelopes.

It wont be like having the source code to Live. The folks who are probably best placed to say what is reasonable to expect from it are those know know both what you can do with max/msp/jitter and those who know the python scripting API. this API may not even exist in Live 8, however I wold guess its functionality may get merged into MFL as a means of provide custom control surface drivers etc.

I sincerely hope they keep enough basic MAX functionality such that externally developed MAX objects can be used with it as well, however there is absolutely no gurantee of this, so for eg - I have no idea of the DMX lighting interface object I have will work - i hope it will, but in the end, no guarantee at all.

I think alot of people are getting overly hyped about the possibilities of MFL and could be in for a huge diappointment. For those of us who have an idea of what you can do with MAX/MSP in the context of plugins etc, then it wont be a disappointment at all, actually we may be pleasently suprised at getting access to stuff we didnt expect.

But unless Live 8 has been re-written from the groun up to expose everything to MFL and allow anything to be intercepted (you have to plan for this within a single runtime, never mind integrating another one as well) - the the picture people are painting simply will not happen.

It will be very powerful - but mostly for writing plugins and controll surface and perhaps for offline processing utilities (for eg, the splice audio clip to drum rack function could we written in MFL *if* we are very lucky).

There wont be any writing of dual screen support. You should be able to offline re-write automation data and do some manipulations. I really hope functionlaity like creating tracks and setting up there parameters can be done from a menu, but I wouldnt be at all surpsed if that cant be accessed unless it was a deliberate choice as a way of potentially enable some of the macro functionality that can be found in other DAWs.


We shall see - dont expect much more than the currently hinted at essentals and certainly not for the first release - buit that will still be very powerful for certain kind of functions (plugins, control surfaces etc).

[doc holiday]

some kind of global midi looper that would loop automation and send it back to live for a x number of bars.

record x number of bars from initial tweak then loop
press button then set knob to cancel the loop at the new setting.

[Nick the Zombie]

This is the single best layperson-oriented explanation of what an API is that I have read. I tried to explain it many times back in my programming days and it was always pretty frustrating.

I suspect this automation issue is one of the latter - ie not fixable via MFL.

Oh, I definitely suspect it WILL be something fixable via MFL. That and "DUAL MONITOR SUPPORT" will be the big ones, I think.

Live (AFAIK) is not written using the same runtime as MAX. Live will therefore probably expose a finite feature set to the MAX run time.

So if a feature you should want to manipulate isnt exposed, then you cant interfere with it. The best you can do is approximinate is and hope your approximation doesnt clash with live's internal workings, and again that is only if alternative functionality is exposed through MFL.

To actually intercept and replace a feature, live has to choose to enable this behaviour by making available some kind of callouit or event into the MAX runtime along with a means to access all necessary state data that may be required in order to incepts the feature. Even then, the most you may be able to do is influence the feature rather than replace it. It will be a choice made for every feature and state data item they want to expose.

To start with, I expect that clip data will be exposed, along with audio streams and if we are lucky, phsyical device (audio midi) ports and selection menus. this would be sufficient say to implemnent menu based processing tools to perform offline editing functions on midi and audio clips. (MIDI clips has allready been confirm as being availabel for this to some degree or other), though access to automation parameters AFAIK has not been confirmed. Neither has clip audio data, nor clip metadata (tempo, length, start, end etc), but I would guess is might be.

Also the communications between Live and a controller devices has been confirmed as changable - for eg so you could change the behaviour of the APC-40 and perhaps write your own custom controller mappers.

We know its is possible to implement MIDI processing plugins and audio processing plugins along with access to Live native UI elements (though whether that is all native UI elements remain to be seen, but lets hope it is). I would guess though these plugin interfeaces you can implement Live style extende plugins (live seems to expose more functionality to its native plugins than it can to VST and AU plugins).

Some of the hinted at cooler stuff that you can do with MFL basically just needs acces to UI elements, control srface comminications, live host clocks and song pos and midi/audio streams - ie no where near enough to replace core live functionality - for eg, like automation envelopes.

It wont be like having the source code to Live. The folks who are probably best placed to say what is reasonable to expect from it are those know know both what you can do with max/msp/jitter and those who know the python scripting API. this API may not even exist in Live 8, however I wold guess its functionality may get merged into MFL as a means of provide custom control surface drivers etc.

I sincerely hope they keep enough basic MAX functionality such that externally developed MAX objects can be used with it as well, however there is absolutely no gurantee of this, so for eg - I have no idea of the DMX lighting interface object I have will work - i hope it will, but in the end, no guarantee at all.

I think alot of people are getting overly hyped about the possibilities of MFL and could be in for a huge diappointment. For those of us who have an idea of what you can do with MAX/MSP in the context of plugins etc, then it wont be a disappointment at all, actually we may be pleasently suprised at getting access to stuff we didnt expect.

But unless Live 8 has been re-written from the groun up to expose everything to MFL and allow anything to be intercepted (you have to plan for this within a single runtime, never mind integrating another one as well) - the the picture people are painting simply will not happen.

It will be very powerful - but mostly for writing plugins and controll surface and perhaps for offline processing utilities (for eg, the splice audio clip to drum rack function could we written in MFL *if* we are very lucky).

There wont be any writing of dual screen support. You should be able to offline re-write automation data and do some manipulations. I really hope functionlaity like creating tracks and setting up there parameters can be done from a menu, but I wouldnt be at all surpsed if that cant be accessed unless it was a deliberate choice as a way of potentially enable some of the macro functionality that can be found in other DAWs.


We shall see - dont expect much more than the currently hinted at essentals and certainly not for the first release - buit that will still be very powerful for certain kind of functions (plugins, control surfaces etc).

[Machinate]

Some of the hinted at cooler stuff that you can do with MFL basically just needs acces to UI elements, control srface comminications, live host clocks and song pos and midi/audio streams - ie no where near enough to replace core live functionality - for eg, like automation envelopes.

thankfully not true.

I sincerely hope they keep enough basic MAX functionality such that externally developed MAX objects can be used with it as well, however there is absolutely no gurantee of this, so for eg - I have no idea of the DMX lighting interface object I have will work - i hope it will, but in the end, no guarantee at all.

yes there is - it will be the FULL maxMSP AND jitter, complete with externals support, udpsend, serial, all these things - and this has been repeated several times.

There wont be any writing of dual screen support.

Actually, this is going to be one of the first things out of the bat: Floating window, all session view mixer neccesities copied, show it on 2nd monitor while in arrangement view - done!

[Tone Deft]

anyone else a bit bugged by the spelling of 'max'? it's not 'MAX' or 'Max.' just a lovable style quirk to the language.

the replaceable GUIs are going to be fun. with max you can even take a .jpg or .gif and turn parts of a picture into a control. some NSFW skins are in order!! and we thought dB markers were cool.

[Euklid.fox]

agree with the topic, even if i like patching, the natural way is


LiveTweakPot-record-yeah i got a new clip

missing from live1 became drastic with midi,
really the ultimate issue that is there from a long. quite paradoxal
live is the fastest imagination workflow but this would allow it to be The natural way., the "live" way,
but they will certainly do that rewrite a day, i just imagine how it will be so huge to rediscover live with that,

[jamief]

But, if you had been keeping track of Robert as he made a merry stroll through our fair pastures...

Please don't ASSume I haven't. Sorry, I just don't buy the complete rewrite excuse. This is supported in hardware and many DAWs so if it is indeed true it was a HUGE oversight to begin with. I have immense respect for Henke but I do not take his word as gospel. If any of you are offended you're taking it way too personal. As a paying customer who doesn't whine about every single gripe I feel I am totally in my right to explain my disappointment that an essential component to midi pattern recording has continued to be left out. It's a big enough omission to make a serious dent in the potential expressiveness of this revolutionary software.

Six_o_clock_crow, you're proably right that "bullshit" was a bit harsh (you should hear me when I'm really trying) but don't act like I've insulted your personal friend. Certainly Robert and Dom have excellent work ethics, but this is about business - not personal favors. Empathy is one thing, but the bottom line is what tools will achieve the result you need and I feel this is a severe handicap and I'm certainly not alone.

I am in general a very happy user of Live but you can be damn sure I won't bite my lip out some notion of brand loyalty.

what a tit !

[ilia]

Some of the hinted at cooler stuff that you can do with MFL basically just needs acces to UI elements, control srface comminications, live host clocks and song pos and midi/audio streams - ie no where near enough to replace core live functionality - for eg, like automation envelopes.

thankfully not true.

care to elaborate?
those live.object/live.observer objects are but a huge cloud of suspense hanging over our heads.

[Machinate]

Some of the hinted at cooler stuff that you can do with MFL basically just needs acces to UI elements, control srface comminications, live host clocks and song pos and midi/audio streams - ie no where near enough to replace core live functionality - for eg, like automation envelopes.

thankfully not true.

care to elaborate?
those live.object/live.observer objects are but a huge cloud of suspense hanging over our heads.

What I mean by that is "access to input/output streams PLUS bidirectional access to UI == control anything on the UI. Now, there's still some caveats, as also mentioned by Khazul, like track generation, but at the very least *any knob and slider can be accessed by max* - and since it can intercept incoming streams.... it is no longer a case of not being able to control automation. Note that no-one is talking about Replacing anything. You currently CANT record automation into session view, I think Khazul is well aware of that - so it's a case of augmenting the "modulation" part, the clip envelopes.

Hope that is a bit clearer?
cheers.

[deva]

thankfully not true.

care to elaborate?
those live.object/live.observer objects are but a huge cloud of suspense hanging over our heads.

What I mean by that is "access to input/output streams PLUS bidirectional access to UI == control anything on the UI. Now, there's still some caveats, as also mentioned by Khazul, like track generation, but at the very least *any knob and slider can be accessed by max* - and since it can intercept incoming streams.... it is no longer a case of not being able to control automation. Note that no-one is talking about Replacing anything. You currently CANT record automation into session view, I think Khazul is well aware of that - so it's a case of augmenting the "modulation" part, the clip envelopes.

Hope that is a bit clearer?
cheers.

THis is from the Ableton MfL page:

"Max for Live also provides objects that allow you to access and modify the inner workings of Live. Modify the tracks, clips, notes, names and values, selection states—and pretty much anything else you can see or hear in Live. This API also allows you to access controller hardware via Live, creating new mappings that can completely repurpose a hardware device."

[Machinate]

yeah.

Current fave new object:

"live.drop" - drag and drop comms between Live and maxForLive - load a buffer just by dragging in the sample

[Johnisfaster]

I suspect this automation issue is one of the latter - ie not fixable via MFL.

Oh, I definitely suspect it WILL be something fixable via MFL. That and "DUAL MONITOR SUPPORT" will be the big ones, I think.

Live (AFAIK) is not written using the same runtime as MAX. Live will therefore probably expose a finite feature set to the MAX run time.

So if a feature you should want to manipulate isnt exposed, then you cant interfere with it. The best you can do is approximinate is and hope your approximation doesnt clash with live's internal workings, and again that is only if alternative functionality is exposed through MFL.

To actually intercept and replace a feature, live has to choose to enable this behaviour by making available some kind of callouit or event into the MAX runtime along with a means to access all necessary state data that may be required in order to incepts the feature. Even then, the most you may be able to do is influence the feature rather than replace it. It will be a choice made for every feature and state data item they want to expose.

To start with, I expect that clip data will be exposed, along with audio streams and if we are lucky, phsyical device (audio midi) ports and selection menus. this would be sufficient say to implemnent menu based processing tools to perform offline editing functions on midi and audio clips. (MIDI clips has allready been confirm as being availabel for this to some degree or other), though access to automation parameters AFAIK has not been confirmed. Neither has clip audio data, nor clip metadata (tempo, length, start, end etc), but I would guess is might be.

Also the communications between Live and a controller devices has been confirmed as changable - for eg so you could change the behaviour of the APC-40 and perhaps write your own custom controller mappers.

We know its is possible to implement MIDI processing plugins and audio processing plugins along with access to Live native UI elements (though whether that is all native UI elements remain to be seen, but lets hope it is). I would guess though these plugin interfeaces you can implement Live style extende plugins (live seems to expose more functionality to its native plugins than it can to VST and AU plugins).

Some of the hinted at cooler stuff that you can do with MFL basically just needs acces to UI elements, control srface comminications, live host clocks and song pos and midi/audio streams - ie no where near enough to replace core live functionality - for eg, like automation envelopes.

It wont be like having the source code to Live. The folks who are probably best placed to say what is reasonable to expect from it are those know know both what you can do with max/msp/jitter and those who know the python scripting API. this API may not even exist in Live 8, however I wold guess its functionality may get merged into MFL as a means of provide custom control surface drivers etc.

I sincerely hope they keep enough basic MAX functionality such that externally developed MAX objects can be used with it as well, however there is absolutely no gurantee of this, so for eg - I have no idea of the DMX lighting interface object I have will work - i hope it will, but in the end, no guarantee at all.

I think alot of people are getting overly hyped about the possibilities of MFL and could be in for a huge diappointment. For those of us who have an idea of what you can do with MAX/MSP in the context of plugins etc, then it wont be a disappointment at all, actually we may be pleasently suprised at getting access to stuff we didnt expect.

But unless Live 8 has been re-written from the groun up to expose everything to MFL and allow anything to be intercepted (you have to plan for this within a single runtime, never mind integrating another one as well) - the the picture people are painting simply will not happen.

It will be very powerful - but mostly for writing plugins and controll surface and perhaps for offline processing utilities (for eg, the splice audio clip to drum rack function could we written in MFL *if* we are very lucky).

There wont be any writing of dual screen support. You should be able to offline re-write automation data and do some manipulations. I really hope functionlaity like creating tracks and setting up there parameters can be done from a menu, but I wouldnt be at all surpsed if that cant be accessed unless it was a deliberate choice as a way of potentially enable some of the macro functionality that can be found in other DAWs.


We shall see - dont expect much more than the currently hinted at essentals and certainly not for the first release - buit that will still be very powerful for certain kind of functions (plugins, control surfaces etc).

does anybody actually read posts this long?

[Machinate]

Oh, I definitely suspect it WILL be something fixable via MFL. That and "DUAL MONITOR SUPPORT" will be the big ones, I think.

Live (AFAIK) is not written using the same runtime as MAX. Live will therefore probably expose a finite feature set to the MAX run time.

So if a feature you should want to manipulate isnt exposed, then you cant interfere with it. The best you can do is approximinate is and hope your approximation doesnt clash with live's internal workings, and again that is only if alternative functionality is exposed through MFL.

To actually intercept and replace a feature, live has to choose to enable this behaviour by making available some kind of callouit or event into the MAX runtime along with a means to access all necessary state data that may be required in order to incepts the feature. Even then, the most you may be able to do is influence the feature rather than replace it. It will be a choice made for every feature and state data item they want to expose.

To start with, I expect that clip data will be exposed, along with audio streams and if we are lucky, phsyical device (audio midi) ports and selection menus. this would be sufficient say to implemnent menu based processing tools to perform offline editing functions on midi and audio clips. (MIDI clips has allready been confirm as being availabel for this to some degree or other), though access to automation parameters AFAIK has not been confirmed. Neither has clip audio data, nor clip metadata (tempo, length, start, end etc), but I would guess is might be.

Also the communications between Live and a controller devices has been confirmed as changable - for eg so you could change the behaviour of the APC-40 and perhaps write your own custom controller mappers.

We know its is possible to implement MIDI processing plugins and audio processing plugins along with access to Live native UI elements (though whether that is all native UI elements remain to be seen, but lets hope it is). I would guess though these plugin interfeaces you can implement Live style extende plugins (live seems to expose more functionality to its native plugins than it can to VST and AU plugins).

Some of the hinted at cooler stuff that you can do with MFL basically just needs acces to UI elements, control srface comminications, live host clocks and song pos and midi/audio streams - ie no where near enough to replace core live functionality - for eg, like automation envelopes.

It wont be like having the source code to Live. The folks who are probably best placed to say what is reasonable to expect from it are those know know both what you can do with max/msp/jitter and those who know the python scripting API. this API may not even exist in Live 8, however I wold guess its functionality may get merged into MFL as a means of provide custom control surface drivers etc.

I sincerely hope they keep enough basic MAX functionality such that externally developed MAX objects can be used with it as well, however there is absolutely no gurantee of this, so for eg - I have no idea of the DMX lighting interface object I have will work - i hope it will, but in the end, no guarantee at all.

I think alot of people are getting overly hyped about the possibilities of MFL and could be in for a huge diappointment. For those of us who have an idea of what you can do with MAX/MSP in the context of plugins etc, then it wont be a disappointment at all, actually we may be pleasently suprised at getting access to stuff we didnt expect.

But unless Live 8 has been re-written from the groun up to expose everything to MFL and allow anything to be intercepted (you have to plan for this within a single runtime, never mind integrating another one as well) - the the picture people are painting simply will not happen.

It will be very powerful - but mostly for writing plugins and controll surface and perhaps for offline processing utilities (for eg, the splice audio clip to drum rack function could we written in MFL *if* we are very lucky).

There wont be any writing of dual screen support. You should be able to offline re-write automation data and do some manipulations. I really hope functionlaity like creating tracks and setting up there parameters can be done from a menu, but I wouldnt be at all surpsed if that cant be accessed unless it was a deliberate choice as a way of potentially enable some of the macro functionality that can be found in other DAWs.


We shall see - dont expect much more than the currently hinted at essentals and certainly not for the first release - buit that will still be very powerful for certain kind of functions (plugins, control surfaces etc).

does anybody actually read posts this long?

No, we just quote them in their entirety to show disdain.

[forge]

aahhh, another Live release, another sessionview automation Ableton-hate thread!


I am hoping MaxForLive will be able to handle what Ableton have failed to shove in there for years...

+1

I'm doubtful it will really solve it, but at least there should be some decent workarounds that can be saved as patches - like some kind of translator that converts Live native automation data to MIDI CCs so that we can at very least use native devices like VSTs - it's a hack, but it would be better than it is currently

but one thing that really worries me is the point Angstrom made in relation to Bjorn's question on the C74 forum about accessing parameters of Ableton's devices with the API stuff being at GUI rate and not audio rate

I'm sure I don't fully understand how this works, but to me that sounds like it could be a very bad thing that ruins a lot of possibilities for the simple fact that Live is specifically programmed to make the GUI lowest priority so that audio doesn't drop out in a live setting

so if being able to create session automation using M4L is going to rely on GUI rate then it could be essentially useless in this context

I really hope I'm just misunderstanding the implications of that....