Ableton Forum

and for the record, i am not angry at you nico or anyone else from the support, you guys are incredible helpful and always try to sort out the shit immediately.
but i wonder how you can support the developers and programmers with their clear failure.

besides how come that it was not such a big issue prior to 8?

what changed? did something changed? (in respect to internal plugin handling, i mean) if so, well change it back. prior 8 it was all tutti frutti.

esky wrote:

i am super angry now, i never thought you would dare to point the finger on others, when the whole rest of the audio world can deal with plugs, except you.

Hey Axel, calm down a little, it's to early this day to be so upset. Are you sure that is always the case ? I remember quite well that when i was on Mac and Logic there were plugins that fail the AU validation of Logic. Then the plug programmers came up with an update to solve it. So Nicos statement for me is comprehensible...

nope it's not!

of course is logic clever and has a AU validation to ensure proper function... well, ableton do the same.

besides, i forced many AUs through the validation (you can easy do that) and they always still work perfectly fine and never caused a logic crash, neither in peak or cubase or PT which i all used a lot next to DP and others, never a single plug caused a crash, as i said, if at all, the plug itself would simply not function properly or cause white noise, like the northpole filter during logic 4 times... as an example i remember, but never a plug brought a host completely to it's knees, i seriously never heard of it either and i am pretty much daily involved with either using audio programs myself or being surrounded by other users...

besides, even if i am all wrong...

then why the hell not implementing something like a AU validation as well?, or dropping the plugin support?, or changing the way it handles plugs?, or whatever it takes to ensure it's working? instead of pointing the finger onto others?

this 3rd party plug in business really triggered extreme anger, yes. what a fucking bullshit.

Axel, you seem to misunderstand my posts. I am not pretending that Live 8 has no self-made plugin problems. We had (and probably still have) bugs in Live 8 which are completely on our side. Having said that, there are also lots of plugins which have bugs in their own code. Saying that all plugins out there are perfectly programmed would be a bit naive, don't you think so?

As for the two plugin problems that you mentioned: I'm not sure which exact Live version you're currenly using, but we have introduced an admittingly very ugly bug in 8.1.1 where several AU plugins would crash in Live. That's clearly our mistake, but this got fixed in one of the 8.1.2 betas. I'd encourage you to install the 8.1.3 release candidate and check if that solves the problems for you. If not, it would be nice if you could send us your crashlogs.

what changed? did something changed? (in respect to internal plugin handling, i mean) if so, well change it back. prior 8 it was all tutti frutti.

The big change in Live 8 (plugin-wise) was the new parameter handling, i.e. the configure mode that we implemented to overcome the old 128 parameter limit.

i still use 8.0.9 and will so untill i see....

ilia wrote: Hi Nico,

I am wondering if you guys have accumulated information as to which plugins require a buffer of particular size to work properly and if you could make this information public? I tend to work with minimal buffer sizes (32 samples for plugins, 48-64 samples audio), since I like to track with plugins, but I've noticed that certain VSTs will not function properly until I increase the plugin buffer. Sometimes this does not manifest itself until Live crashes. Would be great to have detailed list of "rogue" plugins wrt small buffers. Would probably help beta testing as well.

Hi Ilia, the plugin buffer problem that I mentioned earlier affects plugins from a specific manufacturer that I'm not going to name here. If you encounter frequent crashes, especially when running a loop in the Arrangement View, scrubbing through the Arrangement's playback position, hitting start/stop or changing presets in the plugin itself, contact us by email and I'll send you more information.

Apart from that, too small plugin buffers will usually only cause a higher CPU load, but may also lead to dropouts if the buffer is too small. I'd keep the plugin buffer at 64 samples minimum. Another important fact when setting the plugin buffer is that it must be divisible by the audio buffer (or vice versa), e.g. the plugin buffer should be EXACTLY a halve, a third, a quarter, etc. of the audio buffer, so that the buffers can render "in sync". Otherwise you can get dropouts (plugin buffer is smaller than the audio buffer) or you would waste CPU cycles (plugin buffer is higher than the audio buffer). The audio buffer itself should ideally be a power-of-two value, i.e. 64, 128, 256, 512, etc. samples.

Best,
Nico

Seems to me the major difference in Live 8 is this new embedded M4L collaboration that seems to me could change some internal workings. The biggest slew of problems came up when the M4L version came out. At least from what I read.

A public announcement of suspending development of new features until 'quality' is up to par, pretty much makes the post about some
people having no issues with Live 8 a moot point. That Live 8 is the most unstable release yet is without a doubt, you do not suspend further development
when you have a solid release, period, raving fanboys here have posted crash rant threads etc. that was just in bad taste IMO.

Third party plug ins are always a problem stability wise.
Live 8 seems more prone to crashing plug ins, instead of plug ins crashing Live 8.
That, is a problem.

Seven4Lyfe!

[nis] wrote:Axel, you seem to misunderstand my posts. I am not pretending that Live 8 has no self-made plugin problems. We had (and probably still have) bugs in Live 8 which are completely on our side. Having said that, there are also lots of plugins which have bugs in their own code. Saying that all plugins out there are perfectly programmed would be a bit naive, don't you think so?

