Using Terminal to start Ableton Live without bug reporting.

Configure and optimize you computer for Audio.
RELATED
PRODUCTS

Post

Hi

I am desperate to bypass the Ableton crash report as it is wasting a lot of my time and breaking my creative flow.

The following thread on the ableton forum gives a sneaky hack for bypassing it using a DOS script on PC:

https://forum.ableton.com/viewtopic.php?f=4&t=161743

Does anybody know how I might do something similar for OSX using the terminal?

You would be saving me hours of lost time a month and I'm sure others would benefit too.

Huge thanks to anyone that is able to help :)

Cheers

Scorb

Post

I think you need to find out whats causing the crash. Its probably a rogue plugin.

Post

I agree but 9 times out of ten I am not crashing, let me explain better.

Live is just so damn sluggish at opening and closing these days that it is actually quicker for me to force quit and restart Ableton than to use it's close command. I kid you not! I timed it today and it took a shade under 5 minutes just to close a set. And that was after a save!

Now, force quitting is treated just like a crash, even though I saved before force quitting. If I could disable the bug report then this workaround would be even quicker (a lot quicker actually). In Live 9 the problem has got even worse with both opening Live, closing sets and quitting the program. To make matters worse, the GUI hangs for an additional 10-30 seconds after loading before the crash screen even appears. I am left watching a spinning beachball and am locked out of the GUI. This does NOT happen in Live 8.

So you see my problem, I am not actually trying to recover from crashes, I am deliberately force quitting because it is faster than closing live using quit.

Being able to disable the crash report would go someway to making this less than ideal situation more bearable.

I looked in the crash folder today and one day last week I "crashed" 21 times. So by my reckoning I am losing at least 25 minutes a day to this which adds up over the course of a month.

I have simply had enough of it and desperately want to minimise this wasted time.

Cheers

Scorb
Last edited by djscorb on Sun Apr 21, 2013 11:00 pm, edited 1 time in total.

Post

djscorb wrote:I looked in the crash folder today and one day last week I "crashed" 21 times. So by my reckoning I am losing at least 25 minutes a day to this which adds up over the course of a month.

I have simply had enough of it and desperately want to minimise this wasted time.

Cheers

Scorb
Maybe you should use 8. Seriously. The Abe's always take a little while to work out the kinks in a new version. If you don't have the time to help them beta test then stay with the older version until it looks like the coast is clear.

Post

I am using 8 still for all current projects ;)

I am just dipping my toe into Live 9 when I have a bit of spare time so that I am familar with it for when the time does come to swap over. It's nice to explore the new features too!

Anyway, the problem is still manifest in Live 8 (live 9 simply adds 10 to 30
seconds to the crash screen) so I still very much want to alleviate the waiting as much as possible in 8.

It might be that I can keep a shortcut to the CrashDetection.cfg file on my desktop so that after force quitting I can quickly navigate to it and delete it by hand before relaunching live. Would be nice to have a script style workaround for ease of use is all.

I wish I could just untick a box in prefs or that Live would close instantly after a save like Logic does :(

Cheers

Scorb

Post

djscorb wrote:Hi

I am desperate to bypass the Ableton crash report as it is wasting a lot of my time and breaking my creative flow.

The following thread on the ableton forum gives a sneaky hack for bypassing it using a DOS script on PC:

https://forum.ableton.com/viewtopic.php?f=4&t=161743
There's nothing especially clever about that script. I'm pretty sure that you could even put the script on your desktop and give it an icon. Presuming that crash reporting is done the same way in osx, all you need to do is find the location of the .cfg file that they are talking about and use the same procedure to launch the app.

The script is two lines.

Line one, remove the .cfg file

rm /path/to/cfgfilename

Line two, launch the app

open /path/to/ableton.app

Be careful here if you don't know what you're doing. rm is a command that shouldn't be used without some understanding, although if you specify a full and specific path the risk is low.

Bottom line, don't whine to me if you screw up your system, I write scripts like this every day but I know where problems can happen and, unfortunately, I can't tell you in advance everything that's risky, so, use at your own risk.

Note: There are a few other things necessary to create a script in OSX. I've left those off here but basically you have to give the script execute permission. It's easy enough, I'm sure that someone will give you the specific steps after they add details to my general recipe.

Post

Hey Ghettosynth

Thanks for taking the time :)

