Forward and back to what? These are relative statements. That said, I will share with you my own take on what I agree, is an absolute must have capability when working with this time-based workflow since we're constantly moving around in either direction.
First, here are the (relevant) keybindings I have defined in the sequencer shortcuts (remember, the MIDI clip editor shortcuts are separate).
Edit/Select Mode/Auto Automation edit mode A
Edit/Select Mode/Clip Shift-A
Edit/Clip/Loop Set R
Transport/Backward B
Transport/Forward F
Again, these bindings are only a small subset which I'm pointing out specific to the issue being discussed here. At first glance, they may appear to seem a bit whacky. That is, until you notice a few things. First, every binding I ever set (and therefore, use) is left hand only. This is critical as it means my right hand is always working the rodent and the left is always on the home row of the keyboard. The 2 hands can then work together to work fast and efficiently. 99% of the time, my select mode is set to "Clip". In fact, I never ever use Range or Rectangle. When I need to change the select mode to Automation, whack the A key........ to quickly get back to my normal Clip select mode, shift-A. One might think C would have been the ideal key for setting a select mode of Clip but I map that to Copy (and V for paste)....... ah more single left hand goodness!
OK so now we have those keybindings set up and are now capable of the following speedy goodness:
Left click anywhere on the timeline (see blue bar appear in this location). Whack F or B in order to move the play-head forward or back (depending on where you were coming from. What's nice about this is you can continue to press these keys moving forward or back to other things...... you'll see what I mean.
Select a clip and whack the R key (think "repeat"). Boom! Now that clip is set to be looped and due to the location of the now established Loop-start and Loop-end bars, you again, can make use of your newly establish F/B powers to easily navigate to that area. Thanks to Rui, the Loop Set operation mapped to R has recently been upgraded to act as a toggle. This means you can whack R again to unset the loop range as easily as you set it. Essentially the work flow being described here is 1) Select a clip 2) R 3) F or B as needed. It's difficult to explain just how fast and efficient this is given all the scenarios. In short, there's nothing faster than this "move around by block" approach.
Everything we're talking about here gets extended to other common operations.......... map D to Delete, C to Copy, V to paste, G (think "group") to Merge, T to unlink, Z to undo.
Sorry to have strayed a bit from the origins of Forward and Backward movements across the timeline but it's all related.
In fact, when you get into this type of work-flow, you realize the Backward, Rewind, Fast-Forward, and Forward icons are just sitting here unused taking up precious (too dramatic?) screen real-estate. This is why I had asked they be split out into their own sub-menu and added to the optional list of menus a user to choose to opt in or out of. Yes, I just shamelessly plugged my own feature request. LOL.
By the way, i just read your question again and noticed I overlooked "by grid". I'm assuming you mean you want to be able to move forward and back 1 bar at a time (and yes, this is an assumption since an equally valid assumption could be made for each beat within a given bar). In other words, assuming we're at bar 1 wanting to move to bar 9, we'd end up pressing a key 8 times.
This is HORRIBLE
In vim terms, we call this "leaning". The idea of "leaning" on a key (pressing it over and over again or simply holding it down for some amount of time in order to achieve multiple iterations of the operation) is just about the most inefficient method commonly used by people when they interact with a piece of software. It is an absolute time-sink we commonly refer to as "grunt-work".
Given the choice, it's actually more efficient to use the mouse and that's saying something as keybindings entire purpose in life is to provide a means to interact with the system more efficiently than the mouse.
In terms of workflow, I disagree. There is nothing inherently efficient in constantly switching back and forth between the QWERTY and the mouse . And we're not talking about grunt work when it comes to repositioning the playback cursor. If i'm working with a phrase over a range of 3 or 4 bars, being able to move the PB cursor back and forth to audition that phrase, or chord is essential, for just one example.
And then there's the inevitable wear and tear on the hands and arms from constant mouse use. It's far more ergonomic to use the QWERTY, than do the "grunt work" of constantly using the mouse. How is that any different to pressing a key multiple times? And it's worse, when a comparison is made with the physical requirements of simply tapping keys, and the micro movement "triggering motion" require to operate a mouse.
No, I offered to help you learn how to actually interface with your system more efficiently but you're obviously too sensitive and stubborn to get it. Again, enjoy micro-managing your play-head. I never have to touch mine and I'd be willing to bet I use the mouse less than you do. The difference is I clearly understand (and appreciate) the fact the qtractor uses a GUI. As such, you'd be well advised to start thinking how to get the most from your mouse and your QWERTY (btw, there are many other popular layouts the next time you feel the need to try and look like you know something) keybindings. If you think you're going to be able to use (effectively and efficiently) a GUI program like qtractor without using your mouse, well, in the words of Rob Halford, "You've got another thing coming".
Again, the trick is to use each to compliment the other so the overall balance produces the most efficient and effective form of interaction.
That's exactly what I gave you because your feature request is a dumb one.
I have some prolly idiotic questions for you all:
how often do you use the Rewind and Fast-forward transport actions? Do you find those any useful at all? Could them be axed and modified to accommodate this FR instead? Say, for instance, the rewind and forward steps to be regulated by the current snap-to-beat setting and only when playback is rolling it taking the current fast-stepping continuous behavior?
I don't use those actions in their current state. Why?
The current Rewind and Forward actions are uncontrolled. There's no idea of exactly where they will end up when the user stops pressing the action/keystroke/mouse-click. The user will still have to fine-tune the position of the PB cursor anyway.
Your idea is, in my opinion, the best option. When playback is not running, the user can, with keystroke actions, regulate and define where the PB cursor will be positioned, in a controlled and user friendly workflow. When playback is running, then the actions can conform to the current continuous behavior.
There's an addition to this. When the user is writing midi for multiple tracks, and there are intended unison or chordal parts of several instruments playing together, a controlled PB cursor provides an immediate and obvious visual cue across multiple clip editors, to complement the aural cue from listening. The user can write chords and unison parts quickly, knowing which bar he or she is on, then quickly audition to iron out any errors, or alternatives.
An ideal compromise.
p.s. One more thing. If the user presses the new action once and releases it, then the PB cursor moves by one grid unit and stops. If the user holds the keystroke down, then the cursor goes from grid unit to grid unit, until the user releases the keystroke. So he or she doesn't have to press a gazillion keystrokes to move some distance from where he or she is in the canvas. This is how it works in other daws, and is something most users would be familiar with.
Yea, I can't imagine ever clicking on any of these icons or calling their functionality by way of keystrokes. This style of interfacing with software in this fashion is classic "grunt work". Anyway, some people like to work harder, not smarter. I remember watching a particular producer work with similar patterns and it was so clear how much time was being wasted performing tedious steps over and over again. Grabbing and dragging scrollbars around (constantly), painstakingly auditioning sound patches by starting from the beginning of a convoluted drop-down menu where you'd then need to carefully navigate (and remember what you didn't like last time) sub-menus, using appropriate zoom icons over and over..... essentially fighting with the system in order to get any work done. The thing is, he just didn't know any better. He never took a step back to consider how much time and mental energy was being wasted.
There are more efficient ways to do these things and I for one am really grateful that this software has been way ahead of the curve providing those "hooks" for some time now. A perfect example of this "smart" design came up just last week where I realized each automation point can be copied (C) and pasted (V). Now, once pasted, the duplicate point is made visible and can be dragged horizontally to the desired location. As it is being dragged, the value of the point is maintained thereby ensuring the 2 will match when the new location is selected. This is incredible because it absolutely destroys the alternative workflow I had used previously where I was doing it all manually being extremely careful with the mouse in order to accomplish the goal already mentioned.
But you have to learn to look for these more efficient patterns I suppose.
But back to the original question, I'd just like to see those icons go away all together.
Rui, it works. I've allocated 2 keys to the actions. Transport-Rewind to go back, and Transport-Fast-Forward to go Forward.
There is a small glitch. When I attempt to rewind the playback cursor to the very start of the timeline, it gets "almost" there, as you can see in the attached pic, and it's the same in the main canvas, or the clip editor.
Thanks for doing this. It'll definitely help the workflow.
Edited:
Do not pay attention to this entry, it is wrong. To see below "Another simpler solution"
///////
After test it.
From the keyboard point of view I don't see any objections.
It is a functionality that I missed.
But the mouse interface is now very confusing.
First indicate a bug and then possible implementations.
__Bug__
If you press stop, everything should stop.
Now if play is pressed and fast forward, if we press stop, fast forward continues.
__Implementations__
OPTION A (Continue with this implementation)
_1
Problem | Inconsistency in icons:
It is confusing to see a fast forward and rewind icon that when pressed does not do what you expect, but rather takes a single jump.
Solution | They are different functionalities and require different icons.
Unpressed play
Pressed play
_2
Problem | Button jumping is annoying
With the keyboard, if you hold forward, it works as expected, it automatically repeats the forward.
However, the visual jump on the button is annoying and unnecessary.
If I hold down the button, auto repeat should appear, but it doesn't.
Likewise, a visual jump should not appear.
OPTION B (Alternative Implementation)
The keyboard stays as is, it works well. The button panel changes to a slider spring type.
If it is released it returns to the center. Only accepts marked values, not intermediate ones..
(The example design is inconspicuous. I would have to design it carefully)
The steps work well and are necessary. Why associate them with fast forward and backward?
They should have their own keyboard shortcuts.
In fact, in the midi editor you already have one step (forward).
You just have to add another one backwards and that also appears in the sequencer.
They do not need a button graphical interface:
There are workflows where the keyboard is not feasible (when you record with real instruments that occupy your hands and get space between you and the keyboard). In those cases the mouse is more portable and only takes up one hand, and that allows you to work. To record, just beat snap. and move with the mouse.
Steps are useful in editing tasks (where there are no obstacles to access the keyboard), not recording.
The fast-forward and fast-backward buttons work as they do now, except for the stop, which should stop any action in progress.
yes, they are already implemented somewhat as you say, but not accessible as keyboard shortcuts and that's the OP request, if I'm not mistaken :)
on the MIDI clip editor, the Edit/Insert/Step action is for step-recording/input; it's exclusive to the MIDI clip in scope; it isn't for transport or stepping the play-head around...
and finally, I think you're right, it's probably better making it a separate Transport menu action for sure, not tied to Rewind and Fast-forward; maybe Transport/ Step Backward, Step Forward (without toolbar buttons/icons yet)?
Are fast forward and rewind buttons really necessary, when it can be done better from the watch?
If they are eliminated, the stop button would no longer be useful. Unpressing play is stop.
(In mechanical devices they were essential, but this is a computer program and there are other ways to shortcut these functions)
It's an important decision, but I think it's worth considering.
No function is lost and the interface gains in cleanliness.
Thank you
The steps work well.
For me it is what is important.
The stop button still does not stop if fast forward and play are activated at the same time. Just turn off fast forward.
And stop not stop sped foward/backward.
I find it confusing, but it doesn't affect me, I'm not going to use that function.
the said behavior of the play/pause/stop over rwd/ffwd are to stay as they are...
lets not overengineer what is not (fundamentally) broken; albeit confusing, it's working just exactly like it's been (poorly) designed way long long ago :)
Forward and back to what?
Forward and back to what? These are relative statements. That said, I will share with you my own take on what I agree, is an absolute must have capability when working with this time-based workflow since we're constantly moving around in either direction.
First, here are the (relevant) keybindings I have defined in the sequencer shortcuts (remember, the MIDI clip editor shortcuts are separate).
Edit/Select Mode/Auto Automation edit mode A
Edit/Select Mode/Clip Shift-A
Edit/Clip/Loop Set R
Transport/Backward B
Transport/Forward F
Again, these bindings are only a small subset which I'm pointing out specific to the issue being discussed here. At first glance, they may appear to seem a bit whacky. That is, until you notice a few things. First, every binding I ever set (and therefore, use) is left hand only. This is critical as it means my right hand is always working the rodent and the left is always on the home row of the keyboard. The 2 hands can then work together to work fast and efficiently. 99% of the time, my select mode is set to "Clip". In fact, I never ever use Range or Rectangle. When I need to change the select mode to Automation, whack the A key........ to quickly get back to my normal Clip select mode, shift-A. One might think C would have been the ideal key for setting a select mode of Clip but I map that to Copy (and V for paste)....... ah more single left hand goodness!
OK so now we have those keybindings set up and are now capable of the following speedy goodness:
Left click anywhere on the timeline (see blue bar appear in this location). Whack F or B in order to move the play-head forward or back (depending on where you were coming from. What's nice about this is you can continue to press these keys moving forward or back to other things...... you'll see what I mean.
Select a clip and whack the R key (think "repeat"). Boom! Now that clip is set to be looped and due to the location of the now established Loop-start and Loop-end bars, you again, can make use of your newly establish F/B powers to easily navigate to that area. Thanks to Rui, the Loop Set operation mapped to R has recently been upgraded to act as a toggle. This means you can whack R again to unset the loop range as easily as you set it. Essentially the work flow being described here is 1) Select a clip 2) R 3) F or B as needed. It's difficult to explain just how fast and efficient this is given all the scenarios. In short, there's nothing faster than this "move around by block" approach.
Everything we're talking about here gets extended to other common operations.......... map D to Delete, C to Copy, V to paste, G (think "group") to Merge, T to unlink, Z to undo.
Sorry to have strayed a bit from the origins of Forward and Backward movements across the timeline but it's all related.
In fact, when you get into this type of work-flow, you realize the Backward, Rewind, Fast-Forward, and Forward icons are just sitting here unused taking up precious (too dramatic?) screen real-estate. This is why I had asked they be split out into their own sub-menu and added to the optional list of menus a user to choose to opt in or out of. Yes, I just shamelessly plugged my own feature request. LOL.
By the way, i just read your
By the way, i just read your question again and noticed I overlooked "by grid". I'm assuming you mean you want to be able to move forward and back 1 bar at a time (and yes, this is an assumption since an equally valid assumption could be made for each beat within a given bar). In other words, assuming we're at bar 1 wanting to move to bar 9, we'd end up pressing a key 8 times.
This is HORRIBLE
In vim terms, we call this "leaning". The idea of "leaning" on a key (pressing it over and over again or simply holding it down for some amount of time in order to achieve multiple iterations of the operation) is just about the most inefficient method commonly used by people when they interact with a piece of software. It is an absolute time-sink we commonly refer to as "grunt-work".
Given the choice, it's actually more efficient to use the mouse and that's saying something as keybindings entire purpose in life is to provide a means to interact with the system more efficiently than the mouse.
In terms of workflow, I
In terms of workflow, I disagree. There is nothing inherently efficient in constantly switching back and forth between the QWERTY and the mouse . And we're not talking about grunt work when it comes to repositioning the playback cursor. If i'm working with a phrase over a range of 3 or 4 bars, being able to move the PB cursor back and forth to audition that phrase, or chord is essential, for just one example.
And then there's the inevitable wear and tear on the hands and arms from constant mouse use. It's far more ergonomic to use the QWERTY, than do the "grunt work" of constantly using the mouse. How is that any different to pressing a key multiple times? And it's worse, when a comparison is made with the physical requirements of simply tapping keys, and the micro movement "triggering motion" require to operate a mouse.
Hey, nobody is saying you can
Hey, nobody is saying you can't work like you want to work. Have fun with that.
Well, no, YOU'RE saying I
Well, no, YOU'RE saying I shouldn't work the way I work, because your particular vim community have decided it's...."horrible".
You might want to start your feature request in your own thread.
No, I offered to help you
No, I offered to help you learn how to actually interface with your system more efficiently but you're obviously too sensitive and stubborn to get it. Again, enjoy micro-managing your play-head. I never have to touch mine and I'd be willing to bet I use the mouse less than you do. The difference is I clearly understand (and appreciate) the fact the qtractor uses a GUI. As such, you'd be well advised to start thinking how to get the most from your mouse and your QWERTY (btw, there are many other popular layouts the next time you feel the need to try and look like you know something) keybindings. If you think you're going to be able to use (effectively and efficiently) a GUI program like qtractor without using your mouse, well, in the words of Rob Halford, "You've got another thing coming".
Again, the trick is to use each to compliment the other so the overall balance produces the most efficient and effective form of interaction.
That's exactly what I gave you because your feature request is a dumb one.
Hehe, the only thing you've
Hehe, the only thing you've taught anyone here, is you have no idea what you're talking about.
Fortunately, it's not you making these decisions, it's Rui.
re. 2 actions for moving the playback cursor forward and back
hi, please :)
I have some prolly idiotic questions for you all: how often do you use the Rewind and Fast-forward transport actions? Do you find those any useful at all? Could them be axed and modified to accommodate this FR instead? Say, for instance, the rewind and forward steps to be regulated by the current snap-to-beat setting and only when playback is rolling it taking the current fast-stepping continuous behavior?
cheers
Your question's not idiotic
Your question's not idiotic at all.
I don't use those actions in their current state. Why? The current Rewind and Forward actions are uncontrolled. There's no idea of exactly where they will end up when the user stops pressing the action/keystroke/mouse-click. The user will still have to fine-tune the position of the PB cursor anyway.
Your idea is, in my opinion, the best option. When playback is not running, the user can, with keystroke actions, regulate and define where the PB cursor will be positioned, in a controlled and user friendly workflow. When playback is running, then the actions can conform to the current continuous behavior.
There's an addition to this. When the user is writing midi for multiple tracks, and there are intended unison or chordal parts of several instruments playing together, a controlled PB cursor provides an immediate and obvious visual cue across multiple clip editors, to complement the aural cue from listening. The user can write chords and unison parts quickly, knowing which bar he or she is on, then quickly audition to iron out any errors, or alternatives.
An ideal compromise.
p.s. One more thing. If the user presses the new action once and releases it, then the PB cursor moves by one grid unit and stops. If the user holds the keystroke down, then the cursor goes from grid unit to grid unit, until the user releases the keystroke. So he or she doesn't have to press a gazillion keystrokes to move some distance from where he or she is in the canvas. This is how it works in other daws, and is something most users would be familiar with.
re. 2 actions for moving the playback cursor forward and back
thanks
give me a weekend and your wishes shall be fulfilled (or at least some;))
cheers
Your efforts are appreciated.
Your efforts are appreciated. :)
re. 2 actions for moving the playback cursor forward and back.
done.
Transport / Rewind and Fast-Forward are now step wise when playback is not rolling; in qtractor >= 0.9.38.17git.0a8ef6
thanks
Yea, I can't imagine ever
Yea, I can't imagine ever clicking on any of these icons or calling their functionality by way of keystrokes. This style of interfacing with software in this fashion is classic "grunt work". Anyway, some people like to work harder, not smarter. I remember watching a particular producer work with similar patterns and it was so clear how much time was being wasted performing tedious steps over and over again. Grabbing and dragging scrollbars around (constantly), painstakingly auditioning sound patches by starting from the beginning of a convoluted drop-down menu where you'd then need to carefully navigate (and remember what you didn't like last time) sub-menus, using appropriate zoom icons over and over..... essentially fighting with the system in order to get any work done. The thing is, he just didn't know any better. He never took a step back to consider how much time and mental energy was being wasted.
There are more efficient ways to do these things and I for one am really grateful that this software has been way ahead of the curve providing those "hooks" for some time now. A perfect example of this "smart" design came up just last week where I realized each automation point can be copied (C) and pasted (V). Now, once pasted, the duplicate point is made visible and can be dragged horizontally to the desired location. As it is being dragged, the value of the point is maintained thereby ensuring the 2 will match when the new location is selected. This is incredible because it absolutely destroys the alternative workflow I had used previously where I was doing it all manually being extremely careful with the mouse in order to accomplish the goal already mentioned.
But you have to learn to look for these more efficient patterns I suppose.
But back to the original question, I'd just like to see those icons go away all together.
Ok, i'll test as soon as I've
Ok, i'll test as soon as I've built.
Rui, it works. I've allocated
Rui, it works. I've allocated 2 keys to the actions. Transport-Rewind to go back, and Transport-Fast-Forward to go Forward.
There is a small glitch. When I attempt to rewind the playback cursor to the very start of the timeline, it gets "almost" there, as you can see in the attached pic, and it's the same in the main canvas, or the clip editor.
Thanks for doing this. It'll definitely help the workflow.
Alex.
glitch fixed?
qtractor >= 0.9.38.18git.b416db
cheers
The way I see it, I could be wrong
Edited:
Do not pay attention to this entry, it is wrong. To see below "Another simpler solution"
///////
After test it.
From the keyboard point of view I don't see any objections.
It is a functionality that I missed.
But the mouse interface is now very confusing.
First indicate a bug and then possible implementations.
__Bug__
If you press stop, everything should stop.
Now if play is pressed and fast forward, if we press stop, fast forward continues.
__Implementations__
OPTION A (Continue with this implementation)
_1
Problem | Inconsistency in icons:
It is confusing to see a fast forward and rewind icon that when pressed does not do what you expect, but rather takes a single jump.
Solution | They are different functionalities and require different icons.
Unpressed play
Pressed play
_2
Problem | Button jumping is annoying
With the keyboard, if you hold forward, it works as expected, it automatically repeats the forward.
However, the visual jump on the button is annoying and unnecessary.
If I hold down the button, auto repeat should appear, but it doesn't.
Likewise, a visual jump should not appear.
OPTION B (Alternative Implementation)
The keyboard stays as is, it works well. The button panel changes to a slider spring type.
If it is released it returns to the center. Only accepts marked values, not intermediate ones..
(The example design is inconspicuous. I would have to design it carefully)
Another simpler solution
The steps work well and are necessary. Why associate them with fast forward and backward?
They should have their own keyboard shortcuts. In fact, in the midi editor you already have one step (forward). You just have to add another one backwards and that also appears in the sequencer.
They do not need a button graphical interface: There are workflows where the keyboard is not feasible (when you record with real instruments that occupy your hands and get space between you and the keyboard). In those cases the mouse is more portable and only takes up one hand, and that allows you to work. To record, just beat snap. and move with the mouse.
Steps are useful in editing tasks (where there are no obstacles to access the keyboard), not recording.
The fast-forward and fast-backward buttons work as they do now, except for the stop, which should stop any action in progress.
You're going to laugh
You're going to laugh, but move forward and backward in steps from the interface was already implemented
Watch in BBT mode. Up and down arrow buttons.
It even makes an acceleration if held for too long.
I add:
If you set the watch to time mode, the arrows work much better than fast forward, fast back. More controllable, with an acceleration curve.
Conclusion.
The fast forward and fast rewind buttons are really unnecessary.
re. You're going to laugh...
yes, they are already implemented somewhat as you say, but not accessible as keyboard shortcuts and that's the OP request, if I'm not mistaken :)
on the MIDI clip editor, the Edit/Insert/Step action is for step-recording/input; it's exclusive to the MIDI clip in scope; it isn't for transport or stepping the play-head around...
and finally, I think you're right, it's probably better making it a separate Transport menu action for sure, not tied to Rewind and Fast-forward; maybe Transport/ Step Backward, Step Forward (without toolbar buttons/icons yet)?
re. You're going to laugh...
Yes, at all times I think that as a keyboard action it is necessary.
Transport/ Step Backward, Transport/ Step Forward sounds good.
Are fast forward and rewind buttons really necessary, when it can be done better from the watch? If they are eliminated, the stop button would no longer be useful. Unpressing play is stop.
(In mechanical devices they were essential, but this is a computer program and there are other ways to shortcut these functions)
It's an important decision, but I think it's worth considering.
No function is lost and the interface gains in cleanliness.
re. Are Fast Forward and Rewind buttons really necessary?
exactly, that was the (idiotic) question! remember?
eheh
but omg, they are there for historical reasons and also for (old) MMC purposes... so, no cigar: the fat lady won't sing nor die at the end ;)
re. Are Fast Forward and Rewind buttons really necessary?
:) The truth is that they fulfill a nostalgic (old-school) function, and that is not a minor function.
Morning Rui. I had to sleep
Morning Rui. I had to sleep (which sucks).
Building now...
Glitch fixed.
Thanks.
re. 2 actions for moving the playback cursor forward and back.
redone it all over.
there's these brand new Transport / Step / Backward and Forward menu actions, which are now independent to Transport / Rewind and Fast-Forward, resp.
in qtractor >= 0.9.38.26git.46969e
enjoy
Thank you
Thank you
The steps work well.
For me it is what is important.
The stop button still does not stop if fast forward and play are activated at the same time. Just turn off fast forward.
And stop not stop sped foward/backward.
I find it confusing, but it doesn't affect me, I'm not going to use that function.
I mention it simply to inform. :-)
Does something like that make sense?
re. Does something like that make sense?
the said behavior of the play/pause/stop over rwd/ffwd are to stay as they are...
lets not overengineer what is not (fundamentally) broken; albeit confusing, it's working just exactly like it's been (poorly) designed way long long ago :)
cheers
Excuse my confusion. So
Excuse my confusion. So everything is correct. That shows that I never used rwd/ffwd
A good solution.
A good solution.
Thanks Rui, the new actions work fine.
Pages
Add new comment