<d1b2>
<azonenberg> I'm about to create an instrument that's simultaneously a BERT and an oscilloscope and this is going to break a bunch of things lol
<d1b2>
<azonenberg> i think i'm going to have to redo how i do instrument data-processing threads a bunch
<d1b2>
<azonenberg> Basically i think having a separate worker thread for each type of instrument is going to end badly
<d1b2>
<azonenberg> that needs to be coalesced into a single worker thread that just calls various stuff based on the type of instrument
<d1b2>
<azonenberg> In general we have a lot of code paths that make control flow decisions based on the type of instrument that i'd like to unify
<d1b2>
<azonenberg> Well, i jumped in with both feet and started with the rest of the sahred_ptr refactoring, which i think was long overdue
<d1b2>
<azonenberg> Once that's done the next step will be trying to unify some of the device creation code, i think
<d1b2>
<azonenberg> There's no reason to have separate device creation tables for each type of instrument
<d1b2>
<azonenberg> Especially since more and more devices are multiple types anyway
lain has quit [Remote host closed the connection]
lain has joined #scopehal
<d1b2>
<johnsel> Can I request to get a drop-box with known devices to select from as an alternative to typing manually?
<d1b2>
<johnsel> It could even be a combination if you prefer that, so a text input with auto-fill/dropdown if there are known devices already
<d1b2>
<johnsel> Also the long-term issue where it's impossible to disconnect easily from devices might be nice to think about now
<d1b2>
<azonenberg> what do you mean? there's the recent instruments menu
<d1b2>
<azonenberg> that's the normal intended way to reconnect to stuff
<d1b2>
<azonenberg> the dialog for connection is only meant to be the first time you connect to an instrment
<d1b2>
<johnsel> I mean for new devices, e.g. thunderscopes, since we know 'where they live'
<d1b2>
<azonenberg> You mean detect a ts.net or other bridge server instance running on the local host and list that as a suggestion or something?
<d1b2>
<johnsel> Yes exactly
<d1b2>
<azonenberg> yeah there's potential for that i guess. as far as disconnection from devices, that's going to be a multi step process
<d1b2>
<azonenberg> the shared_ptr refactoring is the beginning of it
<d1b2>
<azonenberg> but there's a bunch of other refactoring needed
<d1b2>
<azonenberg> things like decoupling instrument lifespans from the properties dialogs
<d1b2>
<johnsel> sure, I just wanted to keep complaining about it so you don't forget 🙂
<d1b2>
<azonenberg> and unifying worker threads
<d1b2>
<azonenberg> Yeah right now my big priority is getting the shared_ptr code to compile again
<d1b2>
<azonenberg> i have a 2k line diff and hundreds of compile errors right now
<d1b2>
<johnsel> Especially with repeated testing of things it's really cumbersome to close ngscopeclient entirely
<d1b2>
<azonenberg> Yeah. It's one of several dozen things on my list, i just need another five full time devs :p
<d1b2>
<johnsel> Sure don't feel pressured by it, just giving user feedback what I run into while dogfooding
<d1b2>
<johnsel> If you can split out the work in smaller chunks I may be able to pick up some of it
<d1b2>
<azonenberg> This refactoring really has to be done all at once
<d1b2>
<azonenberg> this particular bit i mean
<d1b2>
<azonenberg> the ownership revamp of channels is another big one that will probably be just as painful
<d1b2>
<johnsel> Yep, I mean more in the general sense
<d1b2>
<johnsel> I may be able to contribute 0.1415 of a full time dev towards it if there's some low hanging fruit I can pick up
<d1b2>
<johnsel> I am finally starting to get more familiar with scopehal/ngscopeclient now while writing the driver
<d1b2>
<azonenberg> That's a very precise fraction lol
<d1b2>
<johnsel> Well, it's a rough estimate
<d1b2>
<azonenberg> So i think the top priority yak that isn't a sweeping architectural change I need to do myself is the removal of FFTS
<d1b2>
<johnsel> Mmm yes I spent some time on that before
<d1b2>
<azonenberg> this is two sub-tasks: first, refactoring TestWaveformSource::DegradeSerialData() to use VkFFT
<d1b2>
<johnsel> Would we want to.. right
<d1b2>
<johnsel> that was going to be my question
<d1b2>
<azonenberg> and second, refactoring all unit tests that do FFT stuff to use FFTW (as a golden reference implementation that doesn't depend on the GPU, licensing is irrelevant as we don't distribute binaries of the test cases)
<d1b2>
<azonenberg> The other big dependency yak is replacing Cairo which we literally only use for drawing the bitmasks we use for computing eye pattern hit rates
<d1b2>
<johnsel> I'll see how far I get with the first task of those at least
<d1b2>
<azonenberg> this all ties into the other big issue namely fixing the windows build process
<d1b2>
<azonenberg> and ideally making a native visual studio build possible
<d1b2>
<azonenberg> i think we're close
<d1b2>
<johnsel> yeah.. just gotta pull through these few last dependencies
<d1b2>
<azonenberg> The other related yak is getting CPack set up for Linux binary package generation. This does not replace the need for distro native packaging, but dev builds will always be ahead of distro packages
<d1b2>
<azonenberg> And we want an easy way for people to grab the latest binary including all of our dependencies
<d1b2>
<azonenberg> Functional MSI + DEB + RPM packages are IMO a minimum requirement for the TS launch
<d1b2>
<johnsel> agreed, though I'm not volunteering for that one
<d1b2>
<azonenberg> Lol
<d1b2>
<azonenberg> nobody is, thats the problem :p
<d1b2>
<johnsel> maybe we need to work on making the project a little more developer friendly?
<d1b2>
<azonenberg> the first step for that is fixing the build process
<d1b2>
<johnsel> simple things like a proper readme with instructions to get setup that just work
<d1b2>
<azonenberg> the need to build a zillion dependencies like FFTS from source has already scared off some would-be contributors
<d1b2>
<johnsel> yeah I understand where they're coming from, I don't like it either
<d1b2>
<azonenberg> The other big step is getting some source-level documentation (doxygen) compiled and browsable online
<d1b2>
<azonenberg> doxygen is necessary but not sufficient
<d1b2>
<azonenberg> we also need some higher level dev docs on e.g. how to make a new instrument driver
<d1b2>
<johnsel> yeah 100% agree on that one
<d1b2>
<azonenberg> or filter, etc
<d1b2>
<johnsel> I've asked you I think 4 times now what to do and it still confused me
<d1b2>
<azonenberg> (one of the reasons i've held off is that i've had some sweeping code changes planned that are going to invalidate a bunch of that)
<d1b2>
<johnsel> we should have some explanation of what it entails and ideally a small template driver/filter
<d1b2>
<azonenberg> e.g. eliminating the confusing design of having different dynamic-creation tables based on the instrument type
<d1b2>
<azonenberg> this involves a lot of duplicated code and isnt really needed, but the getting there is going to be painful
<d1b2>
<azonenberg> it's several items down the refactoring todo after the shared_ptr stuff; next immediate focus after that will be unifying worker threads
<d1b2>
<azonenberg> because i have a specific need (an instrument that is simultaneously a bert and oscilloscope) that would be very painful to do without that
<d1b2>
<johnsel> will you decouple the acquisition thread/calls entirely? or something similar to what we have now but less coupled?
<d1b2>
<azonenberg> The first step is going to be making it so we have one worker thread per instrument that contains sub-tasks for each type
<d1b2>
<azonenberg> and only one top level thread procedure
<d1b2>
<azonenberg> Rather than a seaprate LoadThread, MultimeterThread, etc
<d1b2>
<azonenberg> This is going to be part of the overall revamping of instrument lifespans which will enable things like closing and reopen property dialogs and deleting instruments
<d1b2>
<azonenberg> also tied in as part of that will be a GUI revamp so that a lot of the previous instrument property dialogs like for power supplies are going to change to be channel properties like in the filter graph
<d1b2>
<azonenberg> (now that the properties dialog won't have to own the device anymore)
<d1b2>
<johnsel> Mm yes sounds good
<d1b2>
<azonenberg> part of the challenge is all of this is inter-related
<d1b2>
<azonenberg> and hard to do one piece without the others
<d1b2>
<azonenberg> i dont know how i could hand someone a piece of this work and have them do it independently of me doing the rest
<d1b2>
<azonenberg> it's a lot of sweeping object model cleanup
<d1b2>
<johnsel> I do want to challenge you with the idea that a scopehal driver might want to run multiple threads for super high speed instruments
<d1b2>
<azonenberg> That's something that is going to, i think, be something we think about when we move away from the "current waveform" concept
<d1b2>
<azonenberg> we've got many bigger problems to fix before thinking about that
<d1b2>
<johnsel> Sure, but you're redesigning now, you can take into account how the future might/will look (more will than might, even if you'd go ethernet you'll need multiple sockets/threads to reach maximum throughput)
<d1b2>
<azonenberg> The refactoring i'm doing now is not really touching datapath at all
<d1b2>
<johnsel> I'm not saying you should go out of your way to enable it, but you might keep in the back of your mind
<d1b2>
<azonenberg> it's mostly object lifespans and such
<d1b2>
<johnsel> That's also true
<d1b2>
<azonenberg> they're largely orthogonal
<d1b2>
<johnsel> Yeah I have to concur
<d1b2>
<azonenberg> then there's the second big refactoring after this where we move instrument channels to be smart pointers
<d1b2>
<azonenberg> and stop using our own homegrown refcounting
<d1b2>
<azonenberg> Which is not as easy as it sounds for a bunch of reasons including the fact that we currently use the channel ref count in order to determine whether to acquire waveforms for a channel
<d1b2>
<johnsel> hmm @azonenberg I don't have a cmdBuf in TestWaveFormSource