<d1b2>
<vipqualitypost> lol, i somehow assumed that my macbook air would build worse than my desktop pc, but so far I think the build is actually faster on the mba (m1!)
<d1b2>
<vipqualitypost> ok, so build was smooth but app does not run
<d1b2>
<david.rysk> yep, you have to run it from msys2
<d1b2>
<david.rysk> for now
<d1b2>
<vipqualitypost> ahh
<d1b2>
<david.rysk> I probably should fix the instructions to say that
<d1b2>
<vipqualitypost> it says "may run outside of msys2" so you did CYA 😄
<d1b2>
<vipqualitypost> I just didn't realize the implications.
<d1b2>
<vipqualitypost> awesome, just works right out of the box!
<d1b2>
<vipqualitypost> I will say: i think you are missing a dependency for make, and also to build, I needed to use cmake --build . rather than make -j4
<d1b2>
<azonenberg> Yeah fixing these rough edges are the main kinds of things blocking us from an official v0.1 release
<d1b2>
<vipqualitypost> did demo scope get updated? Edge transisions on prbs and 8b10b are softer than in my mac build
<d1b2>
<vipqualitypost> happy to pr this if you are busy
<d1b2>
<david.rysk> there's a filter that doesn't work on mac because of ffts dependency
<d1b2>
<david.rysk> there should be a dependency on ninja already instead of make
<d1b2>
<david.rysk> so you shouldn't need make, the make -j4 is probably wrong
<d1b2>
<vipqualitypost> ah, ok
<d1b2>
<azonenberg> @vipqualitypost if you open up the channel properties
<d1b2>
<johnsel> see this is why I run the CI code for projects
<d1b2>
<azonenberg> you'll see there's modes for each demo channel to specify ideal, ideal + noise, ideal + noise + bandwidth limit
<d1b2>
<vipqualitypost> got it, thank you
<d1b2>
<azonenberg> the BW limit is done with an FFT and is using legacy code that doesnt work on mac
<d1b2>
<azonenberg> long term the plan is to a) transition that code to vkFFT so it works cross platform and is faster and b) make it use full s-parameter channel emulation so we get more realistic rising/falling edge shapes
<d1b2>
<azonenberg> rather than the, i think, 5 GHz brick wall filter it uses now
<d1b2>
<josHua> @david.rysk hm, have you successfully built this stuff on osx recently? I am having a hell of a time convincing it to build an arm64 binary with openmp
<d1b2>
<david.rysk> I have... hmmm lemme try again
<d1b2>
<vipqualitypost> i built it a week or two ago and didn't have any issues, i think?
<d1b2>
<vipqualitypost> on arm64
<d1b2>
<david.rysk> it's been a bit since I've been a little distracted here with other things like plumbing repairs 😄
<d1b2>
<josHua> ok, I will try harder
<d1b2>
<david.rysk> I will try again, if you can share logs/errors I'd always appreciate it
<d1b2>
<josHua> yeah, I didn't want to bug folks until I had most of a solution
<d1b2>
<josHua> I halfassed trying it last night and gave up
<d1b2>
<david.rysk> eh don't feel bad about bugging us 🙂
<d1b2>
<josHua> and kind of ran out of time also
<d1b2>
<david.rysk> we did update the manual though
<d1b2>
<david.rysk> (but there are still some bugs, as @vipqualitypost just found out)
<d1b2>
<josHua> (I am eyeing modifying the Rigol plugin to support my new desk toy)
<d1b2>
<josHua> afk a bit
<d1b2>
<david.rysk> oh nice, which model?
<d1b2>
<josHua> dho4404
<d1b2>
<vipqualitypost> ooh, fancy
<d1b2>
<vipqualitypost> did you figure out the color grading?
<d1b2>
<josHua> yes, if I had it set to a 1Mpt sample and the window was not 1Mpt wide, it got confused and upset
<d1b2>
<david.rysk> if you don't have libomp linked, you need to do cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH="$(brew --prefix);$(brew --prefix)/opt/libomp" (page 23 of the manual)
<d1b2>
<david.rysk> grr this still doesn't copy/paste well, I thought I fixed that...
<d1b2>
<vipqualitypost> msys seems kind of close to a regular linux shell but a bit goofy
<d1b2>
<vipqualitypost> if i wnt to add ngscopeclient to path so i can run it without digging into the build dir how does it work?
<d1b2>
<vipqualitypost> i tried adding it via export PATH=$PATH:/path/to/build.exe but this doesn't seem to do anything when i run it
<d1b2>
<azonenberg> as of now i think people just run from the build directory
<d1b2>
<vipqualitypost> mehh, ok
<d1b2>
<azonenberg> (this is the sort of polish we need for an official release)
<d1b2>
<david.rysk> you'd need to copy all the missing dlls to the build directory, but there's stuff about finding dependent files that's not finished
<d1b2>
<johnsel> did you remove the link to bvernoux binary to do that entirely?
<d1b2>
<david.rysk> it's disabled, I don't like the build scripts downloading and running code
<d1b2>
<johnsel> agreed, but @vipqualitypost might want to run it to get those dlls
<d1b2>
<vipqualitypost> oh i don't mind having to run in msys shell
<d1b2>
<vipqualitypost> but it is annoying to dig into build dir, so just adding that to path would be sufficient for me
<d1b2>
<vipqualitypost> looking into this as some people online seem to suggest it should work
<d1b2>
<johnsel> it's still in there though it seems @david.rysk
<d1b2>
<johnsel> let me check those tiny downloads for it
<d1b2>
<johnsel> wow you really did a number on the scripts @david.rysk lol
<d1b2>
<vipqualitypost> ah i didn't realize the working directory also needs to source the dlls? this makes sense why it doesn't work but feels dumb
<d1b2>
<vipqualitypost> oh windows
<d1b2>
<vipqualitypost> oh i broke something and it doesnt open at all now lol
<d1b2>
<johnsel> you're learning why we hate msys2
<d1b2>
<johnsel> I can't find bvernoux script anymore in the current HEAD either
<d1b2>
<johnsel> might be me though
<d1b2>
<johnsel> if you reaaally want I can dig in history for it
<d1b2>
<johnsel> it builds up the list of dlls and copies them in the build output directory
<d1b2>
<vipqualitypost> oh wait
<d1b2>
<vipqualitypost> i'm only in msys shell not ucrt
<d1b2>
<johnsel> see
<d1b2>
<johnsel> easy
<d1b2>
<vipqualitypost> adding ngscopeclient build dir to path does work, if you have the right shell open
<d1b2>
<vipqualitypost> nice
<d1b2>
<vipqualitypost> what even is the distinction between those things
<d1b2>
<david.rysk> There are various dependent files like fonts and the code for finding them needs some work
<d1b2>
<david.rysk> I started that work but must get back to it
<d1b2>
<azonenberg> Longer term, once we start working on distro native packaging
<d1b2>
<azonenberg> i want to stop distributing fonts as much
<d1b2>
<azonenberg> in particular, things like bitstream vera we should be able to just pull in as a dep in the package manager
<d1b2>
<azonenberg> (or ideally integrate with freedesktop APIs to find the actual user selected theme font)
<d1b2>
<azonenberg> and set that as default
<d1b2>
<azonenberg> so many more things to do
<d1b2>
<vipqualitypost> is there a list of low hanging fruits?
<d1b2>
<vipqualitypost> i would be happy to try some stuff, but i don't have a ton of experience here, but can at least poke at it, like the hidpi stuff a few months back 😄