I will try firstly to see if deleting this cfg file manually after force quitting helps at all with the speed of recovery. If so then I will read up a bit on the execute permissions or check back here in case somebody has been kind enough to add any advice before trying it out.

Cheers again and I'll report back any findings.

Scorb

Post

djscorb wrote:Hey Ghettosynth

Thanks for taking the time :)

I will try firstly to see if deleting this cfg file manually after force quitting helps at all with the speed of recovery. If so then I will read up a bit on the execute permissions or check back here in case somebody has been kind enough to add any advice before trying it out.

Cheers again and I'll report back any findings.

Scorb
That's a good approach. Make sure that it's doing what you need it to do manually, then automate it.

Post

Ok!

I have not got any work done today so far as I wanted to do some tests about Live 8's and Live 9's opening, closing and crash recovery times. The results are quite interesting.

Rather than posting the results for every test I have done I will summarise my findings For the first set of tests and then give the results for my last completed project. :)

I used Ableton Live 8.3.4 32 Bit and Live 9.0.2 32 Bit on OSX 10.6.8 Snow Leopard

Live 8
-------

Set A - Firstly I created a fresh set with no audio or automation in it whatsoever. 16 Audio tracks with a Live Saturator, EQ and compressor on each. Then I added 16 instances of Zebra CM with a live EQ and comp after each. Live 8 used 9% CPU for this set. It took 4 seconds to load up, the project took a further 8 seconds to open and then 8 seconds to close: Total 24 seconds. Great

Set B - Next I created a similar set but replaced the Live EQs and compressors with EQuality (Set to digital+ mode with all bands and 24dB filters on and set to be off their default values) and Compassion (with British 1 Mod loaded). Live 8 used 43% CPU for this set. It opened in 4 seconds, the set opened in 19 seconds and closed in 52 seconds. Total 1:15. Not bad.

Live 9
------

Set A - The same set as for 8 but created in Live 9. Live 9 took 12 seconds to load, the project another 13 and then 13 to close again: Total 39 seconds. Good.

Set B - The same set as for 8 created in Live 9. Live 9 took 12 seconds to open, the project took another 20 and another 54 to close. Total 1:26. Starting to feel a bit slow!

Real world Set
-------------

Now, When I opened my last completed project which takes 60% CPU in 8 and 63% CPU in 9 it starts to get sluggish. I saved the set separately in Live 9's format before doing the test so that no additional converting was skewing the results for 9.

In Live 8:
----------

Opening Live takes 4 seconds, opening the project a further 37 seconds and a whopping 1:18 to close. Total 1:59. However, force quitting and choosing to recover takes only 39 seconds. A huge saving over using the close command and reopening Live followed by reopening the set.

This means in order to close this set and start a fresh set takes 1:22.

However, if I force quit and choose no at the crash recovery dialog I can be back with a fresh set in front of me in 10 seconds, saving 1:11 !

In Live 9:
----------

In Live 9 the problem gets a little worse. The total time to open live, the project and to close it again is a massive 2:56. Using force quit and choosing to recover the set takes only 1:02. This means that closing live the "proper way" takes three times as long as my workaround. Force quitting and choosing no to recovery gets me to a fresh set in just 25 seconds vs 2:04, nearly 5 times faster.


So, as you can see, using force quit and recovering versus Live's close and open commands is up to 3 times faster in this instance, saving me 2 minutes on this project alone every time I open it. When you think about how many projects get opened and closed in a day this is seriously mounting up.

Furthermore, if I delete the CrashDetection.cfg after force quitting in Live 9, it allowed me to be back with a blank set in front of me in just 16 seconds! This is saving me over 2 minutes of pointless waiting!


