Named value channels: what a processor's DSP is computing, reachable by name from its UI. More...
#include <cstddef>#include <cstdint>#include <functional>#include <memory>#include <string>#include <string_view>#include <vector>#include <pulp/dataplane/value_channel_telemetry.hpp>Go to the source code of this file.
Classes | |
| class | pulp::dataplane::ValueChannelSet |
| A processor's declared channels. More... | |
Namespaces | |
| namespace | pulp |
| namespace | pulp::dataplane |
Typedefs | |
| using | pulp::dataplane::ValueChannelVisitor = std::function<void(ValueChannelSet*)> |
| Runs a value-channel operation while the hosting processor guarantees that the exposed set and all of its sources remain alive. | |
| using | pulp::dataplane::ValueChannelAccess = std::function<void(const ValueChannelVisitor&)> |
Named value channels: what a processor's DSP is computing, reachable by name from its UI.
A Pulp plugin's UI can already show a parameter, because a parameter has a name the UI can ask for. It cannot show gain reduction, an envelope follower's output, or a detector's state, because those live inside process() and have no name anywhere. The workaround is a hand-rolled TripleBuffer and a bespoke binding per plugin, which is why most plugins simply do without.
A ValueChannelSet gives those values names. The processor declares them once, publishes into them from process() through the same lock-free MeterSource / ScalarSource / VectorSource / EventSource channels a view already binds to, and a UI — native or scripted — asks for them by name.
The source buffers remain in-process visualization channels. An optional transport-free telemetry attachment can observe UI-consumed snapshots and a bounded producer event tap without becoming another source-buffer reader.
Two properties are deliberate: