DP7 Crashing - Bundles related? (Resolved!)

[superjeezus]

My first task with DP7 is to rebuild my main orchestral/master template with a large Vienna Ensemble Pro palate. So I have lots of MIDI channels, and some bundles set up with instruments routing to several aux tracks. The instrument tracks are all in a v-rack, and each instrument is an instance of the Vienna Ensemble Pro plugin.

DP7 is constantly crashing when I enable/disable aux tracks, or change the outputs of MIDI tracks.

So basically, here is what I did:

1. Created a new empty DP7 project
2. Imported my VI v-rack and main sequence chunks from a previous template, including bundles. This includes several aux tracks in the main Tracks Overview window, with MIDI, Audio, and Aux tracks organized in folders.
3. Renamed the VI's in the v-rack as needed
4. Renamed and re-assigned bundles as needed.
5. Re-assigned any tracks in the T.O. window as needed.

Through this process, DP crashes after adjusting a few MIDI track outputs, enabling/disabling Aux tracks, or assigning Bundles in the Bundles window. The only VI I have instantiated is several instances of the Vienna Ensemble Pro plugin. I also have Bidule rewired to DP, and have aux tracks set up in the T.O. to handle the Bidule Rewire audio inputs.

I spent the last year working in Logic because of the instability of DP6. I jumped on DP7 based on some of the glowing initial reports, hopeful that it would be stable. Fingers crossed that someone can see a problem with what I am doing and offer a possible solution. I really don't want to go back to Logic! DP is so much deeper for scoring and composing in general.

Ideas, anyone?

As a side note, I noticed that MOTU seems to have sorted out the numbering issues that I used to see in the Bundles window in 6.02. This is very cool. I am wondering if renaming the bundles is causing some of these problems?

[charlesparente]

What does the crash log say?
Does the crashed thread [usually listed at the top] point to VE Pro?

Your probably not going to want to hear this, but what I would do is:

1) rebuild everything from scratch, in your new DP file. Don't import anything. Yes, I know it's awful! But it helps to eliminate potential causes of the trouble.

2) Try the routing to/from VE Pro [MIDI and aux tracks] without using a vrack first. Make sure the routing is correct between VE Pro and DP.

In its default settings, VE Pro publishes 32 audio output channels per instance, visible in the Instrument bundles window after you insert VE Pro as a plugin, so if you're using VE Pro for ALL of your sounds, you might not need to create any extra bundles.

3) If you can do this without crashes, then try the VE Pro routing using a vrack.

Since VE Pro allows you to save all of your settings/loaded samples for recall, [and even keep them loaded when you switch DP projects] you might find that the vrack implementation not needed when using VE Pro.

But if you're using multiple sequences per DP project file, I could see how a vrack would be helpful.
------------------------------

Many users here are getting started with VE Pro on a single computer setup, including me, and information is flowing fast! There are already some good active threads on VE Pro.

Also keep an eye on VSL's forum. Lots of good info there.
Like the recent mention of the 8 VE Pro instance limit when used in localhost mode.

Good luck,
Charles

[superjeezus]

Hey Charles, thanks for the reply and good suggestions.

Yeah, I have been trying to avoid re-creating the whole thing from scratch, but I just may need to do it. Yikes.

I really do need the V-rack for instruments because as you guessed, I need to do several sequences within one project. Yeah, with VE Pro it is easier to move to completely different project files, but still...Chunks are one of the things I like most about DP.

And I have been following the discussions and threads about VE Pro here and on VSL's site. It is groundbreaking software for sure, and it will be completely life altering if I can stabilize my system!

I have some unexpected extra time today, so I am cloning my DAW partition and will install 10.6. Who knows, maybe that will make a difference. The Stillwell plugs were the only things holding me back, and now he has some working betas.

[Shooshie]

If the crashes are irrational, and rebuilding/reinstalling doesn't seem to help, it may well be due to the Snow Leopard font issue. It could have to do with DP calling a certain font on your drive that Snow Leopard doesn't like. I don't know which fonts DP calls, but the ones in question are Type1 Postscript fonts. You may have duplicate fonts, or worse, fonts that use the same name, but are completely different kinds of fonts. If you go through your fonts and have Font Book resolve duplicates, make sure it is not choosing the Type1 fonts over newer ones like OpenType. I'm not even sure if OpenType fonts are clean. It would be better to do a Google search on Snow Leopard and Postscript Type 1 fonts crashing. You'll get tons of hits, and most of them will be forum posts by angry desktop publishers and designers. Filter through the angst, and you may find good instructions by people who have gotten to the bottom of this.

I hope I am not sending you on a wild-goose chase, but several people have reported bizarre crashing, and at least some have found that fixing their fonts stopped the crashing.

Shooshie

[superjeezus]

