00:46 <azonenberg> So i really should make ValidateInput() be a const function

00:46 <azonenberg> ValidateChannel*

00:47 <azonenberg> but i'm trying to avoid making excessive refactorings to that part of the code because i really want to change that whole model

00:47 <azonenberg> and make some kind of more declarative way for a filter to describe what it wants

01:16 <_whitenotifier-7> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±8] https://github.com/glscopeclient/scopehal-apps/compare/e3e3c4c8ac64...9ddca7100a46

01:16 <_whitenotifier-7> [scopehal-apps] azonenberg 531fdfe - Initial work on reference filter creation/destruction

01:16 <_whitenotifier-7> [scopehal-apps] azonenberg 9ddca71 - Added initial menus for filter instantiation. Doesn't actually create any filters yet. See #515.

07:59 <d1b2> <mubes> Right, trying to get back involved again, and the first job is to build the current code, which has changed a lot while I wasn't looking 🙂 Problem is I'm getting errors from Vulkan; scopehal-apps/lib/scopehal/VulkanInit.cpp:814:44: error: ‘__gnu_cxx::__alloc_traits<std::allocator<vk::raii::PhysicalDevice>, vk::raii::PhysicalDevice>::value_type’ {aka ‘class vk::raii::PhysicalDevice’} has no member named ‘clear’ 814 |

07:59 <d1b2> devices[i].clear(); Am I using a wrong version or something? Build deps are a bit out of date (I'll update them when I've found them out! ). Trying to build on Ubuntu 22.04 with a shaderc from https://github.com/google/shaderc.git

11:03 <miek> looks like that method was introduced in v1.3.206 of vulkan-hpp

11:42 <azonenberg> yeah i dont know what our minimum vulkan sdk version is

11:42 <azonenberg> i did most dev against 1.3.224

11:42 <azonenberg> and have done little testing on older versions

11:43 <azonenberg> we had some problems with .229 and newer that i think are now fixed

12:44 <d1b2> <mubes> So...am I getting this stuff from the right place or do I need to go somewhere else?

12:45 <azonenberg> https://www.lunarg.com/vulkan-sdk/

12:45 <azonenberg> this is the official link to get tarballs or i think deb/rpm packages

12:46 <azonenberg> i normally install the deb packages

13:22 <miek> they're not providing packages for ubuntu 22.04 until next release but hopefully it'll be any day now, looking at their past release schedule

13:25 <azonenberg> the current packages work fine on debian stable last time i checked

14:31 <d1b2> <mubes> ta

16:24 <d1b2> <mubes> Great. I have a build. Question; Has anyone done anything with R&S RTB2004? I realised that I have one in storage and it's GbE with 10MS/channel sample depth. Just tried it and scopehal falls over in a big heap but it is talking to the scope so it might be worth giving it a bit of love....provided no-one is already on it. Progress will be slow, as things always are when I'm involved.

19:20 <d1b2> <louis> Q: why does the Threshold filter not sparsify/RLE?

19:22 <d1b2> <louis> is that an architectural descision or did we just not do it yet?

19:33 <d1b2> <louis> & somewhat relatedly, do we have a tracking issue for filters that assume dense inputs have the same start offsets?

20:39 <azonenberg> @mubes: There is no active work on the R&S driver. So far AFAIK it only supports RTM3000 and not well

20:39 <azonenberg> I wont object to you spending time on it, it's just not a priority for anyone currently

20:40 <azonenberg> @louis: Good question. There are a lot of potential enhancements we could apply, trading accuracy against performance

20:40 <azonenberg> Or trading near term vs long term performance

20:52 <azonenberg> For example, compressing samples. or interpolating to sub sample precision for zero crossings

20:53 <azonenberg> A lot of these would likely be configurable because they reduce the amount of data downstream filters have to process, but they also tend to be difficult to parallelize

20:53 <azonenberg> And not I am not aware of such an issue. We should make one

21:37 <miek> is anyone working on vna support so far?