param_json.hpp File Reference

The one place a parameter becomes JSON. More...

#include <string>
#include <choc/containers/choc_Value.h>
#include <pulp/state/parameter.hpp>

Go to the source code of this file.

Namespaces
namespace	pulp
namespace	pulp::state
	SequencerStateChannel is the audio-safe transport for a plugin's structured NON-parameter state: the bulk, observable state a step sequencer / mod-matrix / pattern engine holds outside its automatable parameter set (e.g.

Functions
std::string	pulp::state::param_display_text (const ParamInfo &info, float value)
	Display text for value in info's own domain.
bool	pulp::state::param_parse_display_text (const ParamInfo &info, const std::string &text, float &out_value)
	Parse display text back into info's own domain.
choc::value::Value	pulp::state::param_metadata_to_value (const ParamInfo &info)
	A parameter's STATIC shape — everything that does not move when the value does.
choc::value::Value	pulp::state::param_snapshot_to_value (const StateStore &store, const ParamInfo &info)
	A parameter's LIVE snapshot, in the inspector's established wire shape.
choc::value::Value	pulp::state::param_catalog_snapshot_to_value (const StateStore &store, const ParamInfo &info)
	The canonical Product A catalog + live-value shape.

Detailed Description

The one place a parameter becomes JSON.

A parameter's shape is about to have several consumers — the scripted-UI bridge, the dev inspector, @pulp/react's generated typings, the generated JS-bridge reference, and later a UI lint that checks a script's param="…" references against the declared set. Each of those could hand-roll its own object, and then a field added for one silently would not exist for the others.

So there is exactly one serializer, and every consumer calls it. Sync is not a convention anyone has to remember; there is only one implementation to get right. A second hand-rolled parameter payload appearing anywhere is a review-stopper, not a style preference.

Wire compatibility. param_snapshot_to_value is what the inspector protocol already sends. Its field names are load-bearing for existing clients: id, name, unit, value, normalized, modulated, default, min, max, and display (present only when non-empty). Those may not be renamed or made unconditional. New fields are additive only, and test_param_json.cpp pins the set so an accidental change fails a test rather than a downstream client.

Real units first. Everything here reports a parameter's own domain, with normalized alongside it, so a consumer never has to re-derive skew maths from a 0-1 float. The bridge's older getParam/setParam remain normalized and are deliberately untouched.