<_whitenotifier-1>
[scopehal-apps] azonenberg 1bec202 - Added raw trigger position control to trigger properties dialog
<azonenberg>
Ok so, now that we have multiscope working in ngscopeclient (better than it ever did in gl)
<azonenberg>
i think the only remaining feature of glscopeclient not yet present in ngscopeclient is spectrogram/waterfall. the filters work but the rendering is borked and i really need to just rewrite them a bunch
<azonenberg>
Is anyone else here still using glscopeclient for anything? if so, what's holding you back from switching to ng?
Darius has joined #scopehal
bvernoux has joined #scopehal
<azonenberg>
o/ bvernoux
<azonenberg>
are you still using glscopeclient for anything or are you all on ng now?
<bvernoux>
azonenberg, mainly using ng
<bvernoux>
azonenberg, I think glscopeclient can be set to deprecated as ng have all features or more except if you see something blocker ?
<azonenberg>
bvernoux: The only things left that gl can do that ng cannot, now that i have multiscope working as of this week
<azonenberg>
are the rendering shaders for spectrogram and waterfall displays
<azonenberg>
I intend to get those done in the next week or two then completely remove gl from master. people can dig it out of git history if they really need it but i want it gone
<azonenberg>
because then we can cut it out of the build system and start shedding dependencies
<bvernoux>
I think a major things will be to add cheap LA support in ng
<bvernoux>
as Pulseview and Sigrok are dead
<azonenberg>
we support the dslogic already
<bvernoux>
I will test it as I was thinking it was WIP
<bvernoux>
yes removing gl version is a good things to speedup the build and focus only on ng version
<bvernoux>
Potentially do some major change which was locked to support the old glscopeclient
<azonenberg>
yes
<azonenberg>
I have some plans for some significant refactoring once gl is gone
<azonenberg>
for example i want to start using stl shared_ptr's for instruments rather than raw pointers
<bvernoux>
ha yes great
<bvernoux>
a very good point to have a bigger user base mainly everyone using Pulseview will be to check if the sigrok compat layer is fully working
<bvernoux>
I saw it but it is not clear and not part of the build today
<bvernoux>
Then more and more guys with dslogic could start testing seriously ngscopeclient
<bvernoux>
About oscilloscope I think it is pretty an ultra niche as actual popular scope like Rigol MSO5K or Siglent are very slow over Ethernet/USB and I will say at 2 or 3waveform/s it is not really something usable
<azonenberg>
keep in mind, most of the development of ngscopeclient and libscopehal is not driven by hobbiysts using "popular" scopes
<bvernoux>
To be sincere I do not use my Rigol MSO5K with ng because of that and it is clearly not the fault with ng it is the fault of the slow SCPI stuff ...
<azonenberg>
it's driven by people like me and MP who are using it in production in well funded labs
<azonenberg>
if it works with cheap scopes, great. if that attracts more users and devs, great
<azonenberg>
but that's not the core focus
<bvernoux>
Yes it is why I say that will attract more users with LA and even more if cheap salea logic clones... are supported
<bvernoux>
At least to have feedback on the usage and to be tested on more configurations (I suspect mainly slow PC with embedded GXF card for a majority of users)
<bvernoux>
A good things will be to add EEZ BB3 support but I'm not sure if there is a big user base
<azonenberg>
I'm all for people adding drivers for more gear, i just don't have the time to do it myself. My focus is stuff i personally use
<bvernoux>
Yes me too
<bvernoux>
Support of SDR could be also a very big plus
<bvernoux>
especially to be used for scientific stuff not just do like SDR++ which is only for HAM guys doing FM, USB, LSB...
<bvernoux>
In clear to really decode the data and visualize it in advanced mode for signal analysis
<bvernoux>
Especially for SDR like BladeRF v2 ...
<bvernoux>
But I think it is clearly not the priority so far even if you are adding waterfall/spectogram display so it is not far
<azonenberg>
We already have waterfall and spectrogram filters
<azonenberg>
We just don't have the shader in ng to actually render the output
<azonenberg>
(and some refactoring of the code is planned as part of this, likely as part of deprecating gl)
<bvernoux>
Do you are planning to do everything in Vulkan and at end removing totally opengl support ?
<bvernoux>
I imagine it was the plan especially to support easily other host plateform OS like MacOS ...
<azonenberg>
ng has been all-vulkan from day one
<azonenberg>
gl is actually all vulkan except for the final compositor
<azonenberg>
Which is still opengl
<bvernoux>
so you are planning to rewrite the final compositor in short/mid term too ?
<azonenberg>
no, i'm planning to delete glscopeclient and take all the opengl code with it :p
<bvernoux>
hehe
<bvernoux>
because glscopeclient have not only opengl dependencies but crappy gtk stuff which was the most important point I think
<bvernoux>
but yes totally removing opengl is a must have especially to do all in Vulkan
<azonenberg>
yeah getting rid of the gtk dependency is the big thing
<azonenberg>
eventually i want to be able to stop using msys2 and just do native windows builds without all of that hassle
<azonenberg>
we're not quite there yet but the less stuff we pull in from msys2 the better
<bvernoux>
On the other side Visual Studio dependencies are not very nice too
<bvernoux>
It's quite bloated in some case even more than msys2
<bvernoux>
But that can be managed to build it with special option to remove the crappy MS DLLs
<bvernoux>
In static build
<azonenberg>
i dont care about OS provided dependencies
<azonenberg>
i just care about how much the user has to install manually
<bvernoux>
there is always the msvc dll crap by default
<bvernoux>
where you shall install them from MS as it is not integrated after a clean install of Windows even on Win11
<bvernoux>
Which can be avoided with build option but at end with bigger exe
<azonenberg>
oh you mean the c++ runtime?
<azonenberg>
we do not want to do static builds. i hate static builds, dlls exist for a reason
<azonenberg>
it is a bit annoying that MS doesn't package msvcrt with windows and ship it out with windows update though
<azonenberg>
like any linux distro does with their libc