As for the two plugin problems that you mentioned: I'm not sure which exact Live version you're currenly using, but we have introduced an admittingly very ugly bug in 8.1.1 where several AU plugins would crash in Live. That's clearly our mistake, but this got fixed in one of the 8.1.2 betas. I'd encourage you to install the 8.1.3 release candidate and check if that solves the problems for you. If not, it would be nice if you could send us your crashlogs.

what changed? did something changed? (in respect to internal plugin handling, i mean) if so, well change it back. prior 8 it was all tutti frutti.

The big change in Live 8 (plugin-wise) was the new parameter handling, i.e. the configure mode that we implemented to overcome the old 128 parameter limit.

i did yesterday downloaded 8.1.3b and 10.6.3... i will see...

and yes i totally agree that there are plenty of dodgy plugs around, of course!, but my point is that it's funny, that for instance even if you force plugs through the validation, they work flawlessly, even some cracked plugs (waves and NIs) i used years ago... in the meantime i only have legal plugs on my machine and nothing that exotic, AAS, Bias, NI, etc... not even talking freebees, just common known quality suppliers that cost a lot of money, too. and all those work as VSTs for example within peak as well, even within the Vbox... no problems, never had since over a decade...

and not in live 5.2... until 8...

if we suffer because of the 128 parameter limit, then i say change it back for gawds sake.

[nis] wrote: Apart from that, too small plugin buffers will usually only cause a higher CPU load, but may also lead to dropouts if the buffer is too small. I'd keep the plugin buffer at 64 samples minimum. Another important fact when setting the plugin buffer is that it must be divisible by the audio buffer (or vice versa), e.g. the plugin buffer should be EXACTLY a halve, a third, a quarter, etc. of the audio buffer, so that the buffers can render "in sync". Otherwise you can get dropouts (plugin buffer is smaller than the audio buffer) or you would waste CPU cycles (plugin buffer is higher than the audio buffer). The audio buffer itself should ideally be a power-of-two value, i.e. 64, 128, 256, 512, etc. samples.

Best,
Nico

wow..5 sentences for what is spread in the manual with slight condradictions over 10 pages and external lessons without actualy even mentioning something like rendering buffers in sync..


maybe you should write the manual?




and one question to the hopefully former broken state of L8..

how do plugs interfear with event placement of midi and audio events, reaction to external timecode or wrong executed functions in arrange? or are you saying that only the crashbugs was plug related while the other dont qualified to call L8 broken?
Around 50% of your mac users seemed to have/had no problems... but is half broken not broken aswell? or the other way around..half ok is still ok?..

its nice that now all your bugs are plug related...and too bad that L7 was able to deal with the bad plugs only by accident, but in the beginning of the year the bigger problems was something else...

i had long periods with L8 and all external plugs switched off...

However.. i think its good that the quality stickker is off... promisses dont make anything better and i dont want to be reminded all the time to the struggle of the past..

When ther is now a state wher the basics run ok and only this or that software combi has issues there are workarounds ..

But..

could you please name dangerous candidates? it dont matters if its there code or yours that causing the missalignments..

We users want to know about potential risks before going on stage..

ANd could the other users please dont fall into a silence contacting support startegy again?

as long only support knows what possible issues are out there the users are in higher danger of deciding for the wrong tools for a life show...


so plug in related crashes of any kind are better postetd in the forum as a warning..at least as long there are still issues..

I for example just have the plan to replace my fx rack and analog desk for wight and space reasons with reaktor in stand alone or plug.. and do all the pitch trasnposinf and reverb..delayfx on stage with reaktor..
because it gives me the possebility to modell the lexicon and spx fx somehow...


Question..

Is Reaktor a risky plug wright now? before i start all the programming aktion that ultimatly will lead to a crash with live on stage than, i would like to recieve a warning in case there are reaktor issues...

If so i would like to get that info in the forum so that all others know aswell..

I don't see what's the big deal.. just another beta..

BTW... are device racks / presets I save also NOT backwards compatible ?

nathannn wrote:

nebulae wrote:

carlosjhzapien wrote:a whole bunch of shit

cool, but did Live hold up through this epic trainwreck? http://www.youtube.com/watch?v=rzod3CotfAg

this video is extremely funny until you realize the guy is serious..... then its like awwww lets give him some change.

the guy is great..he probly has more music in his little tow than you in your fancy laptop

SubFunk wrote:

Tone Deft wrote:^ooooh good call.

which plug-ins are crashing for you SubFunk?

oh, and thanks to the people that beta tested this release, I didn't.
/ducks

AU versions of the AAS bundle for instance and bias plugs (also AU) that work and worked fine in general in other hosts i use in the last 10 years.

It just works (tm)

7 pages of whining & not a single person saying they installed the RC and it worked/didn't work...

djsynchro wrote:7 pages of whining & not a single person saying they installed the RC and it worked/didn't work...

One "serious error bla bla" when closing a set.
And stupid NI Massive crapping out once. (XP user)

already crashed on me once...
on the up side.. it's quicker/more responsive than 8.1.1