<_whitenotifier-3>
[scopehal-apps] azonenberg d304401 - Various improvements to cursor handling. Enlarged hitbox, fixes #734. Cursors no longer react to mouse clicks inside popup menus.
<_whitenotifier-3>
[scopehal-apps] azonenberg 80e0682 - More improvements to cursor and marker mouse input; cursors no longer incorrectly process mouse events if the mouse is over a marker
<d1b2>
<fredzo_72653> Hi Andrew, 🔼 this is my attempt to enhance DHO800/900 support and to fix DHO1000/4000 support. Please let me know what you think !
<d1b2>
<azonenberg> the scope can return a null sample rate, lovely lol
<d1b2>
<azonenberg> yeah it makes sense to handle that in the driver, waveforms are always expected to have a valid sample rate and if it doesn't crash there it'll throw problems in some other filter block or whatever
<d1b2>
<azonenberg> also eeew model numbers that don't cleanly encode the bandwidth
<_whitenotifier-3>
[scopehal-docs] azonenberg 57ab2b6 - Merge pull request #85 from fredzo/master Updated Windows compilation documentation
<d1b2>
<azonenberg> @fredzo_72653 also please send a companion doc PR updating the supported models for the rigol driver
<d1b2>
<azonenberg> @fredzo_72653 so the issue i have with the live mode setup you have is what happens if >1 channel is enabled?
<d1b2>
<azonenberg> we've generally avoided using "run" mode on most scopes because of the potential for desynchronization where you download channel 1's waveform from trigger N and channel 2 from trigger N+1
<d1b2>
<azonenberg> and i don't see any way you're preventing that here
<d1b2>
<fredzo_72653> @azonenberg ah OK no you're right, nothing prevents that from happening... I've successfully tested live mode with 4 channels activated, but nothing guarantees that all 4 channel come from the same trigger time 😕
<d1b2>
<fredzo_72653> Should I lmiit live mode to one channel setup ?
<d1b2>
<azonenberg> I'm fine with enabling it if only one channel is active
<d1b2>
<azonenberg> we can look at doing that on other scopes too if it improves performance
<d1b2>
<azonenberg> But generally speaking it's a difficult race condition to deal with
<d1b2>
<azonenberg> a very small handful of scopes have some kind of baked in synchronization mechanism where the scope buffers all the data after a trigger and lets you download it later. but most of the time if it exists it's because we designed it that way ourselves and it's an open hardware scope :p
<d1b2>
<fredzo_72653> OK I'll update the PR in that way + create a PR to update the doc
<d1b2>
<fredzo_72653> Thx for the feedback
<d1b2>
<azonenberg> In general i want ngscopeclient to be as fast as possible, but not at the expense of correctness
<d1b2>
<azonenberg> first and foremost this is a debug and measurement tool and the last thing we want to do is lead our users astray with incorrect measurements