<_whitenotifier-9>
[scopehal-apps] azonenberg a408d50 - Convertd MiscInstrument and RFSignalGenerator to use unified thread procedure
<_whitenotifier-9>
[scopehal-apps] azonenberg 12daa75 - Finished unifying thread procedures. We still instantiate one thread per instrument type, though.
<d1b2>
<azonenberg> OK so now to figure out how to unify instrument connection state...
<_whitenotifier-9>
[scopehal-apps] azonenberg a9127dd - Unified instrument connection state to be a single class
<d1b2>
<azonenberg> Progress. Still more to be done
<d1b2>
<azonenberg> Generally I'm working towards erasing as much instrument-class-dependent code as possible
<d1b2>
<azonenberg> and working entirely on feature flags and the set of available channels etc
<d1b2>
<azonenberg> This is going to be a necessary prerequisite to properly handle modern instruments that often implement features from multiple device types
<d1b2>
<azonenberg> (my immediate use case is a bert + oscilloscope but I expect more weird hybrids coming)
<_whitenotifier-9>
[scopehal-apps] ... and 2 more commits.
<d1b2>
<azonenberg> ok so all instrument types now use a single worker thread and all instruments other than oscilloscopes (that will come shortly, i just did the easier stuff first) now use common methods for adding/removing them from a session
<d1b2>
<johnsel> nice work
<d1b2>
<azonenberg> There is sort of an API for removing instruments but it's incomplete and will keep the instrument in a half-deleted state (worker thread terminated but socket still open) as long as other filters/nodes are using it in some way
<d1b2>
<azonenberg> down the road i need to make the remove method actually find all users of the instrument and disconnect those paths
<d1b2>
<azonenberg> also, all of the other instrument types like PSUs and DMMs and RF generators are now decoupled from the dialogs in that the dialog being closed no longer disconnects the instrument from the session
<d1b2>
<azonenberg> however, you can't get the dialog back once you close it
<d1b2>
<azonenberg> so it's as good as gone for most applications :p
<d1b2>
<azonenberg> But i'm gonna be doing a bunch of cleanup around that soon, in particular moving away from the per-instrment dialog for things like PSU channel settings
<d1b2>
<azonenberg> and towards it being a ChannelPropertiesDialog like we use for scope channels
<d1b2>
<azonenberg> (so you can e.g. right click a PSU node in the filter graph and get the settings popup)
<d1b2>
<azonenberg> Still quite a bit more to do
<d1b2>
<azonenberg> And there's still a LOT of unnecessarily repetitive, mostly-copy-pasted code around serialization and instrument creation/deletion that i think can be filtered down greatly
<d1b2>
<johnsel> How do multiple instrument threads and sockets work?
<d1b2>
<johnsel> I assume there's a single socket?
<d1b2>
<azonenberg> So that was part of the problem
<d1b2>
<azonenberg> with the previous model each instrument had a "primary type" e.g. a scope with attached function generator was primarily a scope
<d1b2>
<azonenberg> it would spawn the worker thread for the primary type
<d1b2>
<azonenberg> and you just had to not need any background processing for any of the other functions
<d1b2>
<azonenberg> when i tried to create a bert+scope this broke
<d1b2>
<azonenberg> Which was the impetus for this refactoring
<d1b2>
<azonenberg> In general as part of this refactoring i'm trying to simplify things and remove the concept of an instrument having any kind of one type being more important than any other
<d1b2>
<azonenberg> it'll just have a list of features it supports and the UI knows how to handle that
<d1b2>
<azonenberg> later on i want to simplify instrument creation rather than having dozens of different near-identical dynamic creation tables
<d1b2>
<azonenberg> there will just be one, in the Instrument class