azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #scopehal
<_whitenotifier> [scopehal-apps] azonenberg closed pull request #783: Fix Typo in PreferenceSchema.cpp - https://github.com/ngscopeclient/scopehal-apps/pull/783
<_whitenotifier> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-apps/compare/634969544d80...9d7cb55b82a8
<_whitenotifier> [scopehal-apps] azonenberg 9d7cb55 - Merge pull request #783 from laminar-oss/Fix-Typo-in-PreferenceSchema Fix Typo in PreferenceSchema.cpp
<d1b2> <azonenberg> @fredzo_72653 @josHua are either of you actively working on https://github.com/ngscopeclient/scopehal-apps/issues/775 ?
<d1b2> <josHua> Not I.
<_whitenotifier> [scopehal-apps] jwise commented on issue #775: Sidebar "triggered" / "armed" badges can flicker very rapidly with some WFM/s speeds - https://github.com/ngscopeclient/scopehal-apps/issues/775#issuecomment-2412706576
<_whitenotifier> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-apps/compare/9d7cb55b82a8...c4f747c75a81
<_whitenotifier> [scopehal-apps] azonenberg c4f747c - Merge pull request #782 from fredzo/stream-browser-psu-toggle-combo PSU switch change to a combo-based toggle
<_whitenotifier> [scopehal-apps] azonenberg closed pull request #782: PSU switch change to a combo-based toggle - https://github.com/ngscopeclient/scopehal-apps/pull/782
<d1b2> <azonenberg> Ok well i think i'm going to work on that shortly. But before i do that, i'm gonna work on implementing the progress callbacks for VICP so i can get progress bars on my lecroy scopes
<d1b2> <azonenberg> Which are nice and fast at shallower memory but with tens of megapoints get slow enough a progress bar would definitely be nice
<_whitenotifier> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±22] https://github.com/ngscopeclient/scopehal/compare/09c295bdcfed...32547e7f28a3
<_whitenotifier> [scopehal] azonenberg 88245bb - Began work on LeCroy waveform download progress reporting
<_whitenotifier> [scopehal] azonenberg 32547e7 - LeCroy: implemented download progress callbacks
pirate has joined #scopehal
<d1b2> <fredzo_72653> I am not, I moved to HID transport support with hidapi
<d1b2> <azonenberg> Ok great so i'm not going to step on either of you
<_whitenotifier> [scopehal-apps] azonenberg assigned issue #775: Sidebar "triggered" / "armed" badges can flicker very rapidly with some WFM/s speeds - https://github.com/ngscopeclient/scopehal-apps/issues/775
<_whitenotifier> [scopehal] azonenberg opened issue #918: LeCroy: trigger position is wrong after changing memory depth - https://github.com/ngscopeclient/scopehal/issues/918
<d1b2> <azonenberg> @josHua @fredzo_72653 Let's start thinking about splitting up the render method in StreamBrowserDialog a bit to make the code a bit easier to follow
<d1b2> <azonenberg> i don't like having thousand-line functions 🙂
<d1b2> <azonenberg> And there's gonna be a lot more content being added to it soon
<d1b2> <azonenberg> I might work on that tomorrow before i do 775
<_whitenotifier> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal/compare/32547e7f28a3...e930e4f130b7
<_whitenotifier> [scopehal] azonenberg e930e4f - LeCroyOscilloscope: invalidate cached trigger position when changing memory depth. Fixes #918.
<_whitenotifier> [scopehal] azonenberg closed issue #918: LeCroy: trigger position is wrong after changing memory depth - https://github.com/ngscopeclient/scopehal/issues/918
<d1b2> <josHua> could be nice. I am sure there is some kind of C++ shenanigan that would allow this to be defined in an overloadable way without having to explicitly write every overload-possible type somewhere
_whitenotifier has quit [Ping timeout: 276 seconds]
<d1b2> <azonenberg> yeah i'm gonna think about it
<d1b2> <azonenberg> splitting instruments and filters will be the first step
pirate has quit [Ping timeout: 252 seconds]
pirate has joined #scopehal
<d1b2> <josHua> @azonenberg this reminds me of a few other things that I was thinking about yesterday. for one, now that not everything in the stream browser is actively draggable, it brings me back to the idea of having an interfacebuilder-style metaphor of 'outlets' and 'actions', where there are visible icons (usually) for 'this thing can be dragged as a source', and 'this thing is a target that you can drag to'
<d1b2> <josHua> in the back of my mind, I was thinking that everything that created a stream should have a representative icon of the stream in question, and everything that accepted a stream might want to have such an icon too. consider:
<d1b2> <josHua> in the back of my mind, I was thinking that everything that created a stream should have a representative icon of the stream in question, and everything that accepted a stream might want to have such an icon too. consider the following icons, where the stream behavior is represented by the icon. any Hz-> could be dragged onto any ->Hz icon, for instance.
<d1b2> <josHua> the other thing that I was thinking about was that it was sort of nonobvious to me that waveform viewers were not represented in the filter graph
<d1b2> <azonenberg> Sooo
<d1b2> <azonenberg> that is acutally something i am thinking of changing
<d1b2> <azonenberg> Making a WaveformArea be a FlowGraphNode
<d1b2> <azonenberg> i think there is a ticket for it
<d1b2> <azonenberg> it's not a v0.1 issue, and i'm not 100% i want to do it
<d1b2> <azonenberg> or how
<d1b2> <azonenberg> (in particular WRT the amount of clutter it would cause displaying different signals in one plot)
<d1b2> <azonenberg> But i think at least on the back end it would make more sense
<d1b2> <azonenberg> So right now internally
<d1b2> <azonenberg> streams can be of type analog waveform, digital waveform, analog scalar (digital scalar doesnt exist, but will soon), eye pattern, waterfall, spectrogram, or protocol
<d1b2> <josHua> and also things can arbitrarily reject streams that you try to drag to them, IIRC
<d1b2> <azonenberg> Correct. That is something i want to redo too
<d1b2> <azonenberg> right now the only way to know what datatypes an input wants is to call ValidateChannel with a proposed stream
<d1b2> <azonenberg> and you get a go/no go answer
<d1b2> <azonenberg> there is no visibility into why it rejected it, or what it wants
<d1b2> <azonenberg> i want to switch to a more data driven model where an input advertises what it accept
<d1b2> <azonenberg> again, not a v0.1 issue
<d1b2> <josHua> it is a shame gstreamer is not a compatible license for your goals. it pretty effectively provides a framework to solve most of this
<d1b2> <azonenberg> We can still borrow high level architecture from it
<d1b2> <josHua> yeah, it is worth thinking about
<d1b2> <azonenberg> anyway, there's a bunch more work to do on the sidebar for sure
ALTracer has joined #scopehal