<_whitenotifier-4>
[scopehal-apps] azonenberg 8310cd6 - FilterGraphEditor: don't try to access first node if we don't have any graph nodes yet
<_whitenotifier-4>
[scopehal-apps] azonenberg 5f9ee88 - Updated to latest NFD
<_whitenotifier-4>
[scopehal-apps] azonenberg a9c8bc1 - NFDFileBrowser: ensure window handle is set to null if we don't have a valid handle
<d1b2>
<__._.o._.__> Hi, I'm hoping to contribute some progress towards This scope (6254BD), but my lack of experience with professional/modern cpp development workflows is causing a hangups... so a few quick questions: 1. What IDE/extensions should I be using? Building this on debian was a PITA, I followed along the workflow file to manually build (its beaut. btw, I thought pulseview was a huge step up for me), but would have loved to integrate my existing
<d1b2>
XOA server/any-orchestrator as a job, as the EoF content implies should have been done... I only found that file after fast fourier transforms lib ffts.h wasn't found, and manually setting VULKAN_SDK env var for cmake 2. Where can I find more information about SCPI, and is there an official source? I'd like to use that initially (since danielkucera had at least half of that working), but even after reading a whitepaper, I'm still confused about the
<d1b2>
relationship to VISA... 3. (The Easy Q) Is there a template for a new device going into ngscopeclient/scopehal/scopehal? Thank you for this project.
<d1b2>
<azonenberg> FFTS is no longer required except if you are building unit tests
<d1b2>
<azonenberg> Docs haven't caught up to that change
<d1b2>
<azonenberg> SCPI is officially standardized by I think IEEE, but in reality there isn't much of a standard at all
<d1b2>
<azonenberg> Your scope should have a programming manual
<d1b2>
<azonenberg> I don't know what the PC interface for it is, it may not even be SCPI
<d1b2>
<azonenberg> (a lot of the PC attached scopes are not)
<d1b2>
<azonenberg> I dont know how complete it is
<d1b2>
<azonenberg> The way we normally handle PC attached scopes is to write a server application that calls whatever USB APIs are needed to interface with the scope and exposes data as a socket interface
<d1b2>
<azonenberg> which you can then write a libscopehal driver for
<d1b2>
<azonenberg> the reason for the split is that it avoids making libscopehal itself depend on a ton of third party libraries that anyone without a picoscope or hantek scope or whatever won't need
<d1b2>
<azonenberg> (it also allows you to plug the scope into a different computer than the one you're running ngscopeclient on)
<d1b2>
<azonenberg> as far as question 3, no. there is no template driver
<d1b2>
<azonenberg> we don't even have good developer documentation yet. in my spare time when not tackling more important issues like getting ready for the v0.1 release at the end of the year, i've been slowly building out Doxygen coverage so we at least have low level APIs documented
<d1b2>
<azonenberg> but high level "how to make a filter" or "how to make a driver" docs are a ways off
<d1b2>
<azonenberg> We're a small project without a lot of people and there's not enough hours in our days to do everything we want
<d1b2>
<azonenberg> And i figure low level docs are more important for helping people maintain existing drivers and fix bugs and stuff like that
<d1b2>
<azonenberg> and generally learn their way around the code. because the more people we have who understand the project at a low level, the more people we have who can help new contributors and write better docs
<d1b2>
<__._.o._.__> Thank you so much for all that detail. I understand trying to build an amazing project with a handful of people, I make a living at such a place... Let me say: You are succeeding.
<d1b2>
<azonenberg> in response to your question about IDEs, i use a plain text editor personally
<d1b2>
<__._.o._.__> Thats the plan then. pvachon/libhantek has about half the low level stuff done, and he did it very cleanly, and danielkucera had roughly the same amount done and 80% of a SCPI wrapper, so cobbling all that together should land me somewhere.
<d1b2>
<azonenberg> i grew up using visual studio '98 and '03 and when i switched to linux i tried a few IDEs, never liked any of them, and just started using plain old editors since then
<d1b2>
<azonenberg> Great. You can look at scopehal-pico-bridge and scopehal-waveforms-bridge as references for what a typical bridge server looks like
<d1b2>
<azonenberg> and the corresponding pico and digilent drivers in scopehal to see the client side
<d1b2>
<azonenberg> i'd suggest using them as reading material to learn how things work. the pico driver is more feature complete but also more complex as a result
<d1b2>
<azonenberg> The other reason we like separate servers for external scopes (i.e. ones without native scpi apis) is that it provides a license boundary
<d1b2>
<azonenberg> in this case libhantek looks to be 2-clause BSD which is compatible with our 3-clause BSD
<d1b2>
<azonenberg> but if it was e.g. a GPL'd sigrok module we couldn't legally link with it
<d1b2>
<azonenberg> while if you build a bridge sever, you can license the bridge however you want
<d1b2>
<azonenberg> and have the clientside code licensed differently
<d1b2>
<azonenberg> None of these high level design / architectural policy decisions are currently documented anywhere, it's something i need to work on
<d1b2>
<azonenberg> but again, time 🙂
<d1b2>
<__._.o._.__> haha I completely understand- I appreciate all of this so much. Hopefully I can make the return on your time
<d1b2>
<__._.o._.__> I share that boat as well - I always get strange looks for using two terminal windows, one for nano/vi(when commands come to mind), and one for builds. but its so uncluttered!
<d1b2>
<azonenberg> A few other things of note: this channel is the main coordination point for ongoing dev, we also have zoom calls at irregular intervals open to any interested contributors. they'll probably be more frequent in the next few months as we get ready for v0.1 release
<d1b2>
<azonenberg> tentative plan is v0.1 feature freeze december 1st, only bugfixes and documentation updates allowed from then until release
<d1b2>
<azonenberg> with release scheduled for end of year
<d1b2>
<azonenberg> you can of course do new feature dev in a fork, but we won't be merging new features during the freeze
<d1b2>
<azonenberg> This will be our first official release so we're still working out specifics
<d1b2>
<azonenberg> we also have a lot of work to do on binary packaging and stuff to get ready for the release
<d1b2>
<azonenberg> Goal is to have 0.1 out the door by the time the early access / developer edition ThunderScopes ship
<d1b2>
<azonenberg> then based on feedback from those users and the broader community, get an updated 0.2 release out before the remaining ThunderScopes ship
<d1b2>
<azonenberg> and have fairly regular releases from there on out
<d1b2>
<azonenberg> 1.0, whenever that happens, will be our first "stable" release with any level of API/ABI stability. in the 0.x series there are expected to be large, code-breaking refactorings happening frequently
<d1b2>
<azonenberg> We are expecting a large influx of new users when the thunderscopes ship and so trying to do a lot of work on the new-user experience between now and then
<d1b2>
<azonenberg> docs, UI improvements, etc
<d1b2>
<__._.o._.__> understood - I'll stay out of the way before then, maybe I can do some work in the ways of docs, its usually best to get that all in place from someone with fresh eyes In my experience
<d1b2>
<__._.o._.__> I'm very excited for you all. That is the first I'm hearing of thunderscope, which looks fantastic, and is hilarious because I just said to my boss the other day "when will scopes return to in-PC" and what-do-you-know
<d1b2>
<azonenberg> Yep. Our project is separate from the thunderscope but we do collaborate closely with their folks and they are using us as their UI
<d1b2>
<azonenberg> so obviously we are trying to make sure we're worthy of that choice
<d1b2>
<azonenberg> Doc help will definitely be welcomed. everything needs an update pass, we have almost 200 filter blocks and many have like a single sentence as their documentation
<d1b2>
<azonenberg> the getting started docs need to be updated as some dependencies have probably changed
<d1b2>
<azonenberg> we need to test the build instructions on supported platforms
<d1b2>
<azonenberg> a lot of the descriptions of how the UI works are out of date, e.g. the stream browser and filter palette are brand new (last month or two) and totally undocumented
<d1b2>
<azonenberg> (but i dont want to spend time writing that up yet because that's active development right now and anything we write in the next few weeks will be outdated as soon as it's written)
<d1b2>
<azonenberg> the artist is drawing new icons for the filter palette every day, and i have a bunch of code in the works for the stream browser
<d1b2>
<__._.o._.__> Thank you again, and good luck, the work done here is cutting edge, and may very well bring in the next generation of hardware hackers. I'll be watching closely!
<d1b2>
<fredzo_72653> @chille0417 Alientek DP100 ngscopeclient driver is up and running! 🙂
<d1b2>
<fredzo_72653> Along with HID transport support using hidapi. Tested on Windows OK and I managed to have CI builds for Mac and Linux too (will need testing).
<d1b2>
<azonenberg> Nice
<d1b2>
<azonenberg> I know i've been a bit behind on PR review and some other stuff, i've had a lot of on my plate and am working on trying to finish a work-adjacent PCB
<d1b2>
<azonenberg> hopefully once i get that out of the way i can finish the sidebar work i wanted to do