Zynewave's Forum Page

Hmm, this is a mess :-k

Reassigning Shift+Alt for x/y position drag lock, as I suggested earlier in this topic, will not work. In the arrangement editor you would press and hold Shift+Alt while dragging, as a combo for dragging a phantom copy of a sequence/sound (Alt), and lock the drag direction (Shift) at the same time. There are just limits to how much functionatliy can be piled onto the Shift+Control+Alt keys.

How about I reassign the shortcut key for snap on/off to A instead of T? That should make it easier to reach when you have your hand near the Shift/Ctrl/Alt keys. Note that A would still toggle snap mode. You cannot hold down the A key to temporarily disable snap.

While thinking about this, I had an idea that could make it much easier to do all sorts of drag operations:

Imagine you have made an event selection. You then right-click anywhere you like (most likely near your selection), and what appears is a translucent circular panel containing a number of handles arranged around the edge of the circle. The handles in the circle would be shortcuts for: moving, moving without snap, resizing, resizing without snap, fade-in/out, gain, snap point, note velocity, etc. The available drag actions could be customized by the user.

So basically you right-click, and then left-click+drag a handle on the circular panel, instead of left-click+dragging a handle on the event. The panel will pop up so that the last used handle will appear under the mouse, so if you’re doing a series of gain-adjustments on sound events, it’s a quick right/left click to start dragging the gain value. This panel would solve the problem of having more drag actions than can be activated with key shortcuts. It would also offer easily accessible drag handles, in case you have zoomed out so far that it would be difficult to hit the normal smaller handles on the event. It would also work well with touchscreen interfaces. 😉

Crazy idea?

@LiquidProj3ct wrote:

Frits, I’ve thinking and ignore snap shorcut should act before start the movement, because imagine a note like this:

If you want to move the note start or end a little to fix something in a melody, if you start dragging without ignore snap shortcut you will lose the clue about where was exactly the start or end of the note.

So the solution would be that if the cursor is over events (not free piano roll / arrangement space) or in its border shift key works as ignore snap before click.

You would only need to click, and then press Shift, before starting to drag. Thus you can avoid that it snaps before you press Shift.

I don’t like having an alternative behaviour of the Shift key depending on whether your mouse is over an event. I often use the Shift+Click+Drag marquee selection to quickly select a bunch of events. I’d like to be able to do this without worrying whether I clicked on an event.

@LiquidProj3ct wrote:

@Zynewave wrote:

Can’t it sometimes be confusing to have both snap modes enabled? For example, if you have an event that is very close to the grid line, it would be very hard to see whether you have dragged it so that it snaps absolute to the grid, or relative.

No 🙂 In theory you can believe can be some problems, but in the practise you discover that you always see where you’re snapping, even 1 pixel. While Podium hadn’t relative snap I had to use Reaper or FL Studio to do it, and that’s my experience.

If the event is very close to the grid line (but not on it), there may be zero pixels difference. Depending on which side of the grid line you drop it, the event will be snapped absolute or relative, but you won’t have a visual indication of which. My point is that I would like some indication while dragging, whether the current mouse position snaps absolute or relative to the grid. It could be done by highlighting the vertical grid line when snapped absolute. I’ll think about that.

If I decide to support it, it certainly will be optional. It’s likely that some will dislike snap working both for absolute and relative positions. You get twice the number of snap points when dragging events, and thus it can be harder to drop events precisely. Anyone else have an opinion on this?

@LiquidProj3ct wrote:

Thanks you for try it. Please watch this video, it’s a rar file, it compressed the video from 1.300Kb to 50Kb 😮

When I click the link you provided it says the file is temporarily unavailable?

Edit: And now it’s available.