<_whitenotifier-8>
[scopehal] azonenberg opened issue #991: CDR refactoring: make CDR filter output sampled waveforms so we don't need to sample again in each downstream filter - https://github.com/ngscopeclient/scopehal/issues/991
<_whitenotifier-8>
[scopehal] azonenberg edited issue #991: CDR refactoring: make CDR filter output sampled waveforms so we don't need to sample again in each downstream filter - https://github.com/ngscopeclient/scopehal/issues/991
<_whitenotifier-8>
[scopehal] azonenberg 5a042b8 - ThunderScope: don't report interleaving as a possibility
<_whitenotifier-8>
[scopehal] azonenberg 2c69451 - ThunderScope: set all channels off by default in case any previous device users left a stale config there
<_whitenotifier-8>
[scopehal] azonenberg 06a24c2 - Converted all RemoteBridgeOscilloscope drivers (other than ThunderScope) to queued command API
<_whitenotifier-8>
[scopehal] azonenberg a50756c - ThunderScope: converted to queued command API, refresh reported sample rate when enabling a channel in case we had to lower it server side. Fixes #990.
<_whitenotifier-8>
[scopehal-apps] azonenberg 7f2f4bf - Update to latest scopehal
<_whitenotifier-8>
[scopehal-apps] azonenberg 5663421 - WaveformArea: refresh list of sample rates when disabling a scope channel
<_whitenotifier-8>
[scopehal-apps] azonenberg e522ec4 - StreamBrowserDialog: refresh if a scope's sample rate changes under us (from front panel changes while capturing, or enabling/disabling a channel making the currently selected rate unavailable)
<_whitenotifier-8>
[scopehal-apps] azonenberg 8c25b20 - Update to latest scopehal
<_whitenotifier-8>
[scopehal-apps] azonenberg 8da63c9 - Added some trace messages to PacketManager and HistoryManager. Fixed bug causing PacketManager to refresh twice any time new waveform data showed up, wasting time
<_whitenotifier-8>
[scopehal-apps] azonenberg e8bf968 - update to latest scopehal
<_whitenotifier-8>
[scopehal] azonenberg assigned issue #994: Build broken on macos due to std::from_chars not supporting float yet despite being a c++17 standard function - https://github.com/ngscopeclient/scopehal/issues/994
<_whitenotifier-8>
[scopehal] azonenberg opened issue #994: Build broken on macos due to std::from_chars not supporting float yet despite being a c++17 standard function - https://github.com/ngscopeclient/scopehal/issues/994
<_whitenotifier-8>
[scopehal] azonenberg edited issue #994: Build broken on macos due to std::from_chars not supporting float yet despite being a c++17 standard function - https://github.com/ngscopeclient/scopehal/issues/994
<_whitenotifier-8>
[scopehal-apps] azonenberg 07791e2 - Bug fixes and performance improvements to PacketManager and HistoryManager. Switched to lazy refreshes when a render occurs rather than doing it in the processing path. Fixed crash in StreamBrowserDialog during startup. Fixes #835.
<_whitenotifier-8>
[scopehal] azonenberg 7eb67d4 - ClockRecoveryFilter: use fp32 consistently for small intermediates to avoid constant float-int conversion so much
<d1b2>
<azonenberg> First round of sketches and reference images from the artist doing the application icon, looking for feedback. Goal is to pick one or more of the sketches on the first page, plus levels of realism/abstraction from the subsequent pages, as a starting point. We've already rejected "filter graph window A" as looking too much like the Keysight logo
<d1b2>
<azonenberg> @david.rysk @aleksorsist @lainpants @ckfinite if you have thoughts, i know some of you have seen this already but wanted to get all the discussion in one place
<d1b2>
<azonenberg> (and anybody else with feedback is welcome to chime in too)
<d1b2>
<ckfinite> my suggestion would be to focus on the scope allegory over eye diagrams since I feel like that's pigeonholing a little; I like the device metaphor or the filter graph concepts as a result
<d1b2>
<azonenberg> Thoughts on the filter graph connections? it seems a bit busy and overcomplicated the way it's drawn now but the concept might be worth running with?
<d1b2>
<azonenberg> (also @bryanlehrer, the artist, is in this channel so we can clarify things with him etc if needed)
<d1b2>
<aleksorsist> I like the idea of focusing on the filter graph as the thing that is uniquely ngscopeclient, but I don't particularly like any of the filter graph concepts so far
<d1b2>
<azonenberg> Do we want a more abstracted concept of just nodes and lines? like, the real graph doesnt have waveforms in it
<d1b2>
<aleksorsist> (also balanced with the need to show functionality - The graph without like a waveform or something would not convey much)