Resize Timing (bug in 2.0.16)

[Richard Hamilton]

I hope this is the proper place to mention something like this. I was looking for a bug reporting area, but didn't see it. I also did not see this bug mentioned. I'm not going to bother LOR about a simple bug when they are probably frantic to ship equipment.

I was trying to resize an event near the end of a song because the timing of events was off. I received the following error:

"Timing can't be modified to later than 18,335 centiseconds."

Huh ??? I was confused at first but then figured out that what it means is that I cna't resize an event beyond 183 seconds from the beginning of a song. Hmmm, so I tried resizing an event at the 180 second mark and it worked.

This seems like a limitation that will get in the way. Most songs are at least 3 minutes long. This means I can't resize any beyond the 3:03 minutes.

By the way, "Centiseconds" is a weird value anyway. Why not just display in seconds or milliseconds?

Thanks for ideas on getting around this issue. I'm still thinking about it.

RGH

[LightORamaDan]

Hi,

Perhaps you can give us a little more detail of what you were doing. I cannot reproduce the issue. I made a 2 hour long seqeunce and could adjust timing near the end of the sequence.

Thanks
Dan

[Richard Hamilton]

LightORamaDan wrote:

Hi,

Perhaps you can give us a little more detail of what you were doing. I cannot reproduce the issue. I made a 2 hour long seqeunce and could adjust timing near the end of the sequence.

Thanks
Dan

Sorry for the generalized statement. As I experimented more, I see a more strange occurence, and I understand why you probably cannot repeat it.

Specifically, I right mouse click on an event that is located at 3 minutes, 4 seconds into the song. The event is presently sized to 0:00:18 seconds. I tried resizing it to most any value (example 0:00:30 seconds), yet every entry gives me an error.

Now here is the strange part. The error only occurs if I try to change an event that is in the range of 3:01 to 3:04. I can change any even outside that range! (either earlier or later in the song).

I first thought the problem occured at any event beyond 3:05, but on closer observation, it is just the small window I mentioned above.

So it looks like this is a minor problem and who knows... it could be unique to my sequences, but I can repeat it on almost every song I have. Sometimes the error is different. Example, on one song the error is... "Invalid Timing index (1531; 1531 timings exist)".

If you are interested, I can email the sequence, but I don't want to waste your time to look at something that is probably so rare that few people will notice.

It seem oddly coincident that the small range of time for this error is very close to the 18,335 seconds mentioned in the error message.

Thanks for asking. I'll find a work-around.

RGH

[Richard Hamilton]

For your entertainment value, I attached an LMS file to this message to demonstrate the resizing errors. To keep the file as small as possible (92K) for uploading, I deleted all of the on/off events and left only the timing marks.

Interesting, I can resize events (right mouse... resize event) in some places, but not others, and it is not predictable where it will occur. I tried resizing the event at the 3:03 mark from "0:00:18" to "0:00:38" to keep the song in sync at that point, but I get an error. The beginning of the song is another place I tried resizing and it did not work.

It beats me as to how the song got out of sync from last year (LOR I) to this year (LOR II). Maybe it was always out of sync at this place and I did not notice, but it seems pretty obvious to be 200 milliseconds out of sync at that point when I loaded it this year.

So I am scratching my head trying to figure out how to adjust the song.

Well, I tried attaching my LMS file, but I'm getting an error uploading, so here is the file that I put on my own site.

http://magiclightshow.com/bb/download/Sequence-Resize-Errors.lms

[bob]

Hi,

This is not a bug. It's definitely a poor and confusing error message, though. Here's what's happening:

Consider your cell that starts at 3:02.98. It's 0.18 seconds long, meaning it goes from 3:02.98 to 3:03.16.

The next cell starts at 3:03.16 and goes to 3:03.26.

"Resize" does NOT push later timings out further. It ONLY moves the end of the cell that you're resizing. So you can't push the end of the first cell past the end of the second cell.

So, in this case, it's telling you that you can't resize the first cell such that its end is past 3:03.25 - i.e. past the "18325 centiseconds" that the error message says.

If you had tried to resize it to (for example) 0.24 seconds, the error message wouldn't have popped up, because 3:02.98 plus 0.24 is 3:03.22, which is less than 3:03.26.

To do what I think you want to do - i.e. to push all of the timings and events out by some amount, rather than trying to use "resize", I would suggest using "cut" and "cut timings", along with "paste" and "paste timings".

Please note that you can cut a whole bunch in one fell swoop - i.e. from where you want to start pushing stuff out all the way to the end of the sequence. You don't have to cut and paste a whole bunch of times individually.

We're considering ways to make this easier in the future, but for now cut / cut timings / paste / paste timings is the way to go.

Please let me know if anything that I said is not clear, or if you have any additional questions on this. Thanks.

[Richard Hamilton]

Bob,

Well slap me silly. You perfectly understood what I was trying to do and your suggestion works well, although a bit cumbersome to do.

I TOTALLY misunderstood that error message. I would have never guess what was going on. It makes sense after you say it. I am too used to using LOR I for 3 years where a resize would have moved all of the events to the right of the event being changed. That is the way I was expecting LOR II to work, but obviously it doesn't.

If this feature stays as is, I like to suggest the resize dialog either mention the largest value that is acceptable (the current size of the cell), or better yet, not let the user enter a value greater than the current size of the cell.

Quite honestly, I like the way you did it in LOR I. I understand why you are doing it this new way, and it's probably because of the multi-track feature and the untied relationship between events and tracks.

I was just looking elsewhere on the board and see a thread about this whole resizing thing. I will go there and post my suggestion.

Much thanks for this post. Now I won't have to visit the mental health center ;-)