<d1b2>
<azonenberg> open feature request, not SUPER technically difficult... for most scopes it's basically just injecting a fake trigger event and forcing a waveform download
<d1b2>
<azonenberg> just requires someone who understands the acquisition flow well and isn't doing anything more important
<d1b2>
<josHua> I can make it happen again, it would just be annoying because I am too cheap for sensepeek probes and too lazy to solder to my board because I hope I will understand what is wrong if I get a single capture 🙂
<d1b2>
<azonenberg> i.e. either somebody with some spare time on their hands, or me at some point in the indefinite future :p
<d1b2>
<azonenberg> So we do support importing binary waveform files from most scopes
<d1b2>
<azonenberg> so if you just need it as a one-off right now, save to a thumbdrive and import the binary file offilne
<d1b2>
<azonenberg> pretty sure we support the rigol binary import format
<d1b2>
<azonenberg> anyway tl;dr it's one of several dozen "nice to have but not top of my priority list" things
<d1b2>
<josHua> yes, fair enough
<d1b2>
<azonenberg> that i will get to eventually unless somebody sends a PR first
<d1b2>
<josHua> hm the SPI decoder does not seem to like having CS# disconnected
<d1b2>
<azonenberg> Nope, the current decode requires CS# since it uses falling edges to synchronize to byte boundaries
<d1b2>
<azonenberg> (so it can't be directly used for the weird not-quite-spi flavors that have an end-of-message strobe or similar)
<d1b2>
<josHua> hm can I get a Step to have a negative step position?
<d1b2>
<josHua> a Step Position of 0 seems to be exactly at the trigger (relative to my hardware inputs), but I would like to have it be somewhat before the trigger
<d1b2>
<josHua> haha okay I gave it a Deskew, that did it
<d1b2>
<azonenberg> yeah all of the generation filters expect to start outputting samples at T=0
<d1b2>
<azonenberg> since most scopes have T=0 as the start of the waveform
<d1b2>
<josHua> interesting. so maybe my Xoffset was not correct. I specify T=0 as the trigger point
<d1b2>
<azonenberg> ... oh
<d1b2>
<azonenberg> No, that needs to get fixed to make it consistent with other scopes
<d1b2>
<josHua> ops.
<d1b2>
<azonenberg> The scopehal convention is that T=0 is start of the acquisition
<d1b2>
<azonenberg> then there should be a trigger arrow up top you can drag around anywhere within the window to move the trigger position
<d1b2>
<azonenberg> that the trigger offset controls
<d1b2>
<josHua> hm probably the above PR should be (partially) backed out in this case.
<d1b2>
<azonenberg> I'll keep it for now as it's better than no driver support, but please fix when you get a chance
<d1b2>
<azonenberg> The only time a scope should have a waveform not start at T=0 is if you are doing a multi-scope setup
<d1b2>
<azonenberg> and the second scope is set to trigger before the primary
<d1b2>
<azonenberg> (T=0 in this case is the start of the primary scope's acquisition)
<d1b2>
<josHua> the Rigol, on screen, declares T=0s to be the trigger
<d1b2>
<azonenberg> yeah but in order to present a consistent UI across scopes we have to deviate from what the scopes do in a lot of cases
<d1b2>
<josHua> yeah that is fine, that is just the source of my confusion
<d1b2>
<josHua> for now I am just using what I have to debug my problem 🙂
<d1b2>
<azonenberg> Fair enough
<d1b2>
<azonenberg> (meanwhile i'm neck deep in GUI refactoring ripping out thousands of lines of copy-pasted boilerplate that can be made much smaller)
<d1b2>
<josHua> using ngscopeclient as a digital SPI decoder definitely feels like using a tactical nuke to kill an ant
<_whitenotifier-3>
[scopehal-apps] azonenberg 1ccf05a - Removed all remaining AddInstrumentDialog-derived copypasta
<d1b2>
<azonenberg> lol
<d1b2>
<azonenberg> i once used a 16 GHz scope that is worth almost as much as my house to decode a uart
<d1b2>
<azonenberg> so...
<d1b2>
<azonenberg> in my defense it said "serial data analyzer" on the front panel and i needed to decode serial data :p
<d1b2>
<azonenberg> (and, more seriously, my other scope was out for service so it was this or nothing)
<d1b2>
<josHua> I have a Saleae Logic Pro 16 here, the probes are just the wrong shape for this unless I am willing to turn on the soldering iron
<d1b2>
<azonenberg> BTW did you notice the new contextual-help status bar?
<d1b2>
<azonenberg> any thoughts on it? any spots where i don't currently have a help message that you think it might be beneficial?
<d1b2>
<josHua> the help bar that tells me what the mouse buttons are oging to do?
<d1b2>
<azonenberg> yeah
<d1b2>
<josHua> I found this useful
<d1b2>
<azonenberg> it will eventually list contextual hotkeys, once we have them
<d1b2>
<azonenberg> i.e. shortcuts that apply to the object under the mouse rather than application global
<d1b2>
<duskwuff> "here I am, brain the size of a planet, and they ask me to…"
<d1b2>
<azonenberg> Lol
<d1b2>
<azonenberg> i mean i knew exactly what i was doing i just thought it was ludicrous
<d1b2>
<josHua> I have been fighting with the waveform viewer quite a bit; I have three linear input devices on my desk (a mouse, a Magic Trackpad, and a spacemouse), and the scroll wheels on the mouse are the best I've gotten so far, but I definitely wish I could pinch-to-zoom on the Magic Trackpad or use the spacemouse
<d1b2>
<josHua> (n.b.: many people will tell you that a space mouse is life changing for 3D cad. this is kind of true, but it is really life changing as a left-hand input device for KiCAD for me)
<d1b2>
<azonenberg> I'm not sure what pinch-to-zoom does as far as what messages it actually sends to the application
<d1b2>
<azonenberg> i'm all for adding support for new input deviecs
<d1b2>
<azonenberg> my biggest annoyance is getting my laptop touchpad to register drags on the outline of waveform groups
<d1b2>
<azonenberg> of filter groups*
<d1b2>
<azonenberg> so i might see about enlarging that hitbox
<d1b2>
<josHua> if you don't own one, get one, and spend a day using it in your favorite 3D CAD tool -- then spend a day using it in KiCAD. you will then be instantly motivated to add support for it to ngscopeclient. I have the cheapest one, the SpaceMouse Wireless Bluetooth Edition, and it is absolutely fine for everything I care about.
<d1b2>
<azonenberg> I have an elgato stream deck i bought planning to use to add support for ngscopeclient in
<d1b2>
<azonenberg> but i havent found the right use cases for more buttons yet
<d1b2>
<azonenberg> most of the time i find myself driving it almost entirely by mouse
<d1b2>
<josHua> yeah, life is whatever with more buttons, but life with more axes , man, it's what we needed
<d1b2>
<azonenberg> Lol
<d1b2>
<azonenberg> I'm normally a mouse-and-keyboard gamer but for microscopes, joysticks are where it's at
<d1b2>
<azonenberg> i have my CNC microscope set up with a logitech gaming joystick
<d1b2>
<azonenberg> x/y do what you'd expect, the hat on top controls focus as i found that easier to do without moving the x/y axes than twist
<d1b2>
<azonenberg> throttle controls motion sensitivity, trigger snaps a photo
<d1b2>
<josHua> oh that is pretty good
<d1b2>
<josHua> I probably woudl use Z for focus on the spacemouse, and probably not use any of yaw/pitch/roll
<d1b2>
<azonenberg> wrt pinch to zoom what exactly would you want it to do
<d1b2>
<azonenberg> behave like the scroll wheel does not?
<d1b2>
<azonenberg> now*
<d1b2>
<josHua> yeah, continuously and linearly
<d1b2>
<azonenberg> and does pinch not actually send scroll events?
<d1b2>
<josHua> it does not appear to
<d1b2>
<josHua> two finger scroll does send scroll events, both X and Y scroll
<d1b2>
<azonenberg> Do some digging, it's like two lines of code once i can actually trap the event
<d1b2>
<josHua> (it is hilarious but absolutely chaotic)
<d1b2>
<azonenberg> Lol
<d1b2>
<azonenberg> We can definitely do some work to make the input work better on touchpads
<d1b2>
<josHua> in a pinch to zoom world, you definitely do not want Y scroll to mean zoom
<d1b2>
<azonenberg> i wonder if there's a way to determine if the current input event is coming from a touchpad or a mouse
<d1b2>
<azonenberg> or if it'll have to be a preference
<d1b2>
<josHua> I have like zero knowledge of osx's input subsystem, but you definitely can know
<d1b2>
<azonenberg> yeah its more whether glfw exposes it to use in a useful way
<d1b2>
<azonenberg> or if we'll have to do ugly platform specific hacks
<d1b2>
<josHua> pinch and pan does work as I expect in KiCAD anyway
<d1b2>
<azonenberg> to us*
<d1b2>
<azonenberg> anyway, check the tracker but i dont think there is an issue for this
<d1b2>
<azonenberg> file an issue for more generally "better laptop touchpad support"
<d1b2>
<azonenberg> and we can spend some time thinking about what that will look like
<_whitenotifier-a>
[scopehal-apps] azonenberg 8386bc2 - Filter graph: Enlarged group border to make them easier to resize
<_whitenotifier-a>
[scopehal-apps] azonenberg f9f5775 - Removed lots of copypasta functions in MainWindow_Menus and replaced them with a single generic version