<_whitenotifier-e>
[scopehal] azonenberg a51351b - Refactoring: Removed Filter::IsOverlay() method as well as all overrides in derived classes. Now redundant as there's other ways to get this info.
<azonenberg>
ok that's the first step towards the refactoring we were talking about the other day
<azonenberg>
now, when a filter is created i determine if it's an overlay or not based on whether it outputs a digital or complex type
<azonenberg>
if so, it's an overlay
<azonenberg>
if not, a new channel
<azonenberg>
once created, i determine overlay or not based on whether it's in the list of overlay
<azonenberg>
overlays*
<azonenberg>
The next step is going to be a more extensive refactoring of waveform area handling of overlays and multiple channels
<azonenberg>
i think this was the key core refactoring of it though
<azonenberg>
the next step will be to make a WaveformArea a FlowGraphNode with a single input (preserving the one-analog-input-per-waveform-area restriction we have now)
<azonenberg>
and then start looking into how to do multiple inputs in this model, and fitting overlays into the same model
<azonenberg>
should make things a lot cleaner long term
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
<azonenberg>
Ok sooo hmm
<azonenberg>
So this is getting a bit more complex
<azonenberg>
because the object hierarchy is a bit tricky
<azonenberg>
An OscilloscopeChannel has one or more output streams and all of the usual settings you'd expect from something that outputs a waveform
<azonenberg>
A FlowGraphNode has zero or more input streams and zero or more parameters
<azonenberg>
a Filter is a FlowGraphNode and an OscilloscopeChannel
<azonenberg>
a Trigger is a FlowGraphNode but not an OscilloscopeChannel
<azonenberg>
and now I want to make WaveformArea a FlowGraphNode too
<azonenberg>
the challenge is, right now the filter graph editor assumes everything in the graph is an OscilloscopeChannel
<azonenberg>
but this means we cannot display triggers in the graph editor
<azonenberg>
nor can we add waveform areas
<azonenberg>
If we change the editor to work on FlowGraphNode's, then it won't be able to work with actual scope channels
<azonenberg>
So i'm contemplating making OscilloscopeChannel derive from FlowGraphNode
<azonenberg>
Which seems to make the most sense
<azonenberg>
it will simply be a node that has no inputs
<_whitenotifier-e>
[scopehal] azonenberg 2616f23 - Refactoring: OscilloscopeChannel is now a FlowGraphNode
<azonenberg>
Yeah i think that makes sense. Now I'm working on refactoring FilterGraphEditor / FilterGraphEditorWidget so that it can work with FlowGraphNode's that are not OscilloscopeChannel's
<azonenberg>
Trigger's will be the first test case
<_whitenotifier-e>
[scopehal-apps] azonenberg 78c9671 - FilterGraphEditorWidget: refactoring to support FlowGraphNode's other than OscilloscopeChannel's. No such nodes are implemented, but the data structures now allow for it.