<d1b2>
<vipqualitypost> Is there an easy way to trim input data with filter graph (or other methods inside ngscopeclient)? I have some data which is starting with timestamp at 2 seconds, but ngscopeclient opens it with reference to 0, so there is 2 seconds of nothing which is messing up some measurements, I think.
<d1b2>
<azonenberg> That should not be breaking anything
<d1b2>
<azonenberg> The "deskew" filter applies a time shift to a waveform, if you do want to move it
<d1b2>
<azonenberg> but if any filters are malfunctioning on that dataset, that is a bug and i want to know about it
<d1b2>
<vipqualitypost> sure, I was feeding this into an FIR to BW limit to 20MHz and then RMS, but got nothing out of either the FIR or the measurement. (measurement worked on raw data)
<azonenberg>
ok i can reproduce some weirdness here
<azonenberg>
investigating
<d1b2>
<vipqualitypost> still want me to open an issue?
<azonenberg>
yes, please do. and include your dataset and screenshot if possible
<azonenberg>
anyway, the issue i am chasing now looks like a loss of precision with the deskew filter
<azonenberg>
i dont know exactly what is going on other than that it feels like rounding error
<_whitenotifier>
[scopehal-apps] azonenberg 789649a - WaveformArea: avoid numerical precision issues with large triggerPhase values by doing as much of the X offset calculation as possible using int64 rather than converting to float32 prematurely. Fixes #828.
<_whitenotifier>
[scopehal-apps] azonenberg a5d25c5 - Merge branch 'master' of github.com:ngscopeclient/scopehal-apps
<d1b2>
<azonenberg> @vipqualitypost so i just fixed a bug where i did some triggerPhase math in float32 domain rather than keeping it it as int64
<d1b2>
<azonenberg> which caused rounding errors and display glitches if you had a large triggerPhase
<d1b2>
<azonenberg> can you check if this has any impact on your #829 bug? your symptoms sound like they're probably something else and i just stumbled on this while looking for your bug
<d1b2>
<azonenberg> but if this fixes it, great
<d1b2>
<vipqualitypost> sure, give me a few
<d1b2>
<azonenberg> it's funny, this is one of the few projects i've worked on where full 64-bit precision is not only necessary but sometimes not even enough
<d1b2>
<azonenberg> like, if you want to be able to work on waveforms more than a couple of hours long
<d1b2>
<azonenberg> like trends of some variable over time
<d1b2>
<azonenberg> but also have the dynamic range to do clock recovery PLLs on 100GbE
<d1b2>
<azonenberg> int64 dynamic range is not sufficient
<d1b2>
<azonenberg> which is why down the road i want to start adding a scaling factor to units so that rather than e.g. all of our time being measured in femtoseconds
<d1b2>
<azonenberg> we can have a waveform where the base time unit is picoseconds or hundreds of nanoseconds or whatever
<d1b2>
<azonenberg> and you trade off resolution in exchange for being able to represent much larger amounts of time
<d1b2>
<azonenberg> (i have no immediate plan to explore int128 timestamps)
<d1b2>
<azonenberg> this scaling factor can also be fractional
<d1b2>
<azonenberg> for example, right now we have no way to represent frequencies with <1 Hz granularity
<d1b2>
<azonenberg> and we have ugly hacks where there are units for volts, millivolts, and i think microvolts
<d1b2>
<azonenberg> because the y axis is float32 and the x is int64 and so if you want an x/y plot of voltage in X, like for a bathtub curve or something, you can't actually use the "volt" unit
<d1b2>
<azonenberg> anyway none of that is happening for v0.1 but it's on the roadmap :p
<d1b2>
<vipqualitypost> yeah, have noticed the weirdness about trying to mix some of these units
<d1b2>
<vipqualitypost> weird, after a fresh pull (my build was a little old) I get this : -- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) (found version "5.0") -- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES) (found version "5.0") -- Could NOT find OpenMP (missing: OpenMP_C_FOUND OpenMP_CXX_FOUND) CMake Error at CMakeLists.txt:147 (message): ngscopeclient requires OpenMP but your C++ compiler does not
<d1b2>
appear to support it.
<d1b2>
<vipqualitypost> What is it finding if it is saying it does not support?
<d1b2>
<azonenberg> um, that's new @david.rysk
<d1b2>
<azonenberg> what platform are you on?
<d1b2>
<azonenberg> also what cmake version are you using
<d1b2>
<vipqualitypost> apple silicon
<d1b2>
<vipqualitypost> cmake 3.29
<d1b2>
<azonenberg> ok so it's not related to the cmake 4.0 breakage we're fighting on windows
<d1b2>
<azonenberg> hmm, i know openmp on mac was a bit wonky but i thought we had solved that
<d1b2>
<vipqualitypost> yeah, me too
<d1b2>
<vipqualitypost> i had issues for a bit but haven't recently had any problems with it
<d1b2>
<vipqualitypost> maybe i broke something
<d1b2>
<azonenberg> yeah poke around. i'm actually going to file some tickets for cleanup related to this though
<d1b2>
set(OpenMP_omp_LIBRARY "/opt/homebrew/opt/libomp/lib/libomp.dylib") endif() before the libomp search and now things are working. I don't understand what changed about the brew installation of libomp that this is required? solution from here: https://github.com/stella-cv/stella_vslam/issues/578#issuecomment-2673184480
<d1b2>
<azonenberg> File a ticket with that info and i'll have @lainpants look at it, she's got a bunch of mac build stuff pending