If the crashes are irrational, and rebuilding/reinstalling doesn't seem to help, it may well be due to the Snow Leopard font issue.

Hey Shoosh, thanks for the input. But this started happening in 10.5.8, so I don't think it's the Snow Leopard font issue.

I did clone my system today and upgraded to 10.6.1, and got started on rebuilding my master template. Unfortunately, I am seeing the same exact behavior. When I get to the point in the new template where I am creating several Aux tracks in the T.O., DP7 starts crashing like crazy. This is after I have set up my Instrument V-rack and Bundles.

At this point I am going to keep playing with it to see if I can narrow it down to something more specific.

[superjeezus]

Ok, I have reduced this problem down to some specific steps that consistently recreate the problem on my system. If anyone out there can give this a try, that would be very cool.

1. Create a new empty DP7 project
2. Create a V-rack with 15 Instrument tracks
3. Instantiate a 3rd party Audio Unit VI on the first Instrument track
4. Copy the same VI across all Instrument tracks
5. Create a bus (in Bundles) for each instrument track
6. Assign the busses to the outputs of the instrument tracks
7. Create several aux tracks in the Track Overview (30-40 aux tracks)
8. Change inputs/outputs/enable status of aux tracks until DP crashes

On my system it usually takes less than a minute of clicking around for DP to crash. Fewer VI's will still crash DP, but it may take longer. It doesn't matter whether I use the V-rack or not, DP still crashes. I tested this with Vienna Ensemble Pro and Kontakt 3.5 plugs, no difference. DP does not crash unless I assign outputs of the Instrument channels to the busses created in the Bundles window.

[superjeezus]

I just reproduced the crash several times on a MacBook pro:

Core Duo 2.16
2GB RAM
10.4.11
DP7

I used Kontakt 2 as the plug, with no samples loaded. I loaded less instances, due to the reduced horsepower of this machine. Was operating well within the machine's limits, yet crash after crash.



This is pretty standard routing stuff, I am surprised this wasn't discovered before release. I'm really biting my tongue right now, I don't want to go off on a rant...

[BobK]

As someone asked a few posts back, what do the crash logs say? If a third-party plug-is causing the crash, it would help to let the developer know about it.

Have you filed a Tech Link with MOTU?

[superjeezus]

As someone asked a few posts back, what do the crash logs say? If a third-party plug-is causing the crash, it would help to let the developer know about it.

Have you filed a Tech Link with MOTU?

Hey Bob, yes I managed to get a MOTU tech on the phone today and we have a tech link going. I did send him some crash logs, I can't really tell from them what the cause of the crashes are, but it doesn't look like it's caused by the VI's.

Hopefully we can get to the bottom of it, and I would be more than happy to find that it's something stupid I am doing. I really just want it to work. The fact that it happens on 2 different computers makes it seem like a DP7 thing; there aren't many similarities to those two computers, they are running different versions of OSX and they have different plugs and software installed on them. The two things they have in common are me as the operator and DP7.

[BobK]

If you don't already know this, here's what I've gleaned about reading crash logs:

The first group of info starts with the application that crashed; the second group starts with date/time (and includes OS version); and the third group starts with what kind of crash it was, and then says which thread number crashed. One of my recent examples: "Crashed Thread: 41"

So I scrolled way, way down till I got the details of thread 41:

Thread 41 Crashed:
0 com.audioease.Altiverb5.MAS 0x097c28e8 CFDManipulator::PrepareForSplitAndMix(float***, MissionThread*) + 3388
1 com.audioease.Altiverb5.MAS 0x097c2c70CFDManipulator::FDSplitAndMixNoIntermediateResult(float***, float***, MissionThread*) + 160
2 com.audioease.Altiverb5.MAS 0x097bd1a8 AltiverbProcess::MutingPartialReload(MissionThread*) + 1552
3 com.audioease.Altiverb5.MAS 0x097be830 AltiverbProcess::ReceiveMessage(WalkieTalkie*, long, void*) + 1432
4 com.audioease.Altiverb5.MAS 0x096ca750 MissionThread_mac::DoThreadProc() + 132
5 ...ple.CoreServices.CarbonCore 0x90931428 PrivateMPEntryPoint + 76
6 libSystem.B.dylib 0x9227a0c4 _pthread_start + 316

