<_whitenotifier-7>
[scopehal-apps] azonenberg c09e696 - Continued work on scope window management. Added support for HasFunctionImpedaceControls() etc in FunctionGeneratorDialog.
<d1b2>
<DriftingPancake> is there any decent way around having to manually copy in the vulkan SDK building scopehal from source? This seems likely to become a maintenance headache later
<d1b2>
<azonenberg> Siglent SSG driver now supports the low frequency oscillator, via the usual function generator input
<d1b2>
<azonenberg> LunarG has binary SDK packages in .deb format for recent Ubuntu, which also install fine on Debian in my experience
<d1b2>
<azonenberg> That's what I use on my dev workstation (debian bullseye)
<d1b2>
<DriftingPancake> ...ah. I don't really have any debian or derivatives installed; guess I'll see if AUR has something or just make a script to update it
<d1b2>
<azonenberg> The good news is that we do not depend on any ultra recent stuff. We should run down to vulkan 1.0, and use a few features of 1.2 if available (specifically, byte-addressable storage buffers in shaders)
<d1b2>
<azonenberg> so you should be able to just plop down one SDK version and not touch it for years
<d1b2>
<DriftingPancake> fair enough
<d1b2>
<azonenberg> And most of our other dependencies are pulled in as submodules or available in distro packages
<d1b2>
<azonenberg> the only one i know that doesn't fit in either category, besides the SDK, is FFTS. Which we are planning to move away from in favor of vkFFT
<d1b2>
<azonenberg> We already removed all clFFT calls with vkFFT, but have not yet fully transitioned away from FFTS
<d1b2>
<DriftingPancake> hmm ok
<d1b2>
<DriftingPancake> ffts I don't super mind since that at least goes through git
<d1b2>
<DriftingPancake> Thank you for the info!
Degi_ has joined #scopehal
<d1b2>
<azonenberg> So we care about FFTS because it's basically EOL, it's slow, and it seems to segfault on arm64
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
<d1b2>
<azonenberg> last commit was in 2017, it's unmaintained
<d1b2>
<azonenberg> But there is a general lack of non-GPL FFT libraries out there
<azonenberg>
Also, I know it's been dark on the probe front for a while. I've been busy w / ngscopeclient/glscopeclient work for a while, as well as waiting to hear back from Vishay WRT the components we RMA'd
<azonenberg>
They did their own investigation and confirmed the failure conditions we observed
<d1b2>
<DriftingPancake> ahh :\
<azonenberg>
So with any luck it won't happen again. They sent us a full FA report with root cause analysis but it's marked confidential so i'm not sharing in the main channel
<azonenberg>
But we will be assessing their response and deciding if we think the issues have been solved to our satisfaction before ordering production quantities of the parts
<d1b2>
<DriftingPancake> Trying to capture off the SDS2104X+; seem to get this after a few waveforms each open of the client
<azonenberg>
That's a read timeout
<d1b2>
<DriftingPancake> >Warning: Bad IDN response as well
<azonenberg>
means the driver sent a command and the scope didn't reply
<azonenberg>
if you run glscopeclient with --debug --trace SCPISocketTransport you will get a full log of every command sent and received
<d1b2>
<DriftingPancake> Seems the scope can't deal with sending back long captures on 4 channels at 10M memory depth
<d1b2>
<DriftingPancake> alright
<azonenberg>
pipe that to a file and see if it sheds any light on the problem
<azonenberg>
(it doesn't log raw binary waveform data transfers though)
<azonenberg>
it is possible that sending a large capture takes enough time it triggers some kind of timeout
<azonenberg>
the fix might be as simple as increasing the timeout
<azonenberg>
But their firmware is slow in general
<azonenberg>
they're nice scopes for entry level users, just not the best communications bandwidth
<d1b2>
<DriftingPancake> fair enough, maybe I'm simply asking a bit much of it
<azonenberg>
it is also possible our driver has a bug w/ large waveforms
<azonenberg>
they're slow enough idk how well tested multi megapoint captures on the 2000x+ are
<d1b2>
<DriftingPancake> Seems like you should still be able to make single-run work though, no matter what. I will try to figure out if I can
<azonenberg>
Yes. It's possible the read is simply timing out
<azonenberg>
as a quick hack, patch the SetRxTimeout() call in SCPISocketTransport::SharedCtorInit() (line 81) to a larger number
<azonenberg>
it looks like we wait 5 sec for a reply from the instrument and give up if none comes
<azonenberg>
(when this happens, if a reply comes in the future, the instrument may desync with the driver)
<d1b2>
<DriftingPancake> Ok, need to get a capture with a USB and play with it for the actual reason I needed it first, but after a bit of that I'll try all these things and get you a more complete picture of what's happening
<azonenberg>
Great. also ping @mubes who wrote most of the siglent driver, he's likely a good resource for issues on it
<azonenberg>
(Longer term, i'll probably make the timeout adjustable in preferences)
<d1b2>
<azonenberg> multiple waveform areas with splitting when you drag to the edge of an area
<d1b2>
<azonenberg> integrates nicely with the other docking stuff
<azonenberg>
there's still an issue where we do not handle the case of dragging a waveform into a floating (not docked) window that does not have any splits in it
<azonenberg>
So i'll work on that when i get a chance
<bvernoux>
ha interesting
<bvernoux>
the console is a must have also
<bvernoux>
for future we could even use it to launch some script or anything fun ;)
<azonenberg>
So the console is specifically a SCPI shell on a specific instrument
<azonenberg>
it's meant for sending commands a driver doesn't implement during dev/testing
<azonenberg>
and the log viewer is just a mirror of stdout
<bvernoux>
yes but for Oscilloscope it could be used for other stuff
<bvernoux>
the log viewer is clearly a must have
<azonenberg>
i'm not opposed to adding some kind of scripting interface etc in the future
<azonenberg>
but that's not what this is
<bvernoux>
as it is boring to check in windows or linux console with the GUI in an other place
<bvernoux>
and also the linux or windows cmd console are ultra slow and slow down everything when you have some traces in realtime I think the ImGui console is 100000x faster ;)
<azonenberg>
anyway, still a lot more to be done. like, you know, actually drawing waveform content :p
<bvernoux>
yes real waveform ;)
<bvernoux>
do you have tested HDPI too ?
<bvernoux>
as ImGui have some hint to manage it easily which was impossible with GTK IIRC
<azonenberg>
Someone said they played with it. I expect there will be bugs
<azonenberg>
i also have not tried changing font sizes etc yet (as there's no preference dialog in ngscopeclient yet)
<azonenberg>
the preference system exists but is not used for much
<azonenberg>
Yet
<bvernoux>
yes preference stuff from glscopeclient shall be rewritten
<bvernoux>
anyway in ImGui it is very simple and you do not need tons of line of code
<bvernoux>
also ImGui UI could be improved later
<bvernoux>
as it can be customized without changing any code of the UI of course
<bvernoux>
a bit like applying skin
<bvernoux>
But in a smarter way ;)
<bvernoux>
as skin often add overhead with "bitmap"
massi has quit [Remote host closed the connection]
<azonenberg>
So we will be adding an imgui dialog for the existing preference system
<azonenberg>
then probably adding some new preferences for themeing specifically of imgui
<azonenberg>
But that is not the highest priority right now
<_whitenotifier-7>
[scopehal-apps] azonenberg 55f1df2 - Initial skeleton of timeline. Blocked out space but just draw a gradient there for now.
<azonenberg>
lain, johnsel, louis: any suggestions on a good image library for loading PNGs (and possibly other formats) for toolbar icons etc? things to go with / avoid?
<azonenberg>
i've used FreeImage years ago and am inclined to go with that again
<azonenberg>
vs raw libpng, since it's format agnostic
<azonenberg>
(it calls out to libpng, libjpeg, etc under the hood iirc, but provides a format abstraction layer)
<lain>
I've used libpng in the past without complaints, but I don't have enough experience there to have a preference
<azonenberg>
yeah my question is more, do we use raw format libs or something higher level
<azonenberg>
given that we might be working with other image formats in the future too
<azonenberg>
on the other hand, how likely is that? all of our toolbar icons, color ramps, etc are simple lossless images so it might make sense to just have all external image resources be PNG and not support anything else
<azonenberg>
(I also plan to switch color ramps to an image format rather than raw rgba8 pixels like we have now, to improve maintainability)
<electronic_eel>
won't the gui icons be in some vector format instead of pixel based stuff? otherwise scaling is difficult
<azonenberg>
electronic_eel: i'm not going to attempt to render SVG in the app live
<azonenberg>
Some source files may be SVG, sure, but they'll be pre-rendered ti images at fixed sizes and we'll load the correct one for the GUI scale
<azonenberg>
but especially at small sizes like 16x16 it's common to do individual pixel tweaks to images to make them work better
<electronic_eel>
isn't svg rendering what the gui toolkits do by default nowadays?
<azonenberg>
No
<azonenberg>
generally you start with a svg, render to bitmaps at a range of sizes, then hand tweak the bitmaps to give nice clean lines and such
<azonenberg>
you might add more detail at a larger pixel scale that is best to completely remove vs trying to antialias when small
<azonenberg>
the windows .ico format for example is not a vector format
<azonenberg>
although it may be based on renderings of vectors way up the chain
<azonenberg>
but it's actually just a list of botmaps
<azonenberg>
bitmaps*
<electronic_eel>
i don't mean windows .ico. i mean things like current gnome or kde
<azonenberg>
look in /usr/share/icons/$theme/
<azonenberg>
you'll see directories for bitmaps at 8x8, 16x16, 22x22, 24x24, 32x32, 48x48, 64x64, 96x96, 256x256, 512x512, and svg versions
<azonenberg>
afaik almost everything uses the bitmaps
<electronic_eel>
i had the impression the prerendered images were just for "classic" window managers / desktop environments while the more modern ones do live rendering
<azonenberg>
AFAIK at small sizes you still want to use prerendered bitmaps
<azonenberg>
its a similar problem to font rendering
<azonenberg>
unless you have extreme levels of hinting at small sizes, you get artifacts where things dont line up exactly with pixel boundaries etc
<azonenberg>
it's often eaiser to just manually pixel-art like 8 bit game assets
<azonenberg>
and then switch to a scalable version for bigger stuff
<d1b2>
<Mughees> Can I get access to the project: git push -u origin burstwidthmeasurmentfilter Username for 'https://github.com': MugheesChohan Password for 'https://MugheesChohan@github.com': remote: Permission to glscopeclient/scopehal.git denied to MugheesChohan. fatal: unable to access 'https://github.com/glscopeclient/scopehal.git/': The requested URL returned error: 403
<azonenberg>
mughees: Generally we have folks start out developing in a local fork and send pull requests for changes
<electronic_eel>
isn't this the https vs. ssh submodule issue?
<azonenberg>
and then you get direct push access after a period of steady contributions that don't need extensive rework etc
<azonenberg>
electronic_eel: no he's trying to push to the upstream repo
<azonenberg>
not his own fork
<azonenberg>
and he's a brand new team member who doesn't yet have commit access
<electronic_eel>
yeah, but doesn't that happen when you just fork the main repo and recurse submodules?
<azonenberg>
the URL in the error message is pointing to the upstream repo
<azonenberg>
if you fork the main repo and not the submoudules you'll get errors where the relative paths point to nonexistent forks under your account
<azonenberg>
to me this looks like github access controls working as designed and intended
<electronic_eel>
yeah, right
<d1b2>
<Mughees> hmmm. i am not a very super git user....
<d1b2>
<Mughees> i cloned the scopehal repo directly ..then branched locally..made my changes and then i am trying to push upstream
<azonenberg>
@louis: can you give Mughees a hand setting up local forks he can push to?
<azonenberg>
Mughees: you'll need to make a fork of the upstream repo under your github account
<azonenberg>
push your changes there, then send a pull request to the upstream repo that a core developer can merge after code review
<d1b2>
<Mughees> hmmm....right..i think i get it now
<azonenberg>
We don't hand out push access to the main repo like candy, you have to earn it :)
<d1b2>
<Mughees> 🙂
<d1b2>
<Mughees> Sorry...The disadvantages of years of closed source development
<d1b2>
<Mughees> i wasn't aware of this flow
<azonenberg>
Yeah. We do give more experienced devs direct access to the upstream repo to skip that step, but it takes time to earn that level of trust
<azonenberg>
And yeah i think github enterprise accounts have more fancy access controls
<azonenberg>
like allowing specific accounts to push to some branches but not others
<azonenberg>
But the project is on a free account that i dont think has nearly as fine grained controls
<azonenberg>
that is definitely the kind of thing to look into as the project grows though
<d1b2>
<ehntoo> The pull request workflow isn't all that onerous once you get used to it, either. Definitely a little tricky to pick up on the first time through.
<azonenberg>
ehntoo: yeah the bigger issue is that if you change origin for your local working copy to your personal fork
<azonenberg>
the relative paths in the submodules mean you now have to fork and maintain sync to all of the submodules
<azonenberg>
but the alternative is to put absolute paths in .gitmodules which has its own can of worms
<azonenberg>
this is one thing i wish git handled better
<azonenberg>
If your personal fork is a push-only sandbox for PRs and you never pull from it, and you still have origin set to upstream, it's a non issue
<d1b2>
<ehntoo> Yeah, that part isn't so great.
<d1b2>
<Mughees> And yeah I have been using SVN for a long time too 😁
<azonenberg>
Great. I'll have a look at that in a bit
<d1b2>
<Mughees> oh so here it appears...yayyy..i hope this is right flow now..
<azonenberg>
And yes, we have a bot logging issues, pull requests, etc to the developer chat. Handy for staying on top of status
<d1b2>
<Mughees> And since this is my first PR... I want everyone to be absolutely lethal....
<azonenberg>
mughees: Before I even look at your code, my first feedback is that it needs to be documented. So please add a page to the user manual (under scopehal-docs) describing this filter
<azonenberg>
and send a companion PR for the documentation
<d1b2>
<Mughees> the .tex documenrts right?
<azonenberg>
We already have about 90 filters that have next to no documentation, and I don't want to make the problem worse. So as a general policy any contributions of new filters must be paired with a PR against the documentation
<azonenberg>
Yes
<d1b2>
<Mughees> Sure
<azonenberg>
I'm in the middle of some stuff and it might be a few hours before I get around to reviewing the code. Will let you know if there's any issues that need fixing before it gets merged
bvernoux has quit [Read error: Connection reset by peer]
<azonenberg>
Significant performance regression (OOM or more) in the i2c decode, possibly others, due to the new waveform data model. more precisely due to the code refactoring to handle sparse vs dense input being done lazily
<azonenberg>
investigating now, i have idea on solutions
<azonenberg>
actually maybe it's just an infinite loop
<azonenberg>
ok yeah its just an infinite loop lol