req: track parameters automation read mode behaviour identical as with Fx parameters

[deeb]

this differences makes me feel:

Originally Posted by deeb

i just can't get used to it - it is uncompressible to my understanding and how i see

Originally Posted by deeb

I can't use it , really because we are always stuck, for touching and reading, nothing makes sense to me. I am being totally honest. It just stucks, is totally unusable.. And With FX parameters same reading and trimming and touching have different behaviour which is usable , expectable and i don't get stuck.

example 1/n:
trim is different between track parameters and fx parameters:

With Trim in Fx parameters the automation gets control when we stop dragging the knob (desirable). While with track parameters the automation does not have control back again.



example 2/n:

In the next gif I am using same read mode in different tracks
One track automating volume and other automating reasynth volume.

changing Track Volume does not have effect on the output, while changing reasynth volume has effect on the output, which is desired if we're previewing.



There are many differences more.

[deeb]

another example with Sends Volume (which is the biggest issue for me since for track volume i could workaround by placing a volume plugin just for this).

if Automation already exists, we have no way to change it by dragging its fader - we are stuck.

notice altho i am mouse dragging send volume fader and is at -inf automation does not give control to the movement i am doing on the fader.



This does not happen with FX parameters.

[Lunar Ladder]

Originally Posted by deeb

if Automation already exists, we have no way to change it by dragging its fader - we are stuck.

?

[Lunar Ladder]

Look into the Touch, Latch and Latch Preview modes, alongside the latch clearing actions. I'm not totally sure I'm not missing something in turn here, but ^ at least I haven't bumped into any issues when using these as pictured.

[deeb]

Originally Posted by Lunar Ladder

?

No man. I mean we have no way to change the parameter without being forced to write.

[deeb]

Originally Posted by Lunar Ladder

Look into the Touch, Latch and Latch Preview modes, alongside the latch clearing actions. I'm not totally sure I'm not missing something in turn here, but ^ at least I haven't bumped into any issues when using these as pictured.

In this gif there is something interesting, which doesn’t happen to me. Seems Changes on the knob/fader take control without writing. What mode are you?

[Lunar Ladder]

Originally Posted by deeb

What mode are you?

Latch Preview, and then clearing the latch on the fly when done. There's an action both for clearing the latching state for the selected track, and globally.

[deeb]

Originally Posted by Lunar Ladder

Latch Preview, and then clearing the latch on the fly when done. There's an action both for clearing the latching state for the selected track, and globally.

Thanks Lunar Ladder. I am not in the computer, this is a similar behaviour when I am in read mode in fx parameters but doesn’t happen with track parameters.

[deeb]

The point is: as is demonstrated on my previous gifs read mode behaves differently between fx and track parameters. Why so? I don’t see a reason why it has to be like that and as far as I can see this is undesired.

[deeb]

Originally Posted by deeb

Thanks Lunar Ladder. I am not in the computer, this is a similar behaviour when I am in read mode in fx parameters but doesn’t happen with track parameters.

i confirmed this. The thing is read mode in FX parameters does basically the same as you are doing with latch mode and the additional action to clear latch. That is the point. Same "read" different behaviours. we are not able to have same workflow with track parameters and if using a controller (or without actually) having the need to trigger an action is undesired.

Please try with FX parameter and compare with track Parameter and check for your self.

But thanks for the input! appreciated!

[Lunar Ladder]

Hmm, generally a read mode is not supposed to do that (at least by default) if there are also explicit latch and latch preview modes available. It seems it doesn't do this with FX if you move an FX parameter, while in read mode, using the TCP parameter controls. In any case, I've always used the latch modes, as they are explicitly designed to do this kind of thing across the board.

Imo, if making a request for consistent functionality across the board, that would be Read always with no latching whatsoever, and when latch is actually on (either for writing or merely previewing without writing), you'd then also have consistent toggles for those, controlling relevant latch auto-clearing. I.e. have it let go of the latch at mouseup, or at a particular control being still for a specified time, etc etc, when wanted.

In any case, if this is changed at this time, after so long, without having conveniently toggleable modes that also cover 1:1 the previous experience, there are bound to be users and some edge use cases... where the change is met negatively, I would bet.

[Edit: I mean, what you would clearly prefer, if I gather this correctly, is a Latch Preview mode that lets go of the latch automatically when you let go of the control. And have that work consistently for all sorts of parameters.]

[deeb]

The terminology used is pretty much secondary IMO as long we can have the tools to do what we need to do. If consistency should be as you are you describing,, by not allowing what is happening in fx parameters and reading , let it be and I am ok with that, as long as the functionality is available in another mode like example latch (preview) with the auto clearing as you described which is how read mode works on fx parameters at this point.

The point is : at this time with “read mode” in fx parameters I can happily do what I want and I can’t with track parameters.

Thanks again for the input since it also helps my self to clear what is the issue that I am experiencing.

[Lunar Ladder]

Yep, agreed, and the terminology is naturally secondary in a way; that is, I don't mean the terminology in an of itself, and instead I just mean that if the Read mode is modified to perform, by design, what a Latch Preview mode is supposed to do, then there are redundant modes, and no actual separate Read mode unless this is in any case controlled by a set of options/states/toggles that enables one to do as they like.

[deeb]

Originally Posted by Lunar Ladder

Yep, agreed, and the terminology is naturally secondary in a way; that is, I don't mean the terminology in an of itself, and instead I just mean that if the Read mode is modified to perform, by design, what a Latch Preview mode is supposed to do, then there are redundant modes, and no actual separate Read mode unless this is in any case controlled by a set of options/states/toggles that enables one to do as they like.

i get your point, about redundancy which should of course be avoided. But i don't see a reason why someone would be not happy with current read mode still being able to "latch preview and clear after drag", because how i see, if we don't want audible changes, we don't drag the knob. But i guess with controllers is a totally different story, since drag and controllers messages are naturally different and so maybe it would be not redundant to keep both Track parameters and Read mode working like FX parameters is currently working and having exactly same behaviour with mouse drag on Latch preview with mouse actions but inevitably with hardware controllers like it latch preview is working now. I hope you get the point.

It's out off topic but is kind of related, I am not a trim user as i don't see use for my self, but i feel the existence of trim is kind of redundant since we are doing changes with a knob on the envelopes which now we can do with Razor edit, which (i think) does exactly the same in a bit awakard way and so trim existance in a knob makes the modes less clear. And trim/reasd is the default mode. Maybe i am wrong but in IMO trim/read could just disappear, or at least to not be the default. I have my TCP full of different colors because default is trim/read (grey) and i want to default example: latch preview (which is yellow).

[Lunar Ladder]

Originally Posted by deeb

i feel the existence of trim is kind of redundant since we are doing changes with a knob on the envelopes which now we can do with Razor edit, which (i think) does exactly the same in a bit awakard way and so trim existance in a knob makes the modes less clear.

This is not an example of redundancy in the sense of "there are two modes that do exactly the same thing", these are two different ways of interacting with automation (trim can be used live, using appropriate controls while the project is playing, independent of the play position; razor edits are targeted areas that are generally used when editing).

It's a sort of a complex subject and ^ this is a good example of why changes shouldn't be made rashly if one just happens to feel like it, imo. But I agree there's room for improvement, of course, with some "oh it works like this" kind of peculiarities that one just needs to take into account.

[deeb]

B u m p.