Lags in Playback

[monkey man]

I agree that it would be ideal to get rid of this audio drop-out but I also don't see what's so hard in hitting spacebar to stop playback, changing the loop points, cntrl-opt-c (to jump to the new loop start point), then spacebar again.

I'm with you, Cliffo.

For many years (I'm just not sure whether this included the OS9 days), I've stopped playback to make manual adjustments, especially to the end "locator" (on the right).
I've always done this, with the excpetion of the "set to selection" option; this method doesn't cause the delay, as far as I can remember.
It may be an alternative to bayswater et al's collective beef, albeit a slightly inefficient one in that you have to make a time range selection across the desired loop area first.
I don't like it either, but stopping playback is fine with me - spacebar with left hand, click and drag with right hand and hit the spacebar again.
No big deal. Feels intuitive and makes sense, really.

I do the same thing when selecting plug-ins; beats the delay of a reboot!
Again, it's intuitive in that you're "treating your project gently", and makes sense in that you know that prebuffering and "re-pre-rendering" will need to be done by DP.

I've 2• left in my banana-skin wallet (smells good even when empty!).
Should I leave it on the table on my way out? Er... the 2•, that is?
OK, cool.*

* At this point it's probably worth noting that the monkey's losing it to some extent in all facets of his life.
Remarkably, this applies even to such obscure areas as his much-lauded, in-depth study of sealice mating rituals, the critic-slaying cricket skin oil harvesting project expected to revolutionise the automotive detailing and finishing industries, and, most shockingly of all, the banana:methane volume ratio correlation experiment currently underway in his own living quarters at Banana Alley, Ass-tail-yer!

I told you he was losing it.
You still went right ahead and read that, didn't you, you sadistic bastard?
You looking at me? Who said I lag in playback?

[grimepoch]

Maybe one of the reasons is all the high powered plugins we use now, I just don't know. I can say for sure that the more I add to a project the worse that delay gets when I *touch* anything in DP and the audio is affected.

I'm having a few issues with DP at the moment, and I believe this long delay is causing some lockups on me, so I am trying to work with motu to figure out what combination of things is causing me the problems.

[bayswater]

I agree that it would be ideal to get rid of this audio drop-out but I also don't see what's so hard in hitting spacebar to stop playback, changing the loop points, cntrl-opt-c (to jump to the new loop start point), then spacebar again.

It's like anything else. Just looking for a faster way to get there. What you suggested still has the music stopping and starting, and it involves more key presses.

[bayswater]

I've always done this, with the excpetion of the "set to selection" option; this method doesn't cause the delay, as far as I can remember.

It does cause the delay if you have the selection set to loop. You can mask the delay by manually stopping and starting, but it's still there.

Sorry to hear about your three research projects. I wonder if the methane is killing the lice and corroding the finish on the cars?

[monkey man]

You can mask the delay by manually stopping and starting, but it's still there.

Ouch. Sorry to hear this, Baysie.

Sorry to hear about your three research projects. I wonder if the methane is killing the lice and corroding the finish on the cars?

Eureka! Geronimo! By golly, I think you're onto something, Baysie.

[Shooshie]

This was never an issue with DP 2.7-DP 3.11. You could do just about anything without even a millisecond of delay. This problem has been here since OS X and DP4. There is no way to get around it and it really SUCKS. Look, I'm one of the biggest DP fans on the planet but I call it like I see it.

Check out this post. Read "Bassie12's" reply:

http://www.motunation.com/forum/viewtop ... highlight=


By the way Mr. Clifford, I'm an old fart from the days of tape but after all, this is 2007.

This is one of those things that's worried me since the first OSX came out. I thought OSX, with its multi-tasking, multi-threading, protected memory with core audio and core MIDI... I thought these were supposed to be great advances over what we had before. Now the performance has suffered, and I don't know why. I KNOW that if it was easy to fix, MOTU would already have done it. So, it must be hard to fix. Does that imply that there is a basic flaw in MOTU's code? Perhaps legacy code from 10 or 20 years ago? I would think that it has been rewritten from the bottom up. I just don't know, anymore, what to expect.


Shooshie

[Shooshie]

This is one of those things that's worried me since the first OSX came out. I thought OSX, with its multi-tasking, multi-threading, protected memory with core audio and core MIDI... I thought these were supposed to be great advances over what we had before. Now the performance has suffered, and I don't know why. I KNOW that if it was easy to fix, MOTU would already have done it. So, it must be hard to fix. Does that imply that there is a basic flaw in MOTU's code? Perhaps legacy code from 10 or 20 years ago? I would think that it has been rewritten from the bottom up. I just don't know, anymore, what to expect.


Shooshie

OK, I have to remind myself to put things in perspective. I forget this all the time. Back in OS9, the only virtual instrument I had was Quicktime, via MOTU's "AudioTap" extension. I only used it for utility purposes, and never would have dreamed of incorporating it into a song.

We're handling many times the load compared to those days, along with many features that eat up CPU. T'aint the same thing. Can't compare 2001 with 2007. But still, even with all this load, I expect things to work as well as possible. Is DP going to get more efficient in that regard? When I use only my rack gear, it's still pretty fast, and very much like the OS9 days.

Shooshie

[bayswater]

I read over the discussion on this and went back and tried out a number of combinations. Studio settings and buffers didn't make a lot of difference. The best combination was to set three of the five buttons in the control panel with the "M" on them -- the two on the selection panel and rightmost of the three in the transport. Then use the i-beam tool to mark out the area to be looped in the playback and the pause key if required to start and stop. That combination keeps the cut out in the playback time in the text mix I was using down to less than a second and seems to work better than any othe combination of setting and key commands I could find.

Thanks to everyone for their comments and suggestions.

[Kaspar]

Running all plugins in real time might help on some of the problems. I would like a global setting of that parameter.

[monkey man]

This is one of those things that's worried me since the first OSX came out. I thought OSX, with its multi-tasking, multi-threading, protected memory with core audio and core MIDI... I thought these were supposed to be great advances over what we had before.
Shooshie

I remember the hype.
There was boasting a plenty about core audio's ability to maintain a 2 or 3ms throughput delay even as the load increased.
Much was made of this, as you'd expect, and Windoze comparisons abounded.

I too would like to know what happened to the promised dream of greatly reduced latencies, even under load.
Were the programming hooks and benefits reserved for an exclusive few, such as the Logic team and its beneficiaries (the user base), respectively?

I feel like I've been suckered to an extent.
Many (including myself) made sacrifices in expediting our transitions from 9 to X with the myriad promised benefits in mind.
Foiled again?

[michkhol]

This is one of those things that's worried me since the first OSX came out. I thought OSX, with its multi-tasking, multi-threading, protected memory with core audio and core MIDI... I thought these were supposed to be great advances over what we had before. Now the performance has suffered, and I don't know why. I KNOW that if it was easy to fix, MOTU would already have done it. So, it must be hard to fix. Does that imply that there is a basic flaw in MOTU's code? Perhaps legacy code from 10 or 20 years ago? I would think that it has been rewritten from the bottom up. I just don't know, anymore, what to expect.


Shooshie

Legacy code hits mostly the GUI, all DSP code had to be rewritten from scratch for the new OS interfaces. You didn't have performance issues under OS 9 because you had all CPU resources dedicated to the currently running application and it was up to the application to give them back to others, sitting (not running) in the background. Any preemptive multitasking OS (like Windows XP, Linux, Solaris, etc.) takes away this capability from the application and distributes resources as it sees fit. Among several types of multitasking systems there is a realtime multitasking system (RTOS) which is designed to handle realtime processes such as live sensor data, satellite control and of course sound and video.The FreeBSD OS, which the OS X is sitting upon, was never intended to be the one. You can never gain full control over OS resources (like in OS 9, Windows 3.1, any concurrent OS) in the FreeBSD without a hack. And remember, DP uses MAS as its core audio system (as opposed to Logic). It seems MOTU is having hard time to fully accommodate it to OS X. Meanwhile Logic programmers were digging deep into OS X all this time, I remember a tutorial video with a lot of trimming, moving, cutting soundbites on the fly while music was playing.

[grimepoch]

I agree, MAS must sit on top of the Core Audio System and so add another level of abstraction to the system, and really, there is nothing wrong with this provided the architecture of the MAS system can be mapped into the functionality of how Core Audio works.

One of my beefs with Unix systems is they have never really been that RealTime friendly, but, I believe apple has gone far to improve a lot of the issues most complain about with Unix flavors (for me, mostly slow and resource hungry GUIs).

The other thing is that VI's and Effects are used more and in greater number now than any time before, so they present new challenges. I remember when my problems were just streaming from disk lots of tracks, at that time (using Samplitude on the PC) I NEVER used effects, because they didn't support any then.

The fact that these things work better in logic are hard to judge, because there are other things we get with MAS that logic does not have or do so understanding where the bottleneck is I believe is hard to measure ESPECIALLY with the fact that Motu has to be careful what they rewrite as to not make it hard to load in old projects or have them change drastically. Backwards compatability is HARD on forward progress of code.

Don't get me wrong, I am sure MOTU knows that for their market presence they will have to continue to improve DPs performance so other competitors do not leave them in the dust. There is just no other choice.

[Shooshie]

This is one of those things that's worried me since the first OSX came out. I thought OSX, with its multi-tasking, multi-threading, protected memory with core audio and core MIDI... I thought these were supposed to be great advances over what we had before. Now the performance has suffered, and I don't know why. I KNOW that if it was easy to fix, MOTU would already have done it. So, it must be hard to fix. Does that imply that there is a basic flaw in MOTU's code? Perhaps legacy code from 10 or 20 years ago? I would think that it has been rewritten from the bottom up. I just don't know, anymore, what to expect.


Shooshie

Legacy code hits mostly the GUI, all DSP code had to be rewritten from scratch for the new OS interfaces. You didn't have performance issues under OS 9 because you had all CPU resources dedicated to the currently running application and it was up to the application to give them back to others, sitting (not running) in the background. Any preemptive multitasking OS (like Windows XP, Linux, Solaris, etc.) takes away this capability from the application and distributes resources as it sees fit. Among several types of multitasking systems there is a realtime multitasking system (RTOS) which is designed to handle realtime processes such as live sensor data, satellite control and of course sound and video.The FreeBSD OS, which the OS X is sitting upon, was never intended to be the one. You can never gain full control over OS resources (like in OS 9, Windows 3.1, any concurrent OS) in the FreeBSD without a hack. And remember, DP uses MAS as its core audio system (as opposed to Logic). It seems MOTU is having hard time to fully accommodate it to OS X. Meanwhile Logic programmers were digging deep into OS X all this time, I remember a tutorial video with a lot of trimming, moving, cutting soundbites on the fly while music was playing.

You're saying exactly what I read a few years back in regard to FreeBSD. It was not designed to handle realtime multitasking and also is reported to have difficulty with multiple processors, especially more than 2. They seem to have gotten around that somehow with the Intels, maybe through sheer hardware power, but the realtime multi-threading, multi-tasking that we're expecting was not how FreeBSD was created. Maybe it's evolving toward that. That's possible, isn't it? Is there any licensing issue that would prevent the developers from changing FreeBSD from its current foundation to a more robust, realtime one? Not that I've ever head of anyone doing this; I'm just looking at it as a theoretical possibility.

I foresaw the MAS problem long ago. When I realized that OSX was offering an audio engine built-in to the system, my first question was "what will MOTU do with MAS," which basically becomes redundant at that point. They've kept it, but I think it's hindering DP's progress in this OSX arena. Once again, sheer hardware power is saving the day for them, but even these Intels have their limits, and I've reached those limits periodically. I have to accept that I must act conservatively in my settings and track loading. As long as I do that, the MacPro will burn through my files like crazy.

But I can't help but get the feeling that MAS is getting a little long in the tooth.

Shooshie