Bitwig Plug-In Crash Protection

[fisto]

just saw this vid on createdigitalmusic.com

http://youtu.be/qwekCqQT-t8

looks very nice how they done it. Maybe the abes could do someting like this in Live 9

[xzusa8ky]

just saw this vid on createdigitalmusic.com

http://youtu.be/qwekCqQT-t8

looks very nice how they done it. Maybe the abes could do someting like this in Live 9

Dream On! I did mention this so many times, but Ableton dont implent something that the users want! Get used to it! Thats Ableton!

[fisto]

well, somehow I was very optimistic about a "change" @the Abes's HQ

[crumhorn]

Surely the inter process communication overhead involved in passing around all that audio must hit performance hard - particularly if you want to use a small plugin buffer.

If you have a plug in that crashes why keep it in your setup. Even if you are protected from an application crash it's still not usable.

[Angstrom]

I'm sure that resource consumption is higher, but who knows - perhaps you can choose to activate it, or not.

You notice that it has a bitbridge to load 32 bit plugins (into the 64 bit app). Bitbridges aren't computationally free either.

there's trade-offs to everything.

[crumhorn]

I suppose as processors get faster it becomes possible to implement things that would have been impractical just a few years ago.

[Angstrom]

I guess if you are taking it on stage, you will know ahead of time if the particular set is within your resource limits, so that is a known variable to the user ... The Crashy plugin however could come as a real surprise.
So balancing the two would tend to favour offering a resource overhead in favour of a more recoverable Live performance. We can factor in a resource overhead.

Who hasn't felt that special thrill of their computer taking a noisy shit and dying spectacularly in front of a crowd?
Oh, that's a special moment.

[friend_kami]

I guess if you are taking it on stage, you will know ahead of time if the particular set is within your resource limits, so that is a known variable to the user ... The Crashy plugin however could come as a real surprise.
So balancing the two would tend to favour offering a resource overhead in favour of a more recoverable Live performance. We can factor in a resource overhead.

Who hasn't felt that special thrill of their computer taking a noisy shit and dying spectacularly in front of a crowd?
Oh, that's a special moment.

that's when you always have a mic and some circuitbent pedals that you scream into and tweak furiously until your computer is up and running again

[H20nly]

so the DAW manufacturers and user's processor take on the responsibility for shitty plugins?

jebus, someone burn down Computer Music headquarters STAT!

[kent_sandvik]

Surely the inter process communication overhead involved in passing around all that audio must hit performance hard - particularly if you want to use a small plugin buffer.

If you have a plug in that crashes why keep it in your setup. Even if you are protected from an application crash it's still not usable.

The 32-bit bridge to plug-in process in Logic works really well with small buffer sizes. Computers are fast today.

The problem is not a constantly crashing plug-in, it's a plug-in that crashes occasionally. Especially nasty if you DJ.

Anyway, the technology to stream from another process is nothing new, Jack has this implemented. Most likely a must checkbox item with most DAWs next year.