Fix default_on_toggle and value_map decoding of named float structs

[jcelerier]

Two independent bugs found while building a process on top of this binding.

default_on_toggle defaulted to off

default_toggle and default_on_toggle were both toggle_setup{.init = false}, so the only thing separating them was the name. Any control declared halp::toggle<"...", halp::default_on_toggle> came up off.

It stayed invisible because a toggle reading false looks exactly like one the user turned off, and the binding initialises controls from range().init only in the host — a unit test constructing the object directly sees the same value either way.

A named all-float struct lost its value crossing ossia::value

to_ossia_value_impl tests for field names before vec-compatibility, so a struct with 2/3/4 float members and halp_field_names encodes as a value_map. The inbound path tested the two in the opposite order, took the vecNf shortcut, and called ossia::convert<vecNf>(map) — which returns zeroes.

So the round trip silently dropped the data: a std::vector of such structs (the ordinary shape for detector or tracker output) arrived as a list of correctly-sized, entirely zero elements. Downstream code saw the right number of entries with every field at 0.

Maps are now routed through the field-order decoder in both the nested and the top-level overload. Unnamed all-float structs still encode as vecNf and are unaffected, as is a bare vecNf sent by an external source.

Testing

Both directions are covered by a regression test in score (Tests/from_ossia_value_Test.cpp), which asserts the named struct round-trips, that an unnamed one still encodes as vec3f, and that a plain vec3f from an external sender still decodes into a named struct.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DnNVzm2dPA5iHbSYKrpzZj