Old MWS Measure Mapping Bug Returns?

[Dave Labrecque]

I'm pulling (what's left of) my hair out.

I'm using MWS to add drums and bass to an existing guitar and vocal track for a client. It's mostly a solid 68 BPM, but there are a couple spots that have a slight ritard going into the start of a new section. My plan was to use MWS measure mapping to anchor the start of the last measure of section A, then move the start of the first measure of section B over to the downbeat of the new section's audio.

What happens is that the anchor goes down fine, but when I try to alt-drag the start of section B over, as soon as I release it, a) it snaps back to where I dragged it from, and b) it's revealed that the anchor I'd just laid down has moved to that same point. To add insult to injury, undo has no impact, so I'm stuck with an anchor where I don't want it and an immobile measure boundary.

Is this the same bug from back in 2006 that was supposed to have been fixed? I'll repeat what I said back then: how can it have gone so long unnoticed? Or is this revival due to my Windows 7 migration?

Not sure how to proceed on this project. I need to have this done for the client right away. Yes... panic has begun to set in.

[Dave Labrecque]

Looks like I can work around this by changing the tempo for a measure (using the SS functions, since the MWS functions don't seem to work -- see other thread) and then sliding the stuff downstream that got pushed back to the down beat of the point where the tempo is restored. Kind of a pain, though.

UPDATE: looks like I spoke too soon. The first time it worked. I just tried it again. Using SAW's tempo mapping, I set the tempo at a position based on a one-measure marked area. It worked, except that data going back about two measures prior to the tempo change point got moved, too: although the actual tempo map prior to that point did not change. Tried closing/opening SAW. No good. UGH.

I can't win. I guess the only thing I can do is requantize the data that's getting moved (that's not supposed to move). Good thing I'm quantizing most of this. Otherwise, I'd be up a creek.

[Dave Labrecque]

OK, well...

When I saw that the interval of the data shift preceding the tempo change position (see other thread) was about the same as the amount I'd shifted the zero point on the time line forward, I wondered what would happen if I undid the zero point reset. I did that and moved all the MIDI and audio data back to match, and voila, looks like all the issues (this thread and the other) have gone away. Though I haven't gone back and checked each and every issue. No time.

[Bob L]

Do not shift the zero point... we know that causes all kinds of tempo positioning issues...

Ecverything works as it should if you leave the timeline zero point at zero.

Bob L

[Dave Labrecque]

Do not shift the zero point... we know that causes all kinds of tempo positioning issues...

Ecverything works as it should if you leave the timeline zero point at zero.

Bob L

You're kidding, right?

[Naturally Digital]

You're kidding, right?

I was going to mention the same thing. After all the problems that have been discussed with shifting the zero-point, I was surprised to see you are still using that feature. Don't do that! Change your workflow instead.

[Dave Labrecque]

I was going to mention the same thing. After all the problems that have been discussed with shifting the zero-point, I was surprised to see you are still using that feature. Don't do that! Change your workflow instead.

You're kidding, right? (I really can't tell. If you're being facetious, please disregard the following and accept my humbled chuckle, for that is truly a funny retort. )

Change my workflow from that offered by the software? Yeah, I guess it's come to that.

I guess we differ here. For my money, software should be developed toward eliminating bugs (call me crazy), rather than hoping your user base "gets" that certain features are broken and shouldn't be used -- by having spent time on the support forum. I think that's plain silly.

I've spent a lot of time on this forum. I was aware that smpte/midi mode suffered from some problems when using the zero reset feature. That's why the feature was disabled for that mode, IIRC. However, I only do MIDI projects or use tempo mode occasionally. Not sure how I would have missed that these problems impacted that mode, too. But, I guess I did. Why the feature wasn't disabled for tempo mode? You tell me.

My point is that I was unaware of these problems with using the zero reset feature in tempo mode. And so I lost time on a project in trying to suss it out. And that to simply expect the user to "don't do that" is really lamentable IMO.

[Carey Langille]

You're kidding, right? (I really can't tell. If you're being facetious, please disregard the following and accept my humbled chuckle, for that is truly a funny retort. )

Change my workflow from that offered by the software? Yeah, I guess it's come to that.

I guess we differ here. For my money, software should be developed toward eliminating bugs (call me crazy), rather than hoping your user base "gets" that certain features are broken and shouldn't be used -- by having spent time on the support forum. I think that's plain silly.

I've spent a lot of time on this forum. I was aware that smpte/midi mode suffered from some problems when using the zero reset feature. That's why the feature was disabled for that mode, IIRC. However, I only do MIDI projects or use tempo mode occasionally. Not sure how I would have missed that these problems impacted that mode, too. But, I guess I did. Why the feature wasn't disabled for tempo mode? You tell me.

My point is that I was unaware of these problems with using the zero reset feature in tempo mode. And so I lost time on a project in trying to suss it out. And that to simply expect the user to "don't do that" is really lamentable IMO.

+1

[Naturally Digital]

You're kidding, right? (I really can't tell. If you're being facetious, please disregard the following and accept my humbled chuckle, for that is truly a funny retort. )

Dave, it's not a personal attack and certainly nothing more than a light-hearted suggestion so it might as well be taken as facetious because that makes it a quite funny, sarcastic comment.

I did however mean it in a 'serious' manner but OTOH I may be ignorant to the needs of working in midi and/or tempo (bars, beats) mode where measure 1-beat 1 is important and the need to shift the zero comes much more often. The thing is, anytime I've tried to use the zero shift feature I've had somewhat 'unpredictable' results. I even tried to use it recently and bumped into a few issues (including not being able to reset it properly after the fact) so... I came away going 'oh yeah, that is a bit of a known issue'. I figured since you read the forum at least as much as I do, you would be aware it's a bit of a problem.

Anyway, not to take anything away from your point because I know you're upset about the time wasted on it etc. So carry on...

My personal minor gripe is that the alternative to using the shift-zero is to move every single item on the timeline left or right and this I find somewhat difficult to do with confidence. When you consider one wants to shift every region on every layer, all automation, video regions and control track entries (not to mention MWS data) by an equal amount without losing sync, it turns out to be a multi-step process where one needs to be very careful in order to maintain the relative positions of all the entries. IOW it's not exactly ctrl-A, move. It's for this reason I wish the shift-zero point feature worked perfectly but alas it doesn't so I work around it. Not a deal-breaker for me.

Anyway, Dave and Carey... I'm not meaning to downplay the importance of this for either of you.

[Dave Labrecque]

Dave, it's not a personal attack and certainly nothing more than a light-hearted suggestion so it might as well be taken as facetious because that makes it a quite funny, sarcastic comment.

I did however mean it in a 'serious' manner but OTOH I may be ignorant to the needs of working in midi and/or tempo (bars, beats) mode where measure 1-beat 1 is important and the need to shift the zero comes much more often. The thing is, anytime I've tried to use the zero shift feature I've had somewhat 'unpredictable' results. I even tried to use it recently and bumped into a few issues (including not being able to reset it properly after the fact) so... I came away going 'oh yeah, that is a bit of a known issue'. I figured since you read the forum at least as much as I do, you would be aware it's a bit of a problem.

Anyway, not to take anything away from your point because I know you're upset about the time wasted on it etc. So carry on...

My personal minor gripe is that the alternative to using the shift-zero is to move every single item on the timeline left or right and this I find somewhat difficult to do with confidence. When you consider one wants to shift every region on every layer, all automation, video regions and control track entries (not to mention MWS data) by an equal amount without losing sync, it turns out to be a multi-step process where one needs to be very careful in order to maintain the relative positions of all the entries. IOW it's not exactly ctrl-A, move. It's for this reason I wish the shift-zero point feature worked perfectly but alas it doesn't so I work around it. Not a deal-breaker for me.

Anyway, Dave and Carey... I'm not meaning to downplay the importance of this for either of you.

No worries, Dave. I'm not all that bothered by having to work-around it. I'm quite happy to have found the problem (which was not at all obvious to me at first).

I'm bothered (as you know) by the fact that it messed up my work session and caused me to miss a deadline. And that the developer doesn't seem to think this is a problem -- that I should know better than to use all the available features in the program. Does anybody hear how crazy this sounds? Am I mad?

I think we would all agree, including Bob, that this problem should not have been left in the code for this long. Yet it seems to be looked upon as acceptable. What other features should I be avoiding for fear of getting caught like this again? I'm just glad I figured it out in only a couple hours, rather than having to wait till later when it was revealed to me that I shouldn't be using that feature. My bad? So it seems.

Alas, he's one man who needs to make a living. And so priorities are what they are. I understand the trade-offs (and the advantages) of going with a boutique program like SAW. I just wish I'd stop having such high expectations (like a smooth 'ride') when I'm on a deadline. It just isn't realistic for the way I work, I guess.