MOTUnation.com

blue wrote: But the bursts never seem to come at the same place. If I follow your advice, I would need to put volume information at every tick in every track in anticipation of random volume bursts. And I'm not even sure that would cure it. Even if it did, I don't think it would be worth it. The bursts are much more seldom these days.

Well then I'm stuck. It seems as if this occurs in many different ways. Maybe depending on something else than DP itself? Other hardware or software configs? I don't know.

I think the problem was in Apple's OS system. I had the same problem, where you'd get bursts of volume....then I downloaded an update from Apple and then it was gone. So make sure you do that! Haven't had it since, thank goddess!

There was another long-ish thread about it. A lot of "obvious" features were eliminated as the culprits, such as having continuous data on/off, track automation on/off, etc.

One thing several people suspected was that the bursts didn't start until something was copied and pasted into the sequence. That may have been the closest anyone has come to inducing the problem to kick in, though not 100% definitive.

The tricky part is in determining whether audio is at the root of the problem or whether MIDI itself is where both are actively involved and co-dependent with virtual instruments.

MIDI data in the sequence "calls" for the appropriate samples to be triggered; just one MIDI note can cause it on a patch that contains multiple samples layered, such as Ivory which contains a dozen sample layers mapped per note.

--it doesn't happen with external MIDI modules, so that leaves out MIDI as the sole culprit, anyway

--it doesn't happen on audio-only projects, which means that MIDI has to be involved. Audio and MIDI together appear to be accessories to the crime.

--it's not related to firewire bus clog because I've seen it happen using only SATA and eSATA drives.

--some have reported data or memory leaks in DP even when trying to solo and mute tracks that don't always mute properly.

I tend to lean towards the date/memory leak theory for this reason. If track data can thwart muting, it follows that wayward data can thwart real-time virtual memory updates and lead to a small amount of duplicate data being processed-- (ie: bursts).

--CoreAudioMAS errors from past crash logs have indicated that the Apple/MOTU handshaking may be at issue. Another observation that supports this is the lack of these symptoms happening in Logic. Logic has other issues, however, such as the dead-sample-on-first-play syndrome. This itself points towards the CoreAudio side of things. I've always taken the notion that if something were amiss in Logic in terms of efficiency at the OS level in any way, it had to be a *temporarily* insurmountable problem until Apple gets around to releasing an update of OSX or Logic.

The connection here, again, is memory management-- and the Logic symptom, ironically, is the lack of data (no sound at first) whereas the DP symptom is too much sound in unpredictable places on occasion.

Thing is, I've had the bursts while running only MAS plugins, while running only AU plugins, and while both at the same time. The only thing they all have in common is DP afaik, so I'm at a loss on this one.

The only other thing I can come up with is the whole Carbon vs Cocoa theory. There may be lots of other reasons why Apple decided not drop support of Carbon frameworks for 64-bit threading last June besides mere convenience. Since OSX is now officially certified as a UNIX OS the Carbon stop-gap frameworks may have proven to be more trouble than they're worth, potentially falling outside of the UNIX official spec where crash reports have sent to Apple may have pointed to Carbon as a sort of general albatross as OSX (Leopard) gets updated and refined.

The consideration here is that those who are not using DAWs on their Macs are not likely aware that the problem even exists, so it appears to be just some fraction of electronic musicians dealing with this.

And for those who don't experience this at all, I say good for them! For as enviable as they are, they're also the least likely to have any suggestions for troubleshooting the problem.

Clearly, it's supposed to work well and obviously does on some systems even where VIs are involved.

Like I say, I'm at a loss for why bursts still take place regardless of DP or OSX versions are being used in combo, so none of this should be taken as anything official. It remains a mystery.

Many times I have noticed the reason its happening is simply because I've accidentally pasted one note on top of another. So you have to think that it may not happen as much as it seems to, with other errors being the real cause that you blame the velocity bug for.

RhythmRmixd wrote:Many times I have noticed the reason its happening is simply because I've accidentally pasted one note on top of another. So you have to think that it may not happen as much as it seems to, with other errors being the real cause that you blame the velocity bug for.

That was the subject of my very first test, and while it's a perfectly reasonable notion I've spent days entering note data and editing Event Lists to make sure that there were no double notes.

It's not that the double notes don't result in the same symptom, but the symptoms do indeed occur without the double notes.

The one thing to remember is that if it were only about double notes, the symptoms would occur in the same places all the time until the double notes could be located and fixed.

But the particular brand of bursts in question appear to happen randomly. Those are the ones that freak me out.

Man-- how I wish it were just double notes!!

Since my bursts were reproduceable I could just sit and watch the volume faders go to 127 exactly at the same tick over and over again.

e-snobben wrote:Since my bursts were reproduceable I could just sit and watch the volume faders go to 127 exactly at the same tick over and over again.