(Sorry- couldn't figure out how to get this to format correctly here). Notice that several lines start with 'com.audioease.Altiverb5.MAS'. I figured this meant that Altiverb was involved in the crash. I contacted the developer, AudioEase, and they confirmed this, and that there was indeed a bug which will be fixed in the next update.

I don't know what it means when it says thread 0 crashed.

But in this case, at least, it was clear. I imagine if the crash involved a third-party file that wasn't so clearly named, it might be harder to trace, but, as another example, in the case of Kontakt 2 Player, the crashed thread involved a file that included 'NI' in the name...

Hope this helps.

[superjeezus]

Hey Bob, thank you. Yes, I understand at least that much about the crash logs, and all I can see is that something with MIDI or the MOTU MAS AU wrapper may be part of the problem:

Thread 37 Crashed:
0 libSystem.B.dylib 0x94511c2e __semwait_signal_nocancel + 10
1 libSystem.B.dylib 0x94511b12 nanosleep$NOCANCEL$UNIX2003 + 166
2 libSystem.B.dylib 0x9458d5a6 usleep$NOCANCEL$UNIX2003 + 61
3 libSystem.B.dylib 0x945aebf1 __abort + 136
4 libSystem.B.dylib 0x945aec61 abort_report_np + 0
5 libstdc++.6.dylib 0x91135fda __gnu_cxx::__verbose_terminate_handler() + 433
6 libstdc++.6.dylib 0x9113417a __cxxabiv1::__terminate(void (*)()) + 10
7 libstdc++.6.dylib 0x911341ba __cxxabiv1::__unexpected(void (*)()) + 0
8 libstdc++.6.dylib 0x911342b8 __gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*) + 0
9 PerfError.dylib 0x0213433d MotuExceptionThrower::~MotuExceptionThrower() + 93
10 DPPart2.dylib 0x0118f4e9 WrappedMasRenderCache::MakeWritable(MasRenderCacheBuffer&, bool) + 91
11 PerfEngine.dylib 0x01c992bf PlayTrackAudioReader::Interleaver::OutOfOrderRead(void*, SampleCount, long) + 205
12 PerfEngine.dylib 0x01c91e02 MIDIPlaybackQueue::SendUpTo(Tick) + 14016
13 PerfEngine.dylib 0x01c71624 PerfAudioPlayTrack::GenerateAudio(PerfMutexLite::Lock&) + 256
14 PerfEngine.dylib 0x01c7176a PerfAudioPlayTrack::DoWork() + 130
15 PerfFoundation.dylib 0x0218b425 GetUnitTestRandomLong() + 191
16 libSystem.B.dylib 0x944d1f39 _pthread_start + 345
17 libSystem.B.dylib 0x944d1dbe thread_start + 34

So there are definitely some MOTU and MIDI processes going on in this thread, but I don't know how to decipher anything more specific than that. Like, what process actually crashed the thread?

[BobK]

Yup, that one is beyond me!

[charlesparente]

Ok, I have reduced this problem down to some specific steps that consistently recreate the problem on my system. If anyone out there can give this a try, that would be very cool.

1. Create a new empty DP7 project
2. Create a V-rack with 15 Instrument tracks
3. Instantiate a 3rd party Audio Unit VI on the first Instrument track
4. Copy the same VI across all Instrument tracks
5. Create a bus (in Bundles) for each instrument track
6. Assign the busses to the outputs of the instrument tracks
7. Create several aux tracks in the Track Overview (30-40 aux tracks)
8. Change inputs/outputs/enable status of aux tracks until DP crashes

Hi Superjeezus:

I just created a DP 7 project as you describe above and have not had any crashes.

But...

1) This is on my Macbook, [10.6.1, DP 7] with no 3rd party VI's installed. [Those are all on my studio MacPro.I just used DP's built-in instruments.

If I have time tomorrow I'll try it on my studio MacPro with 3rd party VIs. Since I'm rather new to DP this all helps me to learn the routing anyway...

2) I'm only using built-in audio on my Macbook, [and only stereo outs on my firewire interface on MacPro]
so there's no reason
for me to adjust the output of the aux tracks as you decribe in step 8. Everything outputs to a single hardware stereo output.

If your getting crashes trying to create submixes with auxes outputing to other auxes--I have not tried that yet,
but I see how that could be helpful at the mixing stage.

No problems toggling the enable status of auxes
or choosing different busses for aux input.

Good luck,
charles

[superjeezus]

Hey Charles, thanks for trying this out. I was able to crash DP using the default outputs, but.....

HOLD THE PHONE!

I think I have actually figured it out and solved the issue. I had updated my MOTU 424 drivers, all my plugs and VI's, and done everything else I could think of, but I neglected to check that I was running the most current version of.....the MOTU USB MIDI driver. And that driver was installed on both systems I tested.

Whether the update fixed something or the driver just needed to be reinstalled, it seems to have fixed the problem. I can't get DP7 to crash anymore. That's what I'm talkin 'bout, baby!!

Sorry if I wasted anyone's time on this. Thanks to everyone who replied.

I am absolutely thrilled DP7 is working for me now. I truly believe DP has the deepest and most intuitive feature set for composers and producers, hopefully it will continue to be stable as I put it through its paces over the next few weeks.