<_whitenotifier-3>
[scopehal-apps] azonenberg ced1057 - Initial skeleton code for "lab notes" feature. Added imgui_markdown submodule. See #659.
<_whitenotifier-3>
[scopehal-apps] azonenberg fe70cb9 - Initial work on lab notes dialog and markdown editor integration. See #659.
<_whitenotifier-3>
[scopehal-apps] azonenberg 26a8e51 - Lab notes are now saved and loaded with sessions, but not displayed during loading. See #659.
<_whitenotifier-3>
[scopehal-apps] azonenberg 7d7558f - Lab setup notes, if present, are now displayed on the "speed bump" screen when loading a new session file. Fixes #659.
<d1b2>
<azonenberg> @hansemro please check two-level trigger support and make sure it does what you expect
<d1b2>
<azonenberg> i tested briefly with a few on my lecroys
<d1b2>
<azonenberg> note that i enforce a strict invariant that the upper level is above the lower
<d1b2>
<azonenberg> so if you drag the trigger arrows across each other they'll trade places
<d1b2>
<hansemro> I'll check it out soon.
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #scopehal
<d1b2>
<hansemro> It seems to work really well when the trigger dialog window is closed. However, when the trigger dialog window is up and you drag upper/lower trigger level, the cursor returns to original value. This does not seem to affect triggers with only one level.
<d1b2>
<azonenberg> the cursor returns to its original value if the dialog is open? innnteresting. can you record a video or something so i can compare that to what i see on lecroy?
<d1b2>
<hansemro> sure
<d1b2>
<hansemro> By original value, I mean previous trigger level.
<d1b2>
<louis8374> I could do most any day after this Thu
<d1b2>
<azonenberg> We were talking about next Monday, the 11th
<d1b2>
<azonenberg> Not yesterday
<d1b2>
<louis8374> D'oh. That should work fine
<d1b2>
<azonenberg> Lol
<d1b2>
<azonenberg> @bvernoux Can you have a look at the stuff in the top level CMakeLists.txt that has some fixes for "includes are incomplete in vulkan SDK" and see if the latest SDK release is still affected?
<_whitenotifier-3>
[scopehal-apps] azonenberg c5ba614 - Changed a few more glscopeclient references to ngscopeclient, stop building/linking to scopeexports as it's deprecated
<_whitenotifier-3>
[scopehal-apps] azonenberg 9fd1a71 - Link to cairomm instead of gtkmm since we no longer use GTK. Bump MacOS Vulkan SDK version number in CI scripts
<d1b2>
<azonenberg> ok now let's see what this rboke lol
<d1b2>
<azonenberg> I just removed the last vestiges of GTK dependencies in the build flow. We had been pulling in all of GTK just to link to cairo in a few spots
<d1b2>
<azonenberg> so i removed that and added cairo as an explicit dependency
<d1b2>
<azonenberg> which should speed builds as there's less junk being pulled in
<_whitenotifier-3>
[scopehal-apps] azonenberg 100cf8a - Fixed another GTK -> Cairo include path
<d1b2>
<bvernoux> I have done a quick diff between C:\VulkanSDK\1.3.250.1 & C:\VulkanSDK\1.3.268.0 and it seems they have added the missing files in 1.3.268.0 at least glslang.exe in Bin and C:\VulkanSDK\1.3.268.0\Include\glslang\Include\glslang_c_interface.h & glslang_c_shader_types.h
<d1b2>
<azonenberg> so can you test what happens if you delete that section in the cmakelists? does it still build reliably on windows?
<d1b2>
<azonenberg> @bvernoux also are you going to be able to make the developer meeting? next monday 0900 Pacific
<d1b2>
<azonenberg> which is i think monday afternoon for you
<d1b2>
<bvernoux> Something is still messed up when removing steps "Includes are incomplete in VulkanSDK 1.3.224.1 so we use the include path from MINGW64 mingw-w64-x86_64-glslang" and building without glslang stuff with Vulkan 1.3.268.0 C:/msys64/home/bvern/scopehal-apps/lib/VkFFT/vkFFT/vkFFT.h:38:10: fatal error: glslang_c_interface.h: No such file or directory 38 | #include "glslang_c_interface.h" | ^~~~~~~~~~~~~~~~~~~~~~~
<d1b2>
<azonenberg> ok so we'll leave that in for now
<d1b2>
<azonenberg> yeowch the graph editor docs are waaaay out of date i need to update that next lol
<azonenberg>
also the latest PDF doc is up to 268 pages. But 116 of those are filters that are just a heading and maybe a sentence of text but no real meat
<azonenberg>
So it seems like the analog discovery pro now supports much more reasonable memory depths, up to 32 M samples
<azonenberg>
that's high enough i am definitely going to want to make use of it. i also want to try and get it set up with an embedded server using the gig-e port
<azonenberg>
this might actually become something i am going to use as a secondary scope on my other bench
<d1b2>
<david.rysk> > In addition to the up to 13 built-in instruments enabled by WaveForms, the Analog Discovery Pro introduces Linux Mode. Linux Mode provides an on-device terminal-based operating system that, when combined with WaveForms SDK, is a flexible starting point for all kinds of custom tests and applications. Running embedded on the device itself or via WaveForms, engineers and measurement enthusiasts alike can take advantage of data streaming via
<d1b2>
ethernet, and the on-device storage to capture buffers of millions of samples.
<d1b2>
<david.rysk> huh
<azonenberg>
they sent me an eval unit a while back but the software has improved since then
<azonenberg>
being able to leave the thing on a bench hanging off the LAN and just hook up to it over ethernet would be super convenient
<azonenberg>
i have a scopehal-waveforms-bridge component that i could probably port to run on the thing pretty quickly
<azonenberg>
when i first looked at it, scope memory topped out at like 32k points
<azonenberg>
so i wasn't really too interested
<azonenberg>
and usb2 is slow
<azonenberg>
but if i can get it to run my bridge locally and stream sample data over gig-e? now that is interesting