azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-3> [scopehal-apps] azonenberg db66737 - Added missing include of immintrin.h
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-3> [scopehal-apps] azonenberg 1d628ca - Fixed wait policy check
<azonenberg> miek: ooh
<miek> lol, the macro makes it look awful but here's the finished piece
<azonenberg> Nice
<monochroma> left hand thread SMA, just to fuck with people
<azonenberg> looool
<azonenberg> honestly that would make more sense than RP-SMA
<monochroma> XD
<azonenberg> miek: so what is the ultimate goal here, you're making your own cables?
<miek> yup
<azonenberg> is it really that much cheaper than buying premade, or do you have unique needs you can't find premade?
<azonenberg> These days i just buy from minicircuits
<miek> i've got a chunk of nice huber&suhner coax to use up :p
<azonenberg> Lol
<azonenberg> if you didnt have it, would you still buy coax and make your own SMA cable assemblies?
<azonenberg> It really doesnt seem worth it
<miek> for general use, yeah, it makes sense to just grab a bunch of mini-circuits cables (and i've got some on order)
<miek> i'm curious to see if there's any difference between the two. if they end up more phase stable or something, then it could be worth it
<azonenberg> In a week, i'll have my minicircuits SMA-to-N test leads
<azonenberg> Which i plan to try using instead of the ones that came with my picovna
<azonenberg> i suspect, based on published stats, that i will get much more consistent results
sorear has quit [Ping timeout: 244 seconds]
sorear has joined #scopehal
electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #scopehal
hlzr has quit [Quit: Connection closed for inactivity]
Nero_ has joined #scopehal
Nero_ is now known as NeroTHz
_whitelogger has joined #scopehal
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
bvernoux has joined #scopehal
juli965 has joined #scopehal
juli965 has quit [Quit: Nettalk6 -]
<_whitenotifier-3> [scopehal] azonenberg opened issue #229: Add support for filters that have multiple outputs -
<_whitenotifier-3> [scopehal] azonenberg labeled issue #229: Add support for filters that have multiple outputs -
<azonenberg> So i think it's time i finally did this
<azonenberg> i've jumped through too many hoops already not properly having M:N filters
<azonenberg> now the hard part, fixing all of the code that assumes a "channel" is 1:1 with a filter
<azonenberg> Architecturally, here's what i'm thinking
<azonenberg> The "data" field of a filter will continue to be the data of the first sub-stream
<azonenberg> there will be additional streams in additional data pointers
<azonenberg> which an "extract" filter provides a wrapper for
<azonenberg> This will easily fit into the existing object model, not require any expensive copying of waveform data around, but still provide support for multiple outputs
<azonenberg> so if you have say an i/q downconversion filter that spits out two streams, I would be the output of that filter and you'd access Q by extract(filter, stream 1)
<azonenberg> this would be somewhat hidden by syntactic sugar in the UI that would, for example, automatically instantiate extract filters for each stream in a filter
<azonenberg> Thoughts?
<azonenberg> moving to a full "a filter is no longer isomorphic to a scope channel" model would require a lot more refactoring
<azonenberg> So i want to avoid it unless someone can show me a really good reason why that model is better
bvernoux has quit [Read error: Connection reset by peer]
<azonenberg> lain, monochroma, electronic_eel, miek: thoughts?
<electronic_eel> azonenberg: if there is some easy way in the ui to get this extract thing I don't see any issues
<electronic_eel> how would you build a filter that has two (or more) inputs though? let's say you need the i/q output of one filter as inputs to do further processing on it. how would you do that?
<electronic_eel> and is this i/q input fixed to be coming from one specific filter, or would you be able to freely choose from which other filter the i and the q (separately) come from?
<azonenberg> electronic_eel: Two or more inputs we have already
<azonenberg> that works just fine
<azonenberg> the issue is, right now a filter is essentially a derived class from oscilloscopechannel
<azonenberg> and everything assumes a channel is a single time series of data
<azonenberg> well more precisely a channel has one waveform which is a single time series of data
<azonenberg> So the question is how to fit multi output into this
<azonenberg> In a way that will be clean and easy to work with in the future
<azonenberg> but preferably does not involve massive refactoring of every existing filter
<azonenberg> Although if we conclude that can't be avoided, i'll grudgingly tolerate it :p
<azonenberg> Another option would be to change OscilloscopeChannel::GetData() to take a stream argument
<azonenberg> So GetData(0) would act like GetData() does now
<azonenberg> GetData(1) would return the second output stream, etc
<azonenberg> This would avoid the need for any extraction filters, but we'd have to retool the ProtocolDecoder class to take a stream index along with each channel input
<azonenberg> Given that ProtocolDecoder needs to get renamed to Filter anyway, this might make sense as part of a larger refactoring
<azonenberg> Then in the UI, any time i list channels for inputs to something, i'd just list all of the streams of each channel
<azonenberg> This would also allow for you to have an *instrument* with multi stream output
<azonenberg> for example a RTSA with a single output channel and streams for I and Q in the single instrument
<azonenberg> in the single channel*
<electronic_eel> hmm, this GetData(0), GetData(1),... idea sounds better to me
<electronic_eel> but I haven't done any scopehal/glscope development yet, so I probably don't see all implications and amount of refactoring required yet
<azonenberg> It would require literally every single filter ever written be changed (although likely a ~2 line change to each one)
<azonenberg> the extract approach would be trivial to drop in, but i think would end up being kludgy and worse overall
<azonenberg> One of the reasons i did not make a 1.0 release is because i wanted the freedom to make massive API-breaking refactorings that would require every class in the project to be modified
<azonenberg> and not have anyone complain :p
<azonenberg> once we hit a v1.0 release we'd need to be a lot more careful about sweeping rearchitectures like that since it would break third party plugins etc
<azonenberg> But calling it v0.x implies there is no stability
<electronic_eel> could you overload the GetData() functions in a base class? so that it automatically works for the filters with just one output without refactoring?
<azonenberg> That's not the issue
<azonenberg> the issue is every filter that takes an INPUT needs to call GetData(stream ID) instead of GetData()
<electronic_eel> ah, right, and you must be able to select the stream id and it can be != 0
<azonenberg> Correct
<azonenberg> The ProtocolDecoder, to be renamed to Filter, class has functions that manage the actual list of inputs
<electronic_eel> could you put a shim-filter in between, that does nothing but select the stream id no if it is != 0?
<azonenberg> That was the proposed "extract" approach
<azonenberg> Less refactoring but would be much more awkward to work with
<azonenberg> I think it's the wrong solution long term
<electronic_eel> I thought this to be a short-term solution for the filters that were not refactored yet. so in the long term all filters will be refactored and can directly take in any stream id. but not yet converted filters could optionally use the extrac shim if necessary
<electronic_eel> this would also be a way to allow other to have out-of-tree custom filters (don't know if they exist yet). then you can deprecate the shim solution a few releases afterwards. this gives out-of-tree filter developers enough time to adapt
<azonenberg> Well the issue is, the shim would need a lot of UI work
<azonenberg> in order to e.g. have the shim show up in the dropdown for every time i create a filter
<electronic_eel> ah, ok. so because you know of no widespread out-of-tree filters yet, it isn't worth the effort for the ui work
<azonenberg> That is my thought
<electronic_eel> this would probably be a solution for later releases then, when you value api stability higher
<azonenberg> Correct
<azonenberg> I've intentionally not made a single binary release yet because that implies some level of stability/support
<azonenberg> and i am not ready to make that kind of commitment yet
<azonenberg> i know there's still significant things likely to change
<azonenberg> Like this
NeroTHz has quit [Read error: Connection reset by peer]
maartenBE has quit [Ping timeout: 258 seconds]
maartenBE has joined #scopehal
juli965 has joined #scopehal
bvernoux has joined #scopehal
<azonenberg> lain: ping
<lain> azonenberg: pong
bvernoux has quit [Quit: Leaving]
<azonenberg> lain: see above discussion
<azonenberg> looking for input on how best to fit filters with multiple outputs into the current object model
<azonenberg> f.ex I/Q downconversion
<lain> azonenberg: of the proposed ideas to avoid major refactoring, I think GetData(n) sounds cleanest
<azonenberg> well i mean that is still major refactoring. But i think it's the best solution
<lain> yeah
<lain> less major :P
<_whitenotifier-3> [scopehal-apps] azonenberg opened issue #161: Graphical filter graph viewer/editor -
<_whitenotifier-3> [scopehal-apps] azonenberg labeled issue #161: Graphical filter graph viewer/editor -
<monochroma> oooo filter graph editor
<azonenberg> That will be a significant project
<azonenberg> but we need one
<azonenberg> it's long overdue
<azonenberg> It's the kind of thing i'd like to dump off on somebody else
<azonenberg> I hope katharina is ok, havent seen her around in a while
<lain> :o
<lain> also like, fwiw, I think it's best to refactor this earlier if you have the energy to do so
<lain> I feel like full proper support for M:N filters is essential
<azonenberg> lain: the multi channel stuff? i'm about to start that right now
<azonenberg> like literally today
<lain> do you think GetData(n) is going to be the final solution to that?
<azonenberg> Yes
<lain> ah ok
<azonenberg> There will also be a companion method to get the name of an output stream
<azonenberg> for display in the graph editor etc
<lain> I'm not familiar enough with scopehal internals lol
<lain> makes sense
<azonenberg> i also want to fix some of the channel name generation as part of this revamp
<azonenberg> there's a bunch of stuff i'm gonna try to do at once
<lain> :3
<azonenberg> Also anybody have any idea how embeddable graphviz is in other apps?
<azonenberg> would it be worth looking into for layout of the graph editor?
<azonenberg> I feel like the directed acyclic nature of our graphs would mean we could do a fairly simple auto layout by topologically sorting
<azonenberg> basically do the same sort i do when multithreading
<azonenberg> source channels at column 0, anything that only depends on those in column 1, etc
<azonenberg> So i guess the 3 tickets i'm gonna try to hit during this refactoring are scopehal:#229, #165, #148
_whitelogger has joined #scopehal