When you say they were "reproduceable", does that mean that they were also predictable? Or were they more random?

I wonder; will it do it in a sequence where all faders are fixed at 127?

If so, I would think that it could be random doubling of existing MIDI notes. Kinda like when I have a track in solo and other tracks will blurt out their parts here and there.

Tim wrote:I wonder; will it do it in a sequence where all faders are fixed at 127?

If so, I would think that it could be random doubling of existing MIDI notes. Kinda like when I have a track in solo and other tracks will blurt out their parts here and there.

That was one of my tests-- to max everything out at the top but it still happened. As I studied the event lists, there was no indication that a lower fader setting had appeared and then jumped back to 127-- at least not visibly. This was part of my continuous data on/off tests.

I might have thought that there were phantom automation control changes cropping up, but it really sounds more identical to "other tracks will blurt out their parts here and there".

LOL-- I actually like the term "MIDI Blurt" better!!

Frodo wrote: That was one of my tests-- to max everything out at the top but it still happened. As I studied the event lists, there was no indication that a lower fader setting had appeared and then jumped back to 127-- at least not visibly.

Well that would support the theory of it being actual doubling of notes, a possible relation to the solo thing, and a memory/buffer thing.

I'm curious about different buffer settings, and if it does it with ADC off. I've not read this whole thread, so, sorry if this was already mentioned.

Tim wrote:

Frodo wrote: That was one of my tests-- to max everything out at the top but it still happened. As I studied the event lists, there was no indication that a lower fader setting had appeared and then jumped back to 127-- at least not visibly.

Well that would support the theory of it being actual doubling of notes, a possible relation to the solo thing, and a memory/buffer thing.

Well, yes and no. If the two possibilities are absolute, then the answer would be yes to one or the other-- in this case double notes.

But where no double notes exist (see earlier post where special sequences were made and event lists were checked for double notes)-- and the "blurts" still happen it points to phantom data of one kind or another.

Tim wrote: I'm curious about different buffer settings, and if it does it with ADC off. I've not read this whole thread, so, sorry if this was already mentioned.

Now you're cooking!! Buffers, memory, and the like appear to be closer to the truth. I don't think we've gotten into ADC on this thread, but it might have popped up on one of the others. Wish I had time now to read through it all again, but maybe I'll bookmark it for later.

Some links:

http://www.motunation.com/forum/viewtopic.php?t=23964

http://www.motunation.com/forum/viewtopic.php?t=23099

LOL-- this was started by someone famous!
http://www.motunation.com/forum/viewtopic.php?t=15482

Tim wrote:I wonder; will it do it in a sequence where all faders are fixed at 127?

I doubt it since 127 is the maximum level.

Oops! Frodo says otherwise.

Frodo wrote:

e-snobben wrote:Since my bursts were reproduceable I could just sit and watch the volume faders go to 127 exactly at the same tick over and over again.

When you say they were "reproduceable", does that mean that they were also predictable? Or were they more random?

In this case they were predictable. Here's a quote from the other thread.

This is my theory so far regarding unwanted volume changes in VI's.
When a patch change is initiated, the VI patch loaded comes with a certain volume preset. This volume preset must be changed if it doesn't correspond to the desired value. Therefore you have to add an additional controller #7 message after the patch change, since the patch change seems to be treated as if you would disconnect the MIDI cable of your hardware synth and plug it into another one. Alternatively DP must be told to reinitiate an event chasing after every program change to get the correct values for the new patch. As far as I know event chasing only occurs when hitting play, and is not a continous kind of feature that would work when switching cables on the fly. Or is it? If so my theory fails.

To try this I saw to that the patch changes in the tracks where the unwanted volume changes occured, were placed at the same measure, beat and tick 5|4|240. In this case it was the best thing to do since all the instruments had a brief rest. And finally I took a volume snapshot - from counter to next change (flat) - at 5|4|300 of the tracks in question.

The test
- I chained the chunks.
- I started playback towards the end of the chunk before.
- There were no unwanted volume changes.
- I undid the snapshot and tried again.
- This time the unwanted volume changes reappeared exactly as before in the same tracks.
- I redid the snapshot.
- There were no unwanted volume changes.

FWIW, I can't recall ever experiencing volume surges of the kind you describe on on any version of DP. Despite constant copy/paste, sometimes, I'm sure, hundreds of time, on the same set of tracks.

OTOH, I never - or rarely - change patches on a given track. At most, it's the equivalent of a key switch - ie, the same sound, different articulation.

If anyone wants to email me a dp file, I'll try it on my system. Obviously the sounds will be different, but if there's a volume surge, I should be able to hear it even so, right?

Man, that's a disturbing Avatar. I keep staring at the thing, makes it hard to read the posts.