<d1b2>
<johnsel> but I think it's at least as annoying to use that than to port it to sdl2
<d1b2>
<david.rysk> the other issue is touch support
<d1b2>
<david.rysk> the UI is very much not written with touch in mind and Andrew said to me that it will stay that way
<d1b2>
<david.rysk> but that might change, idk 🙂
<d1b2>
<johnsel> haha
<d1b2>
<david.rysk> rather touch is not a focus at least for now, and I can see why
<d1b2>
<david.rysk> you can't just port keyboard/mouse to touch and expect it to work well
<d1b2>
<johnsel> well you can connect a bluetooth mouse
<d1b2>
<david.rysk> I mean yeah
<d1b2>
<johnsel> so that need not be a problem
<d1b2>
<david.rysk> but then again, mouse on iPad is weird
<d1b2>
<david.rysk> you don't get a pointer even
<d1b2>
<johnsel> sure you do
<d1b2>
<david.rysk> no, you get a circular fingertip-sized blob
<d1b2>
<johnsel> well it's a circular pointer
<d1b2>
<johnsel> who says pointers need to be arrows
<d1b2>
<johnsel> I suspect that glfm will translate touch to mouse as well
<d1b2>
<johnsel> maybe not though
<d1b2>
<johnsel> I may try to port it in
<d1b2>
<johnsel> or port to sdl2
<d1b2>
<david.rysk> idk I consider this low priority
<d1b2>
<johnsel> me too
<d1b2>
<david.rysk> limited RAM on iPad/tablet platforms is another concern heh
<d1b2>
<johnsel> but I like to do things for fun as well
<d1b2>
<johnsel> and it seems fun
<d1b2>
<johnsel> not really though you get a few gigabytes at least
<d1b2>
<johnsel> modern ipads have a decent amount of ram
<Darius>
I ran davinci resolve on ipad, talk about memory pressure..
<d1b2>
<johnsel> my old ipad pro 10.5" inch has idk
<d1b2>
<johnsel> at least a gigabyte
<Darius>
newer ones or pro models have a lot more
<d1b2>
<david.rysk> yeah the current high end ones have 8-16GB of RAM, but the OS will really curtail use
<d1b2>
<johnsel> yes
<d1b2>
<johnsel> are you speaking from experience? because in my experience you can eat up a lot of that memory
<d1b2>
<johnsel> I used to get oom errors at 700-ish MBs of 1GB when I was dealing with it
<d1b2>
<johnsel> unfortunately in a webview
<d1b2>
<azonenberg> Sooo in general, ngscopeclient is meant specifically for the mouse+keyboard use case
<d1b2>
<azonenberg> I am not opposed to making a touch-first frontend for libscopehal and libscopeprotocols
<d1b2>
<azonenberg> but it will IMO be best done as a completely new frontend on the same backend
<d1b2>
<david.rysk> yes but with older devices
<d1b2>
<azonenberg> (if we wanted to ever run scopehal native on e.g. windows based lecroy scopes, same deal - that's not what it's meant to do)
<d1b2>
<johnsel> and older versions of ios then
<d1b2>
<azonenberg> it's a completely reasonable goal, and can leverage the existing investment in drivers and decodes
<d1b2>
<azonenberg> but it would likely be a completely new ground-up UI
<d1b2>
<azonenberg> To do it right
<d1b2>
<johnsel> I would have to disagree, most reasonable scope platforms allows you to connect a mouse and kb as well
<d1b2>
<johnsel> so does an ipad
<d1b2>
<azonenberg> well yes you can do that
<d1b2>
<johnsel> I don't think you need to focus on a touch-first interface
<d1b2>
<johnsel> anything a bit complicated needs a mouse anyway
<d1b2>
<johnsel> instead of fat fingering it
<d1b2>
<azonenberg> And i'm not opposed to exploring such things, i've already run glscopeclient on my lecroys (forget if i've tried with ng yet)
<d1b2>
<azonenberg> it just wasnt all that useful without a mosue+keyboard
<d1b2>
<azonenberg> My point is, i'm not opposed to a touch-first interface for the existing backend being created one day
<d1b2>
<johnsel> sure, for an ipad I think a mouse + osk should be fine
<d1b2>
<azonenberg> Its not our current dev priority, and it should not be an extension of the existing ui
<d1b2>
<azonenberg> we can perhaps use imgui if we judge that to be a good choice
<d1b2>
<azonenberg> and perhaps refactor some stuff into a library
<d1b2>
<azonenberg> but fundamentally it would be a new tool
<d1b2>
<azonenberg> with lots of different optimizations for lower memory usage and such
<d1b2>
<azonenberg> and working well on smaller screens
<d1b2>
<azonenberg> probably less flexibility of window layout, more popups and less docking
<d1b2>
<azonenberg> I'm not a mobile UI designer and havent thought about how to do it well yet
<d1b2>
<azonenberg> The good news is, ngscopeclient actually isn't all that much code compared to the rest of the project
<d1b2>
<azonenberg> like, by lines, ngscopeclient is 41K lines including headers and shaders
<d1b2>
<azonenberg> libscopehal is 74K and libscopeprotocols is another 71k
<d1b2>
<azonenberg> all of that backend could be reused
<d1b2>
<johnsel> not fun though
<d1b2>
<david.rysk> optimizing for memory usage isn't that critical
<d1b2>
<david.rysk> tbh, we'd want the same optimizations on macOS if we can
<d1b2>
<david.rysk> UI though? very
<d1b2>
<johnsel> what? new M macos devices are all the more reason to slobber up RAM
<d1b2>
<johnsel> well except for unified optimizations
<d1b2>
<azonenberg> yeah M series devices are a perfect reason to have even more shaders for even simple signal processing operations
<d1b2>
<azonenberg> because there's ~no transfer penalty
<d1b2>
<david.rysk> but so is iOS and mobile in general
<d1b2>
<azonenberg> but yeah in general the desktop use case expects a lot more ram available than the mobile
<d1b2>
<johnsel> even my 2017 ipad has 4GB ram
<d1b2>
<azonenberg> like, on mobile we would probably write history waveforms to disk immediately to free the ram
<d1b2>
<azonenberg> and only keep the active waveform in memory
<d1b2>
<johnsel> that's half of the max we can use now
<d1b2>
<johnsel> well sure except history then
<d1b2>
<azonenberg> while on desktop we try to keep everything in ram so its fast to move back and forth
<d1b2>
<johnsel> you'd probably disable that on mobile
<d1b2>
<azonenberg> We'd probably keep it but make the cap smaller and use disk
<d1b2>
<azonenberg> make the default cap say 2-3 waveforms or so
<d1b2>
<azonenberg> also reduce default memory depths for a lot of stuff
<d1b2>
<david.rysk> are we doing any sort of in-memory compression?
<d1b2>
<azonenberg> No. the native in-memory sample format is fp32
<d1b2>
<azonenberg> thats by far the fastest for GPU operations
<d1b2>
<johnsel> ?
<d1b2>
<azonenberg> We're not optimizing for memory usage we want to push as many WFM/s as we possibly can
<d1b2>
<johnsel> I've never heard that
<d1b2>
<johnsel> INT8 flops is always higher
<d1b2>
<david.rysk> yeah, but if you fill up the available memory having more WFM/s won't help 😛
<d1b2>
<azonenberg> What I mean is, as opposed to working with wierd fixed point formats
<d1b2>
<azonenberg> like native adc samples or something
<d1b2>
<johnsel> ah
<d1b2>
<azonenberg> sure fp16 is an option for some stuff but you lose enough dynamic range i dont think its worth the overhead and complexity of having multiple waveform formats and needing conversion blocks for filters that cant handle it etc
<d1b2>
<azonenberg> I looked into it a while back and it didnt seem like a good choice at the time
<d1b2>
<johnsel> it would allow for tensor cores to be used easily
<d1b2>
<david.rysk> no Metal support
<d1b2>
<johnsel> I think they can do FP32 as well but it's very badly documented if it is
<d1b2>
<azonenberg> Anyway, these are all things to look into way down the road 🙂
<d1b2>
<david.rysk> well that option for CI is not available anymor
<d1b2>
<david.rysk> e
<d1b2>
<johnsel> thanks broadcom
<d1b2>
<azonenberg> lol
<d1b2>
<azonenberg> yeeeeah
<d1b2>
<johnsel> VMware reached a new milestone in its journey over the last two years to streamline and simplify its portfolio and transition from perpetual licensing to a subscription model
<d1b2>
<azonenberg> "A special shout-out to our new users transitioning from VMware; your enthusiasm is greatly propelling the entire Vates ecosystem, including XCP-ng and Xen Orchestra"
<d1b2>
<johnsel> well hopefully they have better experience than we have
<d1b2>
<david.rysk> wonder how many are moving to Proxmox
<Darius>
johnsel: it's fine there are plenty of cars on their money making road, blowing up the onramp won't affect the next few quarters of revenue at all!
<d1b2>
<johnsel> yeah lol
<d1b2>
<johnsel> not to mention all the school that will have to go back to distributing cracked versions of the software
<d1b2>
<johnsel> and yes I speak from experience
<d1b2>
<azonenberg> lol
<Darius>
hah
<d1b2>
<johnsel> and no I did not go to some backwater shithouse lol
<d1b2>
<johnsel> they were too cheap to buy licenses though
<d1b2>
<johnsel> I think it was vmware workstation though
<d1b2>
<johnsel> funny enough we also used virtualbox
<d1b2>
<johnsel> but I remember the teacher preferred vmware lol
<d1b2>
<david.rysk> they're unlikely to get rid of the educational programs for teaching
<d1b2>
<david.rysk> they'll probably restrict infra use though
<d1b2>
<johnsel> yeah presumably my school could not make use of that
<d1b2>
<johnsel> I think it's limited to higher education. I never liked going to school when I was little because got kicked out of Dutch school to Belgian ones because our school system works with levels and I came in having skipped a class in primary so they wouldn't let me drop a level. And I was never one to learn from books, I preferred the internet
<d1b2>
<johnsel> that said, I'm not giving my children the same unrestricted access to the internet lol
<Darius>
anyone built scopehal on macos recently?
<d1b2>
<david.rysk> yes, me
<d1b2>
<david.rysk> running into problems?
<d1b2>
<david.rysk> I'll test build again, but I recently updated the instructions too
<d1b2>
<david.rysk> builds for me
<Darius>
OK
<Darius>
well I am doing it with macports deps
<d1b2>
<david.rysk> so I test with Homebrew deps, but MacPorts deps should work too. I can help troubleshoot, what are you seeing? You will need to provide -DCMAKE_PREFIX_PATH appropriately
<Darius>
I had to comment out the YAML CPP work around for debian
<Darius>
also had to add a kludge for openmp
<d1b2>
<david.rysk> that should only trigger if you're missing yaml-cpp files in /opt/local/lib/cmake, or if they are broken
<Darius>
next up is: Could not find VulkanLoader_LIB using the following names: libvulkan.so
<d1b2>
<darius0949> actually I shoudl speak here, then I can quote block
<d1b2>
<david.rysk> yeah
<d1b2>
<johnsel> one of us
<d1b2>
<david.rysk> the version of vulkan-loader in macports is lagging
<d1b2>
<david.rysk> 1.3.261.1, current is 1.3.275.0
<d1b2>
<david.rysk> yeah the Portfile is incomplete
<d1b2>
<david.rysk> 😦
<d1b2>
<david.rysk> it's not installing the .cmake files
<d1b2>
<david.rysk> file a bug with them I guess
<d1b2>
<darius0949> ah righto
<d1b2>
<darius0949> will do
<d1b2>
<david.rysk> I suspect something similar with yaml-cpp
<d1b2>
<david.rysk> I used to use MacPorts years back, then around the time of the Apple Silicon transition I switched to MacPorts for a while, but I got tired of packages not being updated in a timely manner and lack of binary builds
<d1b2>
<darius0949> hmm yaml-cpp has /opt/local/share/cmake/yaml-cpp/yaml-cpp-config-version.cmake etc
<d1b2>
<darius0949> maybe I fucked up something else
<d1b2>
<david.rysk> if there's a yaml-cpp-config.cmake it should find that. If you can paste the contents of the file and the files it includes someplace I can look more closely
<d1b2>
<david.rysk> also for debugging cmake message("VARIABLE is ${VARIABLE}") is super handy 🙂
<d1b2>
<david.rysk> yeah I'm trying to use cmake config find when possible
<d1b2>
<darius0949> but: -- Found PkgConfig: /opt/local/bin/pkg-config (found version "0.29.2") CMake Error at CMakeLists.txt:104 (message): Unexpected partially-installed yaml-cpp, is it installed correctly?
<d1b2>
<david.rysk> pkgconfig has its own problems
<d1b2>
<darius0949> oh OK
<d1b2>
<darius0949> how do I add to the cmake find path?
<d1b2>
<david.rysk> yeah I'd need to see the contents of ayaml-cpp-config.cmake etc
<d1b2>
<david.rysk> or I'd need to set up macports here lol
<d1b2>
<darius0949> I put /opt/local/share/cmake/yaml-cpp/yaml-cpp-config.cmake n https://termbin.com/4u17
<d1b2>
<david.rysk> so that's including yaml-cpp-targets.cmake, can you put that somewhere too?
<d1b2>
<david.rysk> oh they're packaging 0.7.0
<d1b2>
<david.rysk> 0.8.0 was released in August 2023
<d1b2>
<david.rysk> I would not be surprised if this is basically the same issue that I had on Debian, just that my workaround only looks for the .so and not the .dylib
<d1b2>
<david.rysk> if it doesn't add_library(yaml-cpp::yaml-cpp ... or so, then it's that
<d1b2>
<darius0949> duplicating the debian hack 'works'
<d1b2>
<david.rysk> yeah if you make it look for .dylib it will work
<d1b2>
<david.rysk> > DEPRECATION "The target yaml-cpp is deprecated and will be removed in version 0.10.0. Use the yaml-cpp::yaml-cpp target instead."
<d1b2>
<david.rysk> yeah, macports needs to update their yaml-cpp package to 0.8.0
<d1b2>
<david.rysk> that's what it is
<d1b2>
<darius0949> OK
<azonenberg>
also i still have to update the pdf/website docs, on my list of things to do tonight after i finish writing the filters i'm doing now
<azonenberg>
(i wanted to get skeleton docs for those filters included in the update)
<d1b2>
<darius0949> @david.rysk I updated vulkan-headers and vulkan-loader to 1.3.275.0 but it still complains it can't find VulkanLoader, I see that vulkan-headers installs /opt/local/share/cmake/VulkanHeaders/VulkanHeadersConfig.cmake and VulkanHeadersConfigVersion.cmake but loader doesn't install any cmake files.. got any hints? 🙂
<d1b2>
<david.rysk> yes, update the Portfile to install the .cmake files
<d1b2>
<david.rysk> right now it's only installing a few select files
<d1b2>
<david.rysk> it probably should be doing the equivalent of make install
<d1b2>
<darius0949> ah yep I see
<d1b2>
<darius0949> sigh, still barfs
<d1b2>
<darius0949> I installed https://termbin.com/0q4a to /opt/local/share/cmake/VulkanLoader/VulkanLoaderConfigVersion.cmake
<d1b2>
<darius0949> oh maybe it needs to be in lib not share
<d1b2>
<david.rysk> yes, for the loader (which is a lib) it needs to be in lib, not share
<d1b2>
<david.rysk> and you need Config, ConfigVersion, Targets, etc
<d1b2>
<david.rysk> one sec
<d1b2>
<david.rysk> yeah why isn't it using make install?
<d1b2>
<darius0949> I dunno 🙂
<d1b2>
<darius0949> I think because it is split into vulkan-headers and vulkan-loader but not certain
<d1b2>
<darius0949> lemme rebuild with the destroot {} crap removed, should DTRT then
<d1b2>
<darius0949> progress 😭 CMake Error at CMakeLists.txt:204 (message): glslc not found. This is needed to compile shaders. Please install shaderc or load the Vulkan SDK.
<d1b2>
<darius0949> naturally no port, guess I'll have to write one
<_whitenotifier-5>
[scopehal] azonenberg bf0d87d - Initial version of IQDemuxFilter
<_whitenotifier-7>
[scopehal-docs] azonenberg f46d3b2 - Initial skeleton docs of IQ Demux and Constellation filter blocks
<d1b2>
<darius0949> ie [Havok 17:02] ~/projects/scopehal-apps/build >./src/ngscopeclient/ngscopeclient libc++abi: terminating due to uncaught exception of type std::runtime_error: Failed to load vulkan library! zsh: abort ./src/ngscopeclient/ngscopeclient
<d1b2>
<darius0949> however.. [Havok 17:02] ~/projects/scopehal-apps/build >otool -L ./src/ngscopeclient/ngscopeclient|grep libvulkan /opt/local/lib/libvulkan.1.dylib (compatibility version 1.0.0, current version 1.3.0)
<azonenberg>
i can only assume thats something very wrong in your vulkan installation
<azonenberg>
because thats a low enough level error that it's before any of my gpu code even runs
<d1b2>
<darius0949> yeah I figured that when I couldn't find that string in the scopehal code 😬
<d1b2>
<darius0949> sadly setting VK_LOADER_DEBUG=all just prints the loader version
<d1b2>
<darius0949> OK setting DYLD_LIBRARY_PATH to /opt/local/lib gets a bit further
<d1b2>
<darius0949> now I get ERROR: glfwGetRequiredInstanceExtensions failed
<_whitenotifier-5>
[scopehal] azonenberg 8f0b9bf - Initial constellation skeleton code. Doesn't actually do any integration yet.
<d1b2>
<johnsel> picked the wrong thing to copy then 🙂
<d1b2>
<johnsel> haha
<azonenberg>
Yeah we can definitely make the repo link more obvious. I can work on that when i push the updated docs and do some other website stuff soon
bvernoux has quit [Quit: Leaving]
<d1b2>
<darius0949> not yet
<d1b2>
<darius0949> oh so it is, I thought it showed the crashing thread first but it doesn't
<d1b2>
<frosty._._._> 5-channel USB "oscilloscope" (more like a data logger)
<d1b2>
<johnsel> I have an oscilloscope that is faster
<d1b2>
<frosty._._._> I need a multi-channel analog datalogge
<d1b2>
<david.rysk> how many channels and what frequencies / sample rates?
<d1b2>
<david.rysk> and for what purpose?
<d1b2>
<david.rysk> if it's for RE of programming algorithms by watching what a programmer is doing... I did this mainly by pairing a multichannel LA with a 2-4 channel scope
<d1b2>
<frosty._._._> >=4 50kHz/channel is probably "enough" but more is always better.
<d1b2>
<david.rysk> Options dwindle if you go above 4 channels
<d1b2>
<frosty._._._> Building a flyback converter as a drain modulator for an RF power amp. Want to linearize the input/output
<d1b2>
<david.rysk> Good options*
<d1b2>
<david.rysk> ahhh
<d1b2>
<frosty._._._> two feels like too few, four is 'enough',
<d1b2>
<frosty._._._> I stumbled on the 5-channel device while poking around but I can't find anyone that's actually used one.
<d1b2>
<johnsel> with good reason probably
<d1b2>
<johnsel> this looks like some generic chinese garbage
<d1b2>
<johnsel> the brand also makes wicca boards and laptop stands
<d1b2>
<frosty._._._> Why would you insult my workbench like that 😉
<d1b2>
<azonenberg> I have a design in the early stages that will do well for that, but is likely overkill in both specs and price for what you need
<d1b2>
<johnsel> I can't see the price but I'm pretty sure there are better options out there
<d1b2>
<azonenberg> My concept is 100 Msps 16 bits 10-20 MHz BW on ~28 channels
<d1b2>
<david.rysk> yeah and there's Thunderscope too, but again probably overkill and expensive
<d1b2>
<azonenberg> With 10G ethernet and ~8GB of waveform memory
<d1b2>
<frosty._._._> $55 and it's dropshipped. likely also available on aliexpress for about the same money
<d1b2>
<azonenberg> Yeah my design will... not be $55 :p
<d1b2>
<david.rysk> I usually hear okay things about the Hantek scopes in that price range but idk if they have a 4ch
<d1b2>
<azonenberg> On that note, there's an open ticket for a hantek driver in scopehal
<d1b2>
<azonenberg> Nobody's got their hands on one to write it
<d1b2>
<frosty._._._> I'd drop a few hundred on a decent data acquisition module.
<d1b2>
<david.rysk> I'd look at digilent or picoscope
<d1b2>
<frosty._._._> my next best alternative is voltage dividers and round-robin ADC on a mictocontroller but I'm trying to avoid having to put in the time to bootstrap that.
<d1b2>
<david.rysk> Thunderscope will be around $700 it seems
<d1b2>
<david.rysk> maybe a bit more
<d1b2>
<david.rysk> (just cost of materials is that high)
<d1b2>
<johnsel> I did a INA229 design with scpi server on XMC4700 if that is the route you'd want to go
<d1b2>
<azonenberg> Yeah my own design is going to be quite a bit more because of the specs, the ADC is $331 per 4 channels so you're looking at $2317 just for ADCs for a 28 channel system. It's not a budget oriented platform
<d1b2>
<johnsel> I'm not sure if I can get you the Altium design