Adjust Event Timing -- Effect Doesn't ReSize

[Tom B.]

When doing fine adjustments to event timing ... the effect (ON) doesn't resize when the end point of the effect is moved. (on Either side of the event)

Cannot tell if the event is acting as expected, or if both the visual and the actual are both not adjusting.

Note: The event line does move.

Thanks,

T.

[bob]

This is the way it's supposed to be working, but we're thinking about changing it.

The reason it's done this way is that, now that tracks exist, it's not necessarily the case that effects line up with timings (as opposed to LOR I, where they always lined up with each other).

[Tom B.]

Thanks Bob,

As I explore the usage of Tracks, I see your point. With Channels having the ability to appear in more than one track, it would be necessary to see how the particular channel is working elsewhere.

T.

[Tim Fischer]

bob wrote:

This is the way it's supposed to be working, but we're thinking about changing it.

The reason it's done this way is that, now that tracks exist, it's not necessarily the case that effects line up with timings (as opposed to LOR I, where they always lined up with each other).

That makes sense, but I wonder if a mode would be a good compromise (sort of how you have a "paste by time" mode now) to get it both ways.

-Tim

[Tim Fischer]

Now that I've played with LOR II a little more, I have another idea/option. Would it be possible (if you're not already) to keep track of which track the event was entered in (since they can show up in multiple tracks)? Then if you dragged the timing at the start of an event it would change a-la LOR I if you were in the track that it was originally placed in. If you were in another track, and the event just happened to line up, it would work as it does currently in LOR II.

-Tim

[bob]

Well, I don't think so, really. I'm not sure that it's really clear what "the track it was entered in" means, in all cases.

I'm leaning towards "If the event you drag happens to line up with the start or end of an event or events, stretch all event(s) in the adjacent cell(s) having the event(s) that line(s) up. Otherwise, don't."

[Tom B.]

Bob and Tim,

After spending several days with the software ... I'm inclined to "not" allow a resize to occur "just because it lines up."

Why?

1. 
   
2. When using multiple tracks, there are reasons why you may adjust one event in Track #2, that coincidently, lines up with something that is going on in Track #3 ... but you do not want Track #3 to adjust.
   
3. A good example would be:
   
   • 
     
   • You have a Long Fade, that is on Track #1
     
   • On Track number 2 you have that same length of space broken up into 1/8ths ... and you put a Flash (100% on) in one of those Events ...
     
   • Now when you look at the screen you see: A long fade, with a brief flash in the middle of it, and the fade continues down.
     
   • I think, if you adjusted the event length at this point, and the Effect also was adjusted, I think the Flash would happen correctly -- or be removed.

[*]So, at the moment, I think it might cause more "un-intended" consequences than it would solve. Particularly, a resized Effect does not "look" wrong ... but an effect that clearly does not fit inside the boundaries of an Event does (look wrong). And thus, is easier to identify and change.

I'm sure the debate will continue ... but thought this might at least give a different perspective.

T.

[Tim Fischer]

Based on the above discussion, I'm kind of back to "it should be a user-selectable mode". That is, there should be two options: One which operates like the current LOR II behavior, and one which operates like Bob's suggested "change it if it lines up" methodology.

-Tim

[Richard Hamilton]

Bob,

I'm commenting on this older thread because as you know, I had trouble understanding this new method of resizing, and I reported a bug when an error popped up every time I tried to resize an event to a bigger value. Thanks for setting me straight. I think veteran LOR users will be confused and disappointed by this new approach.

So my 2 cents worth on this topic is I think you had it right in LOR I. I really liked being able to "skew" a portion of the song (and all of its effects) by resizing an event anywhere that things got out of sync. In fact, such an action should probably be called a "skew" because that is what it really does.

My suggestion is to dig up that old code and put it back in and call it a Skew. I think channel actions should be "anchored" to an event marker so that when the marker is changed, the cell resizes or changes the starting location to match. Do it for the track ebing changed, not the other tracks.

I noticed the new feature "Copy to other Track", but it really is not a "Copy". It is a "Mirror" because if I change an effect in one track, it also changes that channel in the track where I copied it.

LOR II would probably be more flexible and serve the other suggestions of people who posted here if you don't link channels together when a "Copy to other Track" is done. Once copied, leave the effects to be independent on that track just like the way you do with the timing marks. They are already independent.

I hope I am explaining this in a way to be understandable.

[bob]

The problem with having two channels in two tracks that control the same actual physical circuit is the same problem with having two channels in two sequences playing at the same time in the same show:

Those two channels will compete for control of the physical circuit, and your light's probably won't behave the way that you expect.

That's why "copy to track" "mirrors" the channel, as you say - it really is the same channel, in two tracks, rather than two channels in two tracks that happen to control the same circuit.

[Richard Hamilton]

Hi Bob,

I completely understand the problem and challenges you face as I've been involved with sequencers, programming, and stage effects for more than 30 years at various times. It isn't simple as you already know.

I obviously did not get an idea across. I need to explain better, but afraid the posting gets too long. Perhaps I am trying to relate LOR to other stage controllers, midi, or music devices that also don't allow control of the same device from more than one source at the same time.

Please entertain this though / idea...
First, I'll say that LOR is superb and I don't mean to undermine it fabulous features. I lvoe it. I'm just stuggling with this new approach to copying channels and not being able to easily skew events.

The goal is as you say, is prevent channel conflict by not doing more than one effect at the same time on the same channel. A suggestion is rather than restricting the program interface to using a copy "mirror" approach that keeps copied channels in sync, prevent conflicts by restricting multiple commands within a "CELL" (event) method.

Let users have multiple rows assigned to the same channel if they want (regardless of what track they are in), but don't allow more than one effect to occur on the same channel at the same time. When a user enters or modifies an effect into a cell (event), have the software verify that other overlapping cells in other rows or tracks are not trying to perform an effect during that same time if they are on the same channel. Then you don't care how the user lays out tracks or timing. The non-conflict validation is done at the time an effect is entered or modified in a cell. If an overlap of commands occur on that channel, notify the user by a subtle means (status bar indicator or popup). This method lets a user put different effects with different timng on one or more rows yet mapped to the same channel, and every effect is tied to a cell starting marker. It gives the greatest flexibility.

This is the way most professional stage effect controllers work in the entertainment world. Many professional music editors, News room and weather video editors work that way also. Even most home video editing tools work on an event or cell bases and don't allow you to overlap effects, yet allow multiple tracks similar to what you already have.

You ever see the lighting and stage effects of a 1994 Pink Floyd concert ;-) That complex show is done with a sequencer very similar to LOR, but is event verified instead of channel verified. In fact, I mapped those effects from a midi sequencer into a 144 channel LOR sequence for two fast paced PF songs... base beats on one track, fast guitar lics on another track, drums on another... all with different timing, and I didn't need to use that copy feature! I tried it, and things just got screwed up. I move tracks, not copy them. And I don't visually have more than one channel shown in two different tracks. I can still do everything I want.

Gee, that hurt my brain to explain ;-) I hope it doesn't cause you a headache.

[WayneKremer]

Instead of having it as a user selectable mode, why not allow it to be the way it is now as the default, then if someone holds down (CTRL or ALT) then drags the event timing, then the effect drags along with the timing? That way, you can quickly do either or. Thoughts?