Strange DM Transport Issue

[JHTorch]

OK, over the last couple of weeks, we've been using the DM primarily as a control surface for Nuendo. With a couple of minor issues, I certainly prefer it to the Mackie Universal Controller. However, during this time period, I have experienced about 3 "blue screen of death" crashes and a couple more Nuendo "is not responding" crashes.

I will be working on a project in cycle (looping) mode and then I will hit stop on the DM; however, Nuendo will ignore the command and continue to play until I do a "forced" shut down of Nuendo. Oddly, the DM will continue to "play" in the sense that the LED above the play button is green and the time code window on the meter bridge is still happily rolling along. (I should note that the DM is set to be the MTC slave).

Anyone experience a similar issue? I've yet to do a thorough trouble shoot but I suspect that it is an MTC settings issue on the DM. Or potentially a USB bandwidth issue. Any thoughts? I'm running Win XP SP3. Not all of my USB ports are used but in addition to the DM, I have all of the following connected to my system's USB ports: Lynx Aurora 8; Novation Nocturn plugin controller; MOTU MIDI patchbay; keyboard and mouse. There have been no material updates or changes to my system except for a driver update to my video display adapter. (The problem started before the update).

 

[Drumstruck]

I have a similar "lock + DM timecode continuing issue" in my Reaper / Mac / DM4800 setup when Reaper is sync'd to the DM (minus the blue screen of course).

Occasionally a "force quit" and restart of Reaper will fix this - sometimes a reboot is required.

As a workaround I don't use the DM transport buttons when recording / looping and simply use the mouse.

 

[captdan]

I've had this problem several times over the past few years. It always happens if the transport is set in Loop mode, and if after many loop events I forget to disable Loop and - say - record a part - I run the risk of crashes.

I'm running Win7 with PT10, and I found when I added an extra 4megs of RAM, the issue occurred less often. And after loading up the Legacy IE1394 Win driver last year, the issue is now thankfully rare. But I'm still careful, because when PT wets the bed on a large session, it takes awhile to get it all back.

CaptDan

 

[JHTorch]

I have a similar "lock + DM timecode continuing issue" in my Reaper / Mac / DM4800 setup when Reaper is sync'd to the DM (minus the blue screen of course).

Occasionally a "force quit" and restart of Reaper will fix this - sometimes a reboot is required.

As a workaround I don't use the DM transport buttons when recording / looping and simply use the mouse.

Do you have the DM transmitting MTC to Reaper or the other way around? I take it that if you work only with the keyboard and mouse during a given session, you do not have any issues even if you use the DM's pan and fader controls?

I'm not sure why I've been getting the Blue Screen of Death. I assume that it concerns the DM's MTC issue. Before the DM I'd say it's been at least 3-4 years since I experienced a BSD problem. XP and Nuendo have been rock solid for me and hence my reluctance to switch to Win 7.

 

[JHTorch]

I've had this problem several times over the past few years. It always happens if the transport is set in Loop mode, and if after many loop events I forget to disable Loop and - say - record a part - I run the risk of crashes.

I'm running Win7 with PT10, and I found when I added an extra 4megs of RAM, the issue occurred less often. And after loading up the Legacy IE1394 Win driver last year, the issue is now thankfully rare. But I'm still careful, because when PT wets the bed on a large session, it takes awhile to get it all back.

CaptDan

Humm...do you think that the DM's use of MTC is somehow hogging memory? It's a very strange problem. Since we're using different OS's and DAW's, I assume it's a DM driver issue or firmware bug. Does Tascam monitor this board for correcting user problems?

I assume by the name that the Legacy IE1394 driver is for Firewire 400?

I'm wondering if using the DM's rear MIDI ports for MTC would improve matters. I have to add, the problem does not occur during every session. Earlier today I was working on a mix for about an hour -- looping away to my heart's content but no issues. However, I have to admit that I was working mainly on the keyboard and mouse.

 

[Drumstruck]

Do you have the DM transmitting MTC to Reaper or the other way around? I take it that if you work only with the keyboard and mouse during a given session, you do not have any issues even if you use the DM's pan and fader controls?

I'm not sure why I've been getting the Blue Screen of Death. I assume that it concerns the DM's MTC issue. Before the DM I'd say it's been at least 3-4 years since I experienced a BSD problem. XP and Nuendo have been rock solid for me and hence my reluctance to switch to Win 7.

I have Reaper chasing MTC, though I've tried both options - Reaper chasing works best on my system. fwiw I get the same issue in PT9 but I try to avoid looping in PT as it seems to leak memory.

Transport whilst looping is the only thing that causes an issue - I use the DM remote layer for everything else that it can do - that equals most things as I use my DAWs basically as a tape recorder (and hate chasing the stupid mouse all over the table).

If you look at the memory dump after a bluescreen it should tell you which device/IRQ/whatever is causing the conflict.

 

[JHTorch]

I have Reaper chasing MTC, though I've tried both options - Reaper chasing works best on my system. fwiw I get the same issue in PT9 but I try to avoid looping in PT as it seems to leak memory.

Transport whilst looping is the only thing that causes an issue - I use the DM remote layer for everything else that it can do - that equals most things as I use my DAWs basically as a tape recorder (and hate chasing the stupid mouse all over the table).

