Can the proc macro generate messages recursively? #122
Comments
sowbug
added a commit
that referenced
this issue
Apr 2, 2023
As we make progress toward #122, we need the ability to specify certain #[nano] fields that can be handled by update(), but aren't expected to respond to F32ControlValue. An example is EnvelopeParams, which could be flattened into ADSR, but is better as a serializable thing that isn't a controllable thing. This meant teaching #[nano] that some fields should populate the Nano params struct, and should be handled in update(), but should not appear in the automation GUI or respond to F32ControlValue (which makes no sense <EnvelopeParams>::into()). - Taught #[nano] to be smarter - Moved ToySynth -> DebugSynth, and created a more standard ToySynth - Moved all the proc-macro tests from struct-sync into the orchestration crate, so that they'll be tracked with this repo and tested.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If we embed one Nano type inside another, the desired outcome would be an enum whose type is that embedded Nano type. And so on. This is preferable to flattening the struct. It could also allow a variable number of complex parts in an instrument, like an N-operator FM synth.
The text was updated successfully, but these errors were encountered: