Open gsxdsm opened 3 weeks ago
Nevermind this works
Well it works, but its pretty buggy
The main bugginess is when you are using the range tool - the event for the command modifier causes the range selector to snap which then leads to a laggy/glitchy experience.
I was able to fix this:
In Extensions.swift, add additional enum for Phase
enum Phase: Int64 {
case none = 0
case began = 1
case cont = 2
case end = 4
case other
}
In EventMapping.swift, only send key up event when the phase is end:
case .wheel:
let originalEvent = event
let originalFlags = event.flags
let event = CGEvent(scrollWheelEvent2Source: nil, units: .pixel,
wheelCount: 1, wheel1: Int32(steps), wheel2: 0, wheel3: 0)!
event.flags = flags
CGEvent(flagsChangedEventSource: nil, flags: flags)!.tapPostEvent(proxy)
event.tapPostEvent(proxy)
if originalEvent.phase == .end {
CGEvent(flagsChangedEventSource: nil, flags: originalFlags)?.tapPostEvent(proxy)
}
return nil
Hmm, this doesn't seem to be reliable - still working on this
The issue is that sometimes the .end phase doesn't get fired.
Okay the issue is with the setting - Tools -> Select Tool: Show Extra Info
When this is on, the initial command keydown causes the overall scroll/zoom to be laggy/glitchy because of the rendering of the selection point and info box (when the cursor is over a Midi Part).
Turning this setting off makes pinchbar work as expected. Still trying to see if I can correctly detect the start/end of the gesture to only send the command down at the start and command up at the end.
Hi gsxdsm, thank you for the detailed information! I just signed up for Cubase 14 beta programme and have to wait for approval before I can debug this issue. I could not reproduce it within Cubase 13 with activated "Tools -> Select Tool: Show Extra Info" on my M3 Pro MBP14. Which model are you working on? Can you confirm this issue is not present in Cubase 13?
In EventMapping.swift, only send key up event when the phase is end:
case .wheel: let originalEvent = event let originalFlags = event.flags let event = CGEvent(scrollWheelEvent2Source: nil, units: .pixel, wheelCount: 1, wheel1: Int32(steps), wheel2: 0, wheel3: 0)! event.flags = flags CGEvent(flagsChangedEventSource: nil, flags: flags)!.tapPostEvent(proxy) event.tapPostEvent(proxy) if originalEvent.phase == .end { CGEvent(flagsChangedEventSource: nil, flags: originalFlags)?.tapPostEvent(proxy) } return nil
This section of code stems from e64136ba which fixed an issue with Cubase 13. Until Cubase 12, it was unnecessary to post flagsChangedEvents. With Cubase 13, Steinberg implemented new scroll wheel zooming options that rely only on flags changed events and ignore scrollwheel event flags. Maybe Steinberg fixed this implementation and you could get away with reverting e64136ba?
Hm, I signed up for Cubase 14 pro trial version and tested my recent Cubase projects with the settings you described (Tools -> Select Tool: Show Extra Info)
I cannot reproduce your issue, meaning i don't see no glitches in Cubase 14, regardless of hovering midi tracks with the mouse cursor, other tracks or just empty space.
This was tested both on MBP M3pro and on a very old Intel core i5 MBP from 2015, so I suppuse it's not just a performance issue.
So, more detailed information needed here, regarding hardware, Cubase configuration and maybe the project file. Could you please zip and share your Cubase settings folder (see this page)
Doens't seem to work with Cubase 14