@Zynewave wrote:
I assume you mean holding Ctrl+Alt while dropping. Could be a solution. But then we have the same possibility for confusion, as we had with the old Alt key phantom drag behaviour, which is that you need to press Ctrl+Alt AFTER you have clicked. Otherwise you would start a zoom drag.
Yes, that’s what I ment. A unique solution/behaviour to get a Unique copy, easy to remember.
@Slomo wrote:
@Zynewave wrote:
I assume you mean holding Ctrl+Alt while dropping. Could be a solution. But then we have the same possibility for confusion, as we had with the old Alt key phantom drag behaviour, which is that you need to press Ctrl+Alt AFTER you have clicked. Otherwise you would start a zoom drag.
Yes, that’s what I ment. A unique solution/behaviour to get a Unique copy, easy to remember.
Hmm, it just doesn’t add up. If Ctrl+Alt should drag unique copies, then it won’t be possible to drag a phantom copy to another track, locked to the same timeline position. Other suggestions?
Here’s a possibly weird suggestion: How about making double-tap of the Ctrl key swap between dragging phantom or unique?
So, Ctrl+click will start a phantom copy drag. While holding down the mouse button, double-tap the Ctrl key (and keep Ctrl pressed on second tap) to change the mouse cursor from the phantom copy cursor to the unique ‘+’ cursor. It’s a bit like a secret handshake, but at least it will be known to users that read the key shortcut page in the guide.
@Zynewave wrote:
Here’s a possibly weird suggestion: How about making double-tap of the Ctrl key swap between dragging phantom or unique?
So, Ctrl+click will start a phantom copy drag. While holding down the mouse button, double-tap the Ctrl key (and keep Ctrl pressed on second tap) to change the mouse cursor from the phantom copy cursor to the unique ‘+’ cursor. It’s a bit like a secret handshake, but at least it will be known to users that read the key shortcut page in the guide.
Sounds like a nice compromise
Yes, that sounds like a good and creative solution.
Frits, if you allow me the tip I think you’re losing lots of functionality not allowing right mouse button do actions and don’t allowing that modifiers+mouse buttons are context dependent too. That means lots of new and easy shortcuts that honestly, if I was you, I would re-plan again. I want to mean, when the mouse its over an emply space Ctrl/Atl/shift + LMB/RMB do something, when the cursor is over an event border the same keys do another things. Think that in a near future is easy that you implement timestretch, and that mean another shorcut.
Other host take advantage here (context dependent + right mouse button), and other draw or design programs too, even Windows and Linux… it shouldn’t be bad.
If you want I could develop a complete shortcut map allowing this functionality, but something say me in the ear that you prefer develop it yourself 😛
@LiquidProj3ct wrote:
If you want I could develop a complete shortcut map allowing this functionality, but something say me in the ear that you prefer develop it yourself 😛
You are welcome to come up with your suggestions, which the community here then can discuss. Better do that in a new topic. I ask though that you please consider consistency across the entire UI. It’s not enough to make up the perfect key/mouse behaviour for the piano-roll, if it means that the key shortcuts will conflict with behaviour in other parts of the UI. I don’t want to remember a different set of shortcuts for each editor.
Thanks for the change, anyway I was doing it already 😀
The most Podium shortcuts are fine, the only problem is when you want to edit music, so I’m going to post in another thread how I would do it. Because pressing notes after others is a little messy
My observations:
Alt+Shift as it is in beta1 is pretty useless. It does the same as just holding Alt when dragging vertically, and for horizontal dragging… I think it’s not that hard to keep an event on the right track.
Ctrl+Alt+Shift is equally useless. In beta1, it doesn’t do anything different than Ctrl+Alt when dragging vertically, and again, locking the x position isn’t really necessary, in my opinion.
Something I came up with:
Ctrl – Create phantom copy
Alt – Lock x/y position
Shift – Override snap
Ctrl+Alt – Create unique copy
Ctrl+Shift – Create phantom copy and override snap
Alt+Shift – Create phantom copy and lock x/y position
Ctrl+Alt+Shift – Create unique copy and override snap
It’s not great either, especially Alt+Shift is weird, and there’s no shortcut to create a unique copy while locking the x/y position.
I don’t know of any programs that add the right mouse button as a modifier, and think I’d find it uncomfortable…
Something will have to be sacrificed in the end… Personally, I’m fine with losing ‘create unique copy’ and getting ‘override snap’.
Thinking of the future – I’d say it would be fine if time-stretching, for example, was done by clicking on the resize handles while holding some modifier key. I don’t think anyone would time-stretch at a zoom level where this becomes impossible.
Beta2 is up. Some bugs are fixed, but there are still a few left that I’ll look at tomorrow.
The “snap to previous grid line” option is added to the snap menu.
When an event drag operation has started, each press of the Ctrl key will toggle between phantom and unique copy. I think it works ok. Let me know what you think.
Thanks for the update. I don’t understand the point of “snap to previous grid line”, but “snap to closest grid line” works for me, it seems more consistent bacause when you drag a note horizontally it doesn’t “dance” (behavior that seems buggy).
Maybe you’re aware of this: If snap is on, and you click in the border of a note, then press shitf and you move the note you can do the note as tiny as you want. But if you start to resize the note without keeping down shift key and while resizing you press it you cannot do smaller than snap value.
And this is a suggestion, I would allow press shift key before click to resize, is more comfortable, despite the fact that pressing shift key is for select notes.
Thanks again for relative snap 🙂
@LiquidProj3ct wrote:
Thanks for the update. I don’t understand the point of “snap to previous grid line”, but “snap to closest grid line” works for me, it seems more consistent bacause when you drag a note horizontally it doesn’t “dance” (behavior that seems buggy).
Ok I understand it, it’s the snap behaviour. But when you move notes with relative snap “previous” options seems buggy. I did a small video:
http://www.youtube.com/watch?v=07O-58egWMw
Will be deleted once you see it 😉
When you import zReeverb the Mono version is confused as a Mono In version with one input and two outputs
Beta3 is up. This fixes two bugs:
@LiquidProj3ct wrote:
I don’t understand the point of “snap to previous grid line”, but “snap to closest grid line” works for me, it seems more consistent bacause when you drag a note horizontally it doesn’t “dance” (behavior that seems buggy).
Even though the jumping back and forth was highly confusing, I found it was actually correct behaviour when I debugged it. It happened because snap relative was still snap to “closest” relative position, so you would get a jump backwards when dragging across the grid line because that suddenly made the “snap to previous grid line” closer than the relative position. I’ve fixed this confusing behaviour by making the relative mode snap to “previous” relative position when the “snap to previous grid line” mode is enabled.
Maybe you’re aware of this: If snap is on, and you click in the border of a note, then press shitf and you move the note you can do the note as tiny as you want. But if you start to resize the note without keeping down shift key and while resizing you press it you cannot do smaller than snap value.
I was aware of it, and it is now fixed. Thanks.
@LiquidProj3ct wrote:
When you import zReeverb the Mono version is confused as a Mono In version with one input and two outputs
The “Mono In” indicates that it is stereo out instead of mono in/out. I’ve never heard of a reverb plugin that had mono output ❓