If you look at the memory dump after a bluescreen it should tell you which device/IRQ/whatever is causing the conflict.

OK, thanks. I guess I just get into the habit of using the keyboard transport when I'm looping. Not really a big deal. Yeah, I'll make note of the memory dump on the next crash, which hopefully I cn avoid.

 

[Drumstruck]

It would be good if there was a real answer to this issue - thankfully our workarounds are not too big a pita ;-).

The most interesting aspect is that it appears to manifest somehow regardless of DAW / platform.

 

[JHTorch]

It would be good if there was a real answer to this issue - thankfully our workarounds are not too big a pita ;-).

The most interesting aspect is that it appears to manifest somehow regardless of DAW / platform.

Yes, that's why it has to be a DM issue, either with the firmware or the DM's drivers. How frequently does Tascam update the firmware or drivers in the ordinary course?

 

[Arjan P]

The most interesting aspect is that it appears to manifest somehow regardless of DAW / platform.

Maybe I'm lucky, but I use DM transport all the time, and also with loop playing/recording. Never seen this issue.

 

[cmaffia]

I have never experienced this issue either. Arjan and I both use Cubase so I don't think it is exclusively a DM issue. Sounds more like a DAW configuration issue which is triggered by the DM.

 

[captdan]

I have to agree - based on my own observations - that this is DAW/computer specific. As I said, with added memory, new drivers and Legacy IE1394 (pertinent to firewire, not USB), I can loop playback/record, maybe up to 100 events without crashes. I can do so either with PT's virtual transport, or using the DM's 'Repeat' Key which enables Loop. And my PC is by no means 'modern.'

Still, I agree with Arjan: looping is a memory intensive method; and likely, the more you rely on it while tracking, the higher the potential for crashes.

But - YMMV.

CaptDan

 

[JHTorch]

I have to agree - based on my own observations - that this is DAW/computer specific. As I said, with added memory, new drivers and Legacy IE1394 (pertinent to firewire, not USB), I can loop playback/record, maybe up to 100 events without crashes. I can do so either with PT's virtual transport, or using the DM's 'Repeat' Key which enables Loop. And my PC is by no means 'modern.'

Still, I agree with Arjan: looping is a memory intensive method; and likely, the more you rely on it while tracking, the higher the potential for crashes.

But - YMMV.

CaptDan

Yes, looping certainly eats RAM. I have 8 Gigs of RAM and run an Intel Quad-core. Got the system in late 2009 from ADK, a DAW-specific computer assembler. Long before I got the DM I was having issues with my system shutting off for no apparent reason. Finally determined that my case was trapping heat from the power supply. Running the system without the case cover solved it and I enjoyed rock solid performance until this DM transport issue. So I will either place the system in a new case or get a new power supply as to the overheating issue.

As to the transport issue, perhaps I'll get some more RAM. Not sure if I'm maxed out. I don't think so. I'll have to check the motherboard manual.

 

[captdan]

A few years, ago, my PC experienced sudden shutdowns too. I moved the tower case to its own cooler 'machine room' but the problem continued. I finally checked the boot record and it turned out to be a bad video card. Replaced it; no problemo since.

CaptDan

 

[Jarno]

Another source for strange problems with older PCs may be dead BIOS backup battery. Custom-built DAW might have memory sticks which may not like standard memroy timings and these figures must be entered manually. Now when the backup battery dies, computer looses these settings every time it looses power and use default ones: strange crashes. Had experienced this problem with my 2 previous DAW computers. (Yes, used to have sticker listing correct memory timing figures glued into my monitor frame ... won't need it anymore even after battery of my current PC dies ... this new PC's motherboard is capable of negotiating timing figures correctly even with these super-duper-hyper-whatever memory sticks)

 

[JHTorch]

A few years, ago, my PC experienced sudden shutdowns too. I moved the tower case to its own cooler 'machine room' but the problem continued. I finally checked the boot record and it turned out to be a bad video card. Replaced it; no problemo since.

CaptDan

Funny you mentioned a video card issue. Before determining that the issue was (very likely) the overheating of the power supply, I thought that it might be something involving the video card. My dual head Intel video card is integrated into the motherboard. I've read on other forums that integrated video cards can be a source of trouble.

 

[captdan]

I've read similar accounts. My case was a little different; I started with a dual core 'gaming' computer, fast video card with two mini fans. When the shutdowns began, I pulled the card and found dust bunnies had frozen the tiny fan blades. After carefully cleaning the assemblies and freeing the fans, I'd hoped the problem was solved.

A week later - BAM! Back to square #1. I suspect the inoperative fans lead to overheating which fried something on the board. I 'downgraded' to an ATI card designed for 'Plebians' - folks who couldn't care less about running 'Space Demons From Hell' in 3D.

Seriously, though, video card issues and drivers can affect DAW stability and operation.

CaptDan

 

[JHTorch]

Seriously, though, video card issues and drivers can affect DAW stability and operation.

CaptDan

Yes, I know. I have an unused video card in my old system but it's a AGP format and my present board does not have AGP slots. I may just buy an inexpensive PCI video card just to do some tests.