In Live 8 there is little to no difference whether I force quit and delete the cfg file versus just force quitting, so Live 9 is hanging for at least an extra 10 seconds with it's bug report / crash recovery compared to 8 for this set.

As i mentioned elsewhere one set last week that must have been particularly resource hungry took over 4 and a half minutes to close after a save! I dread to think how much longer it would have been for Live 9!

Conclusion? Force quitting Live rather than closing it is definitely the way to go.

It would be interesting to know why Live sets open so much faster than they close? How can that be? Logic closes instantly after a save so I know it should be possible for Live to do the same. How can asking a program to stop doing anything take longer than asking it to do something intensive? Baffling!

Any thoughts anybody?

Cheers

Scorb

Post

Just some ideas:

To monitor changes to Live's log (which might give you more clues), in Terminal, enter:

Code: Select all

tail -f /Users/*/Library/Preferences/Ableton/*/Log.txt
To disable the usage of OS notifications for files that have changed to the 'indexer', add this line in Options.txt:

Code: Select all

-_IndexerOsEventsFlags=Disabled

Post

Hi Ch00rD :)

I tried the first one (obviously I replaced the asterix with my username and Live 9.0.2 respectively. However, it says no such file or directory.

I even located and opened manually the Log.txt in safari and copied the address to ensure I got the path 100% accurate. Do I need an underscore or something else instead of a space in the name; "Live 9.0.2" or something because I've tried both a space and underscore and still no joy.

Thanks for any hints :)

Scorb

Post

Eh, oops, yeah, that could have been a bit clearer, sorry. :oops:

You should use the Live version number, but escape the whitespace with a backslash, e.g.:

Code: Select all

tail -f ~/Library/Preferences/Ableton/Live\ 8.4.1b2/Log.txt
(using the tilde is the same as the current user, so that should work for you as well.)

Post

Brilliant, thanks!:)

I will investigate further.

Also I am just going to repeat the last test (my latest completed project) on my Macbook as well just to see if it acts differently. I had a few Memory deallocation errors recently on teh studio machine so am wondering if one of my sticks of RAM is going bad. If the closing is taking longer than opening on my macbook as well then I know that it is just live and not my machine that is causing the slow closing.

Cheers

Scorb

Post

djscorb wrote:[...] I had a few Memory deallocation errors recently on teh studio machine so am wondering if one of my sticks of RAM is going bad. If the closing is taking longer than opening on my macbook as well then I know that it is just live and not my machine that is causing the slow closing. [...]
Oh, another wild guess: do you still have plug-in windows open when quitting the app? Perhaps try closing them first to see if that makes a difference; Live apparently has a bug with deallocating plug-in windows when deleting them; that could also be an issue with closing the app, perhaps.

Post

Hey Ch00rD

Yes I made sure of that after reading it somewhere yesterday ;)

ok, so an update.

This is the line of code in the log.txt that Live is hanging on when waiting to close. It's the same for both my desktop and Macbook so I can rule out bad memory and hardware I think.

761073 ms. Audio time allocations: EventBuffering: Capacity/Used/Failures: 26214/54/0

I just repeated my earlier test on my trusty old White Macbook (2.16Ghz Core2Duo with 2Gb RAM).

Live 9 takes a whopping 1:05 to open a blank set on the Macbook and the project that was using 63% on Live's CPU meter on my 2.6 Ghz QuadCore 4Gb Ram studio Mac, used 329% and took an incredible 2:48 seconds to load and an even more ridiculous 3:20 just to close.

I think I can rule out any problem with my studio machine!

Can anyone else confirm that a Live set takes longer to close than to open using third party plugins and over 40 - 50% on Live's CPU load meter? Mac or PC, would be interesting to know if there's any difference. I was using Audio Units but have no idea at this point whether using VST would be better or worse.

I mainly use DMG, Valhalla, Audio Damage and Voxengo plugins and very little else, at least in the project I have tested this with today.

It just seems ridiculous that any program should take so long to close after the project has already been saved :(

Cheers for any feedback and comments

Scorb

Post Reply

Return to “Computer Setup and System Configuration”