<d1b2>
[opt] frame #12: 0x0000000101725518 libscopehal.dylib`sigc::internal::signal_emit<void, void>::emit(impl=<unavailable>) at signal.h:366:7 [opt] frame #13: 0x00000001018ddbfc libscopehal.dylib`FilterParameter::ParseString(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, bool) [inlined] sigc::signal_with_accumulator<void, void>::emit(this=<unavailable>) const at signal.h:493:12 [opt] crash while trying
<d1b2>
to import a CSV with frequency,dB data
<d1b2>
<josHua> joshua@samskara:~/work/scopehal/scopehal-apps/build$ head -n4 dho4000_spectrum_mag.csv Frequency (Hz),Amplitude (dB) 10004121,0.0 30010932,-0.06460313776179083 50017743,-0.11642853553906152
<azonenberg>
hmm interesting. i'll have a look, if nothing else we shouldnt be aborting with throws on malformed csv
<azonenberg>
file a ticket, at minimum we should abort the parsing and continue running the app
Degi has quit [Ping timeout: 252 seconds]
Degi has joined #scopehal
<d1b2>
<azonenberg> @fredzo_72653 @josHua So i'm probably going to merge this as is once i finish reading unless i find any major issues. I do have some requests for you to do soon though
<d1b2>
<azonenberg> first, don't hard code colors and add preferences for them as needed
<d1b2>
<azonenberg> second, don't hard code dimensions because this causes problems with large fonts, hi-dpi, etc. always make UI elements be scaled as a function of the font size
<d1b2>
<josHua> ACK on both counts
<d1b2>
<azonenberg> (i'd rather have it merged without those changes than continue to diverge though, because i want to start building on your work sooner rather than later)
<d1b2>
<azonenberg> Oh and since this is modern C++ use nullptr rather than NULL in new code
<d1b2>
<josHua> is it preferred to test for equality with nullptr or just use a pointer as truthy?
<d1b2>
<azonenberg> I have no preference
<d1b2>
<azonenberg> depends on what you think makes the code more readable
<d1b2>
<josHua> I always prefer pointers to be truthy 🙂
<d1b2>
<azonenberg> @josHua Just pulled your PR into my local dev copy, going to poke at it a bit
<d1b2>
<azonenberg> One -Werror build failure, looks like an easy fix
<d1b2>
<azonenberg> Let's see... It doesn't handle multiple streams well
<d1b2>
<azonenberg> i think you're not using unique imgui ids here
<d1b2>
<azonenberg> probably an easy fix i'll look into it shortly
<d1b2>
<azonenberg> i also think we probably should not expand the tree nodes for channels by default, or maybe gate the default-expand by channel count or something
<d1b2>
<azonenberg> ok yeah that was a non-unique-ID issue
<d1b2>
<azonenberg> I have one of my lecroy scopes triggering at ~8 WFM/s right now and the "triggered" / "armed" flickering constantly is really annoying
<d1b2>
<azonenberg> so we definitely need a way to gate that
<d1b2>
<azonenberg> I hit "stop" on the lecroy and the badge is stuck in the "triggered" state
<lethalbit>
The Rigol DS1054's do that too, flashing between RUN/STOP and SINGLE on each captuer and getting a pretty low WFM/s even on lower memory depths and it's just worse and worse for higher depths,
<d1b2>
<azonenberg> (while triggering)
<lethalbit>
the LXI interface is awful
<azonenberg>
lethalbit: i specifically meant using the new stream browser code
<azonenberg>
having the badge in ngscopeclient flickering is intolerable to me
<lethalbit>
oooh,
<azonenberg>
So we need some way to pulse-stretch state changes
<lethalbit>
yeah fair
<lethalbit>
I only half-read, sorry :v
<lethalbit>
just woke up
<azonenberg>
i.e. any toggles faster than X Hz need to render as a steady "active" state
<lethalbit>
yee, fair
<lethalbit>
Oh, I built a fresh copy last night, liking the UI changes so far
<lethalbit>
there are still some floating window management issues, where sometimes they'll just, get *suck* on a desktop and be unable to be moved or closed, so that's fun
<azonenberg>
oh fun
<azonenberg>
i know there are a few windows, like BERT properties
<azonenberg>
that you can close and never get back
<azonenberg>
there's no way to reopen them
<lethalbit>
oof
<azonenberg>
but most of those were slated for folding into the stream browser
<_whitenotifier>
[scopehal-apps] jwise d448bbd - WIP: StreamBrowserDialog gets support for some rich UI on oscilloscopes
<_whitenotifier>
[scopehal-apps] jwise 444643f - refactor info link, to be used elsewhere soon
<_whitenotifier>
[scopehal-apps] jwise 51a63c9 - refactor renderBadge, and only render a badge if there is enough space, and fall back on a shorter string if there is not
<_whitenotifier>
[scopehal-apps] ... and 20 more commits.
<joshua_>
azonenberg, we could do the pulse-stretching thing on triggered/armed -> running. I guess that could be done with a token bucket or something. can you file a bug for that?
<joshua_>
or with analogous hysteresis around retriggering time
<azonenberg>
joshua_: yeah we can work out the specifics of exactly how to do it later
<azonenberg>
but it can't stay like this :p
<joshua_>
yep
<joshua_>
I have a bunch of things I need to do over the next few weeks associated with preparing the X1Plus Expansion Board for launch, so I am not sure how much ngscopeclient bandwidth I am going to have
<azonenberg>
I'm working on adding performance profiling to the filter graph so i have a centralized way to track how long each filter is taking to run to find targets for optimization without needing to be running VTune all the time
<azonenberg>
then will start doing some serious work on the sidebar
<_whitenotifier>
[scopehal-apps] azonenberg 5711d44 - MainWindow: fixed some bugs related to handling of null transport in in add-instrument menu. Fixes #777.