The crashing is back, pulling my teeth. Need to vent!

To put it brief:
to best of my ability, I've now tracked it down to EQuick.
it has to be it.

i removed all its instances from the project, and it started working way better: i could save, copy sequences etc.
i did a sh1tl0ad of that for a while and only get a few crashes, which i think were "normal" (considering the Ren, eh eh).

then i loaded a few instances of EQuick again, and im getting crashes so easily again.

just sent a crash report to Dave of DMG; he said he's interested.
J Sandeen said crash reports aren't much of use to them. Uh.

Fanu wrote:J Sandeen said crash reports aren't much of use to them. Uh.

That's odd, one would think BETATESTER(S) should know about this, rather than suggest people to send them to Akai in the first place.


Back to topic: Glad you found the reason. I'd suggest you bounce to audio whenever you can to get rid of plugins. Seems like they're the one major thing causing Ren to crash.

Yeah.
To quote J Sandeen:
"The crash reports don't help as much as the steps to reproducing a crash or bug. "

As for the 60+ crashes I had today, I could only describe it like "I made music. I made music just like I always do. At some point, with no obvious changes I'm in a crash hell – when I save and copy sequences it always crashes. Can you reproduce that?"
So I'd quess that a crash report tells people way more than user's words where you just don't know what causes the crash, especially if it's just saving a project, copying a sequence.
I understand if stuff like "I just added this megasynth" might give some clue into the problem, but often times, we can't say what it is.

Oh hell yeah!
As soon as I was writing this, Dave of DMG – who had been going thru the crash reports I sent 30 mins ago – hit me up via email and he says he can already see EQuick is doing the crashing in some of the crash cases and he'll be looking into it.
Now THIS is how it's supposed to be done...Akai devs....take heed!

To quote J Sandeen:
"The crash reports don't help as much as the steps to reproducing a crash or bug. "

Well, that's not saying 'crash reports are not useful' (as was first suggested) - that's saying 'if you can work out a step by step reproduction, it would be more beneficial than a crash report'.

A crash report is clearly of benefit to the devs in the case of a crash that has no clear reproducible steps. If you cannot reproduce a bug, then you should send in as much information as possible to help the devs work out the possible culprit.

I'm glad you've narrowed down the culprit. Hang in there man. It'll all pay off!

MPC-Tutor wrote:

To quote J Sandeen:
"The crash reports don't help as much as the steps to reproducing a crash or bug. "

Well, that's not saying 'crash reports are not useful' (as was first suggested) - that's saying 'if you can work out a step by step reproduction, it would be more beneficial than a crash report'.

Yes, but still, I did get the feeling that crash reports won't be looked at: there was no comment as to the crash reports I did send him. He ignored them and said:
"I can do the same thing I did last time you were getting crashing when saving, if you send the session. I just loaded all the content into a new project, then saved it as another project and project content name. That seemed to set you straight last time."

That to me doesn't sound like "OK, we'll dive into the crash report data if you can't reproduce a problem". I could reproduce / explain the problem ten times in a row but not say what actually caused it, and that could only be seen in a crash report.

I'm only wondering how strong the dev / tester team is. And I don't know the first thing about coding but I'd think they need to go in on the crash report if that's all you get. Also, eliminating a problem from one's set may help this one time but the bug will be faced by others.

From what I've seen on the Akai community site, J Sandeen is front end tech support, he's not a dev, so he's not going to be able to comment specifically on what happened with your crash report - it gets submitted to the devs and added to the system to be looked at when the time can be found.

Dave has gotten someone at Akai to log the crashes and added his breakdown from his code, as he put it.

He took a look at the crash logs I sent and said that one of the crashes is because the EQ is "trying to save its settings. In fact the crash is inside a library that's rock-solid that's compiled in, so this suggests some kind of memory corruption.
Still not clear whether this is EQuick or something else. EQuick is a good candidate for revealing this kind of bug, because it does use a fair bit of memory."

I hope something – anything – comes out of this. Maybe the people at Akai will learn some stuff about the Ren.

I've heard a lot of praise about Dave @ DMG and this story so far confirms he's worth it.

If you're using EQuick, keep all this in mind.

The sadness madness continues

I thought it worked for a while. Was enjoying making beats for a while this morning.
Then it's crashing upon save again. Tried removing each plug to see if it has an effect. Nope. Finally removed all plugins – it's still crashing when I save.

Updated OS X in vain (Mountain Lion feels slower than Snow Leopard...really can't be arsed to restore a backup...don't want to spend any more time for this).
MPC reinstall didn't work.

This is f*cking madness. This has to be fixed. I want to make music again.
PS: Picking up an old E-MU sampler today...f*ck the software for a while...can't take the ballache caused by constant crashing.

Try to update to mac os 10.8.3 Mountain Lion, it should be much more reactive and faster than Lion.

With some tweak/optimization it feels really Snow Leopard like.

And man you shouldnt sell the jjos 2500...no matter what is the only mpc i would never sell.

you said you have live which is the most creative DAW around
just run the ren standalone along with live. let live do all the heavy lifting sample
and effects wise use the ren just to do drums and triggering via the clips in tracks and also samples in drum racks
i do this, have two monitors set up ren in one screen ableton in the other works like a dream. get on it best of both till you / they whatever the problem is gets sorted out

Danny wrote:you said you have live which is the most creative DAW around
just run the ren standalone along with live. let live do all the heavy lifting sample
and effects wise use the ren just to do drums and triggering via the clips in tracks and also samples in drum racks
i do this, have two monitors set up ren in one screen ableton in the other works like a dream. get on it best of both till you / they whatever the problem is gets sorted out

That's a waste of time and CPU cycles, you can't send the audio to Ableton because the mpc software des not have rewire, of course you can use soundflower which is just crap.
So you come up with a cluttered workflow...

Better to do all your work in the mpc and after bounce stuff and import in Ableton Live.

Or even better just use the mpc as it is, or Live with an mpd32.

Using the mpc software just for drum duties without effect and without rewire is not worth, at this conditions, imho the drum rack is much more well integrated into Ableton Live.

i offered an alternative to help the guy out but you know best i guess
i only been using live since version 5 so i probably don't know that much about it

the thing that tells me that you have no idea what your talking about is when you
mentioned this.

"can't send the audio to Ableton because the mpc software des not have rewire, of course you can use soundflower which is just ****."

anyway whatever. you carry, on maybe you can help the guy out. i obviously
don't know jack shit

Are you saving straight to ssd? maybe the ssd drive is doing some funny shit when trying to write.. When i was going to invest in external ssds for a new silent sturdier solution, while doing reserch the common agreement was that they read awsome but write terrible and unreliable..(especially when the drive started to fill up)

^^ cuz true.