<_whitenotifier-3>
[scopehal] azonenberg opened issue #229: Add support for filters that have multiple outputs - https://git.io/JUvlt
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #229: Add support for filters that have multiple outputs - https://git.io/JUvlt
<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