Non-atomics read and written on different threads?

[cubicvoid]

Thanks for this project, it's really helpful in understanding parameter values vs modulation! I did find a potential conflict between the parameter handling and the CLAP spec. Defining your parameter values you have:

    // These items are ONLY read and written on the audio thread, so they
    // are safe to be non-atomic doubles. We keep a map to locate them
    // for parameter updates.
    double unisonCount{3}, ...

but it seems like these are also read on the main thread. They're read (via pointers in the paramToValue map) from paramsValue(), implementing clap_plugin_params.get_value:

/// The host can at any time read parameters' value on the [main-thread] using
/// @ref clap_plugin_params.value().
...
   // Gets the parameter plain value.
   // [main-thread]
   bool (*get_value)(const clap_plugin_t *plugin, clap_id param_id, double *value);

This looks to me like these should be atomics, or maybe use cached values when accessing from get_value. Perhaps I'm misunderstanding something about the spec or the contextual assumptions (maybe there's some reason get_value is never concurrent to process)? But I was specifically looking for examples of thread-safe parameter handling in get_value so this stood out to me.

[baconpaul]

No i think you are correct. Those should be atomics, or there should be a cache which is atomically updated at the end of process indeed.