<d1b2>
<david.rysk> @josHua can't remember, did you have interest in the TS side of things? I'm going to flash my beta unit with LiteX firmware soon and then start messing with the DriverKit driver, but I recall you having worked with some of that before
<_whitenotifier>
[scopehal] azonenberg 6b0a06e - Merge pull request #901 from fredzo/siglent-sds-support Reduced command rate limiting for newer models + fixes.
<d1b2>
<josHua> not much interest (also I do not have TS hardware)
<d1b2>
<josHua> I think my realization is that I should be careful to avoid being called the dev team for now, and I should submit UI patches that I think are important when I can, and if my vision diverges greatly from others', then I will simply not be personally offended and I will go do other thing 🙂
<d1b2>
<azonenberg> Well please keep it up, i definitely like the direction you're taking the stream browser
<d1b2>
<azonenberg> I had a similar vision and just haven't yet had the time to execute on it
<d1b2>
<josHua> I guess my point is just that you shoudl expect me to be this kind of open source contributor, not the kind that can be effectively aimed in any particular direction 🙂
<d1b2>
<azonenberg> Also i still don't have a root cause for the corrupted-preferences-cause-crashes bug
<d1b2>
<azonenberg> but i do have a bandaid that makes bad font files result in a fallback to a default font
<d1b2>
<azonenberg> (in my local working copy not yet pushed)
<d1b2>
<azonenberg> well right now we have an anvil that needs hitting
<d1b2>
<azonenberg> so i'll take it :p
<d1b2>
<josHua> this reminds me that I need to redraw the toolbar icons for retrigger / singleshot / forcetrigger / abort capture. I keep staring at them and invariably clicking the wrong one
<d1b2>
<azonenberg> That was going to be on pirate's docket once she finishes redrawing the filter icons
<d1b2>
<azonenberg> (as well as making a new one for auto-trigger once we support that)
<d1b2>
<josHua> also fine
<d1b2>
<azonenberg> But if you want to try a concept yourself, i won't stop you
<d1b2>
<josHua> are there issues filed for each of the icons that need to be done so I can just grab some that are unassigned if I feel like being artistic?
<d1b2>
<josHua> tell you what, I'm going to see if I can finish my first pass on this schematic review from hell round 9, and if I have any time left before I go to sleep, I will fire up inkscape and see if I can doodle anything useful
<d1b2>
<azonenberg> We do not have issues for individual filter icons, pirate has been throwing drafts at me of everything that wasn't in a screenshot i shared before
<d1b2>
<azonenberg> She is not actively working on the toolbar
<d1b2>
<azonenberg> so if you want to de-conflict, working on the toolbar is probably the easiest option
<d1b2>
<josHua> I think that is also, like, two questions phrased as suggestions, 'what other art is there in general that needs to be done? should there be tickets to fully enumerate the art needed for 0.1 so we know how much work there is?'
<d1b2>
<azonenberg> There shoulud be
<d1b2>
<azonenberg> An application icon is the biggest open TODO
<d1b2>
<azonenberg> art wise
<d1b2>
<azonenberg> nobody is actively working on it
<d1b2>
<azonenberg> Latest round of icon drafts BTW
<d1b2>
<josHua> so in part these textures are difficult to see on my display because they are not rendered to be pixel grid aligned; in part, it is because they are rendered for 24x24 on a nominal 24x24 "point" display size (but my display is HiDPI); and, in part, it is because they are rendered for 24x2 3 !
<d1b2>
<azonenberg> i never noticed they were off by a pixel lol
<d1b2>
<azonenberg> blame the OG artist from years back lol
<d1b2>
<azonenberg> also, on hidpi we should be using the 48x48 icon renders
<d1b2>
<josHua> well, on hidpi, in iconSize = 24px, we shoudl use the 48x48 renders, and in iconSize = 48, then we shoudl use the (non existent) 96x96 renders
<d1b2>
<chille0417> I would love to see an upstream icon, even if its just an placeholder while waiting for the "real" one. AppImage's requires an icon, so now I have to copy some random image and add it to ngscopeclient.desktop to be able to generate one.
<d1b2>
<josHua> let me see if lavender (who did the x1plus logo) has any ideas for a ngscopeclient logo
<d1b2>
<macaba> My guess is that it needs updating therefore is commented out for now
<d1b2>
<macaba> That's okay, just wanted to make sure I didn't miss some useful docs for my plugin development
<d1b2>
<david.rysk> Aah that’d be a question for @azonenberg
<d1b2>
<macaba> So far I've figured out I need a PluginInit entry point, but not yet sure what I need to do in that method to register with the rest of the app.
azonenberg has joined #scopehal
<d1b2>
<macaba> Added some debug messages, looking good so far, just need a bit of an idea of how to do registration
sgstair has quit [Read error: Connection reset by peer]
sgstair has joined #scopehal
miek has quit [Ping timeout: 244 seconds]
<d1b2>
<azonenberg> Look at the init functions in libscopehal
<d1b2>
<azonenberg> e.g. DriverStaticInit()
<d1b2>
<macaba> I need to think about this more but I think the plugin interface might need some kind of context passed to PluginInit for invoking methods on, otherwise how does it stay truly isolated from ngscopeclient?
<d1b2>
<azonenberg> As of now, plugins simply advertise drivers, filters, and transports by writing them into the global object creation tables (std::map<driver name, factory method>)
<d1b2>
<azonenberg> the table doesnt care where the factory came from
<d1b2>
<macaba> how does the plugin get access to that table?
<d1b2>
<azonenberg> once PluginInit is called there are no interactions between ngscopeclient and the plugin until a driver/fitler/transport is created
<d1b2>
<azonenberg> It's global and exported by libscopehal
<d1b2>
<azonenberg> the plugin links to scopehal
<d1b2>
<macaba> Ok, that's the issue then
<d1b2>
<azonenberg> Calling AddDriverClass() etc writes to it
<d1b2>
<macaba> I can't do that
<d1b2>
<azonenberg> ??
<d1b2>
<azonenberg> why?
<d1b2>
<macaba> I can invoke C ABI methods on DLLs, or do things with objects passed to the plugin
<d1b2>
<azonenberg> ... oh you're not writing your plugin in C++
<d1b2>
<azonenberg> yeah thats not going to work yet
<d1b2>
<macaba> That's fine, it's not a plugin interface as it is - because you might as well create your thing directly in a fork of scopehal. That's okay, something to look at later.
<d1b2>
<azonenberg> The entire object model relies on you creating a C++ object derived from e.g. SCPIOscilloscope in the factory method in your driver and returning a pointer to it when your factory is called
<d1b2>
<azonenberg> The intent is to provide a license and compilation boundary
<d1b2>
<azonenberg> so you can create proprietary plugins or ones that are distributed separately due to dependencies we don't want all users to depend on
<d1b2>
<macaba> Sure, but it's not a plugin interface, that's all
<d1b2>
<macaba> for external code interop and so on
<d1b2>
<azonenberg> I would still consider it a plugin interface, simply one with a C++ ABI
<d1b2>
<macaba> Ok, I wouldn't
<d1b2>
<azonenberg> Its definitely fairly tightly coupled
<d1b2>
<macaba> by the convention of 99% of things out there 😄
<d1b2>
<azonenberg> But yeah there is no way to create a driver just with C method calls
<d1b2>
<azonenberg> all drivers need to exist as C++ objects with RTTI that fit our existing object model etc
<d1b2>
<azonenberg> the plugin interface is simply a way to create that in a way that isn't part of the distributed binaries
<d1b2>
<macaba> Cool, so I'll go at it from the opposite way - C++ shim in scopehal fork that calls the DLL
<d1b2>
<azonenberg> You could still make a plugin for the shim
<d1b2>
<azonenberg> But yeah, ultimately you need to have an object derived from SCPIOscilloscope that implements all those virtual methods and creates data in AcceleratorBuffer's etc
<d1b2>
<macaba> Makes sense, I think that answers everything for now
<d1b2>
<azonenberg> Yeah we dont have any high level dev docs yet
<d1b2>
<azonenberg> we have the low level doxygen (full coverage of which is incomplete) and end user docs
<d1b2>
<azonenberg> nothign in between so far
<d1b2>
<josHua> I sent you an invite, I'm not sure if it's going to go nuts because I don' thave any more paid github seats in the acceleratedtech organization, but I'm also not sure what causes a paid seat to be needed
<d1b2>
<fredzo_72653> Got it ! Should be good, I'll push something shortly to check that, thanks !
<d1b2>
<azonenberg> We now have a dialog under the debug menu that we can use to allocate up to 4GB (per instance, you can have several active) of host RAM or VRAM
<d1b2>
<azonenberg> allowing you to simulate low memory situations without having to create some complex filter graph with huge waveforms
<d1b2>
<azonenberg> Should be a good debug tool for improving stabiliy in these situations
<d1b2>
<fredzo_72653> Download progress is simulated for now, but the idea would be to add a GetDownloadProgress() method on OscilloscopeChannel interface that would return an integer that could be between 0 and 100 for progress bar, or other (negative) values mapped to an enum to let the driver say if he wants to display a progress bar or not based on the current sample depth.
<d1b2>
<fredzo_72653> In this demo, the download progress bar is activated if sampledetph is greater that 100k samples
<d1b2>
<josHua> yeah, I figured there would be a GetChannelStatus() that returned an enum ACQUIRING, DATA_AVAILABLE, DOWNLOADING, EMPTY or something, and then a GetDownloadProgress() that is valid when in DOWNLOADING state
<d1b2>
<fredzo_72653> Yep, download progress is only shown if IsTriggerArmed() is true
<d1b2>
<fredzo_72653> Let me review my code and I'll push in a minute
<d1b2>
<fredzo_72653> @azonenberg can you tell me if you're OK with the idea of an GetDownloadProgress() method on OscilloscopeChannel interface ? If so I'll submit a PR for that on scopehal, so that we can move on with StremBrowerDialog implementation
<d1b2>
<azonenberg> Hmm, yeah that should work
<d1b2>
<azonenberg> We may have to revise things as we test with a combination of slow and fast scopes
<d1b2>
<azonenberg> Including such edge cases as "picoscope accessed over slow VPN"
<d1b2>
<azonenberg> i am wondering if it should be dynamic where we display the progress bar if we've been in DOWNLOADING for more than say 100ms
<d1b2>
<azonenberg> and then keep it on for the remainder of the session
<d1b2>
<azonenberg> (also it should be an Oscilloscope method that OscilloscopeChannel just has a helper method to get with m_index)
<d1b2>
<fredzo_72653> Yeah, I was thinking dynamic too, but it might be tricky to find a consistent way to activate it: it might be frustrating to have it show up or not with the same settings just based on some network latency
<d1b2>
<chille0417> @fredzo If the Alientek DP100 is actually using the same CRC as Modbus, then maybe ModbusInstrument::CalculateCRC should be splitted out to a separate file that can be reused in the DP100 driver.
<d1b2>
<fredzo_72653> Th demo code uses this enum: enum DownloadState : int { DOWNLOAD_PROGRESS_DISABLED = -3, DOWNLOAD_NONE = -2, DOWNLOAD_WAITING = -1, DOWNLOAD_STARTED = 0, DOWNLOAD_FINISHED = 100 }; The default implementation of GetDownloadProgress() would return DOWNLOAD_PROGRESS_DISABLED to let each driver choose it's strategy
<d1b2>
<chille0417> Maybe the SCPISocketTransport should have a "slow VPN simulation mode"? Enable it and all commands will be delay 10 seconds. 😂
<d1b2>
<azonenberg> I'm not opposed to adding some kind of delay feature for testing we'd just have to figure out how
<d1b2>
<fredzo_72653> Yeah I'll look into that when I move to USB HID integration with hidapi lib, but it looks like I've gone the UI path for now with Joshua so it will have to wait a little ;-)...
<d1b2>
<chille0417> I want to add some other options to configure the behavior of the data transfers. So maybe we should have some kind of SetOption() on all transport to begin with.