Feature: tempo editing in the MiscWidget #19
Conversation
|
Thanks a lot! Great idea to add the tempo in this widget! Two comments: This screenshot was taken after using line mode once up and once down. The latest line should be permanent, and the end point set the tempo until the very next tempo change event. 2.) Could you add an update to the manual? I think there's either a description about tempo changes, but there should also be a section about the misc widget. |
|
Oops, looks like I have some debugging to do. I didn't think to test the freehand and line modes since I'm most interested in editing existing events myself, and was very closely basing the tempo code on the existing code for editing controllers, etc. I must have missed a case. I'll also do the manual bits. |
|
Thanks for fixing! |
|
Note to self: probably coming from the X coordinate of later events
changing when a tempo event is inserted. May need two passes, one to
compute where all the events of a drag gesture should be inserted
(translating from pixels to midi ticks based on existing events), then a
second pass to do the inserts. Other event types don’t affect the
linearity pf the X axis, which is why symmetry in the code wasn’t
sufficient.
…On Sun, Sep 15, 2019 at 5:38 AM markusschwenk ***@***.***> wrote:
Thanks for fixing!
However, I still end up with max tempo sometimes (was not able to figure
out a way to always reproduce) at the end of the time frame I modified
using free-hand or linear tool. Could you check?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#19?email_source=notifications&email_token=ADBFD3VCGLHNMAZU7SCX2M3QJX675A5CNFSM4IS5UHXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6XNCUQ#issuecomment-531550546>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADBFD3UDFOYGCCUGKFYHYATQJX675ANCNFSM4IS5UHXA>
.
|
The two pass approach didn't help, and made lines which were drawn straight actually appear curved when you released the mouse. The problem actually appeared to be coming from needing to handle points a little beyond the end of the "toAlign" array, so I had to make the interpolate function extrapolate off the right end of that line. Also fixed a problem with inserting lots of "minimum possible value" events if the user released the mouse below the bottom edge of the window.
|
Nope, still no good. The extrapolation is causing some undesirable effects. I'll keep poking at it. |
…es correctly In particular, I still need to figure out what the righthand bound of the range should be for removing the old events. maxTick isn't correct, even if you recompute it as xPosToTock(toAlign.last().first) each time you go around the loop, because the end point depends on the tempo events you're going to insert not the ones which are already there. I may need to intersperse the remove and add rather than having them in separate loops.
What you draw is evaluated in the context of what's already there, so that means that a tempo line which you draw straight will end up curved once you release the mouse. That's unintuitive, but I'm starting to think it's not actually a bug, just an accurate reflection of what the straight line really means.
No description provided.