azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
bvernoux has quit [Quit: Leaving]
XMPPwocky has quit [Quit: Bridge terminating on SIGTERM]
mikolajw has quit [Quit: Bridge terminating on SIGTERM]
sajattack[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark has quit [Quit: Bridge terminating on SIGTERM]
sajattack[m] has joined #scopehal
XMPPwocky has joined #scopehal
mikolajw has joined #scopehal
whitequark has joined #scopehal
bvernoux has joined #scopehal
<_whitenotifier-e> [scopehal] azonenberg opened issue #600: Resolution enhancement filter - https://github.com/glscopeclient/scopehal/issues/600
<_whitenotifier-e> [scopehal] azonenberg labeled issue #600: Resolution enhancement filter - https://github.com/glscopeclient/scopehal/issues/600
<d1b2> <louis> Aborting and indicating failure due to incompressability certainly seems like a fine place to start. Partial capture seems more useful... there's no UI trickery involved with glscope as the display since hdiv isn't coupled to capture length
<d1b2> <louis> The case of highly compressible data before trigger (say, all zeros) and poorly compressible after (some burst transfer) seems totally plausible
<d1b2> <louis> (Sorry to come back to that loop days later; It's finals for me 🤓 )
<d1b2> <louis> I want to bring the diagnostics window branch into main sooner or later. I will do a little more cleaning here and PR it shortly. Want to know your thoughts on graph window UX re: (1) one window and graph per parameter, or (2) one window and multiple graphs, or (3) one window, one graph, multiple series for different graphed parameters
<d1b2> <louis> Also, right now the graphs are redrawn / displayed parameters updated every frame of the main OscWindow. We could instead be using the change signal facility on FilterParameters to update them in an event-driven fashion whenever the relevant debug param is changed. I think that would be better; any reason not to?
<d1b2> <louis> (This would be useful for, e.g., diagnostics within a single capture, such as the progress of a chunked CURV? transfer on the rewritten Tek driver)
bvernoux has quit [Quit: Leaving]
<azonenberg> Event driven changes make sense, yes
<azonenberg> as far as UX goes, one window multiple graphs i think is best
<azonenberg> But also just keep in mind this is a debug tool
<azonenberg> it doesnt have to be quite as polished as the user facing stuff