DP 5.11 on Mac pro Tiger 10.4.11

[mfromwhere]

I'm running DP 5.11 on a Mac Pro (intel) running Tiger v.10.4.11

I've run into a problem where every few days (or sometimes multiple times in a day) dp stops sending MIDI notes from my MIDI keyboard to my software synths. This is true for both software synth plugins in DP and others connected via MidiOverLan.

Two of the things that are especially odd about this is that i can see that the computer running DP is receiving the MIDI on the the MidiOverLan monitor, and even when DP isn't sending the MIDI, i can still send the MIDI by going to audio MIDI setup and using the test feature to check each software synth.

The only way I am able to get DP to send MIDI to the software synths is to restart DP every time this problem arises.

I've got all the most recent drivers, and I've got my MIDI keyboard hooked up directly through a MIDI timepiece.

I've tried reinstalling DP, I've tried DP 5.13 and 5.12

Every time I call Motu support they blame everything besides DP


Any suggestions would be greatly appreciated.



Thanks,

-Mike

[Frodo]

This is one of the reasons I've avoided MOL in favor of the old MIDI cable approach. Some people are not having trouble with MOL, but some have talked about data dropouts.

Have you contacted MusicLab tech support to inquire about possible LAN optimization settings?

At one point I was trying to figure out what its Quantize Settings did. Here's how they begin their explanation in the manual:

Let••™s try to understand what Send Quantization mechanism is for and how it affects MIDI event stream timing.

Imagine you••™re haulier and have infinite number of trucks. Your trucks are intended to carry some count
goods (household refrigerators for example) from finished stores of several factories.

Primary scenario of household refrigerators transportation may be as follows:

An autoloader gets one refrigerator (assume it cannot get more than one at a time) outside finished store and loads it onto a truck. Upon completion loading of one refrigerator a truck driver immediately turns ignition on, starts engine and drives this one refrigerator to some other place (an intermediate storage area). While first truck is on its way, the autoloader gets the next refrigerator and loads it onto another truck, which immediately starting its way too and so on...

Such a rambling preamble did nothing to enhance my understanding of MIDI event streaming, to say the least. But I suppose somewhere buried deep inside the Quantization feature there may be an answer to how MIDI event streaming might be optimized.

My guess from the awful truck analogy is that MIDI data is delivered in packages, much like USB data-- but somehow, subsequent packages of MIDI data are not arriving as expected.

I do know a few people using MOL, so I'll run the question by them and post whatever info that may surface.

[mfromwhere]

I'm pretty confident that the problem is not MOL as it effects all software synths across the board. Including the ones that run as plug-ins inside of DP.

In addition, if I play the sequence with MIDI that I've already recorded in DP it still plays back all of the software synths. The problem is that somehow DP stops forwarding the MIDI it gets directly from the MIDI keyboard to the synths.

[Frodo]

Every time I call Motu support they blame everything besides DP

Ye olde runaround, eh?

Hmm. Such a nasty catch-22, this.

Did MOTU even suggest what aspect it could be even if wasn't DP's fault? Again, it may not be MOL's fault, per se, but if MOTU has recused itself from the troubleshooting, perhaps MusicLab will have more info on how MOL works with various sequencers and could explain why this happens.

To help nail this down, have you tried a similar project with, say, GarageBand (if GB even supports MOL) or another MIDI app? If the problem doesn't occur with other DAWs, then it's clearly a DP issue which may be insurmountable-- one which MOTU doesn't feel like surmounting at the moment as they work to clean up DP6 for release.

Is there anything else running on your Mac that could be polling the ethernet port concurrently? Just picking at straws here until I get some more definitive feedback for you...

[Frodo]

Here's a bit of info from one of the developers at the Vienna Symphonic Library where things like Wormhole2 and MOL are used by a number of its members-- fwiw:

the behaviour you describe fits pretty well into the picture of OS X *looking ahead* type of memory management which is contraproductive for streaming.

the OS assumes some loaded data is not needed currently and moves it into the pagefile (on disk) ... surprisingly the application now calls the data and the OS has to reload it from the pagefile (on your system disk) to physical RAM causing delay and emptying of the buffer (sound drops)

i've already pointed in an earlier post to an article on the apple developer pages where they confirm even memory marked as *wired* (= to be kept in RAM) gets paged out - a serious misdesign for a sampling application and not configurable (at least configuration not supported)

you could confirm this for yourself comparing the behaviour during less load and extensive load of patches/matrices - watch your activity monitor during that.

obviously there is some *learn* algorithm built in memory management which then leaves more often used data in physical RAM

i only have a very plain hint to a solution: much RAM helps much ...