The modulator "misc" (phasor and random) panel

[baconpaul]

Here's the panel

Here's how I would do it

Step one: include the data

• src/configuration.h add numPhasorsPerGroupOrZone{4} and numRandomsPerGroupOrZone{4}
• src/modulators/modulator_storage.h
  • add PhasorStorage and RandomStorage
  • PhasorStorage contains PhasorConfig which looks roughly like enum Mode, enum NoteStyle, int16_t num, int16_t den and then a std::array<PhasorConfig, numPhasors>
  • Random is easier. Just an enum and an array of the enums
  • I would probably then add a MiscModulatorsStorage which just contains a PhasorStorage and RandomStorage and treat it as a single 'thing'.
• src/has_modulators.h is a mixing which group and zone inherit to get modulators so add a modulator::MiscStorage but you only need one of them (since this is the entire zone so there's only one Misc with one PhasorStorage per zone which contains inside it 4 PhasorConfigs etc...)
• Make it stream. Follow the curve example. Pretty clear.

Step two: make the screen

• well trodden at this path but basically
• Make something like LFOPane which is called MiscPane
• Add the messages to update the values. For these we can just do it in bulk we don't have to do per field since they are small and infrequently edited. So probably add an s2c_set_misc_modulators and c2s_update_misc_modulators and so on. Thread it through just like the curve

Step three: make it work in the engine. This will be a non-compatible break with prior patches and that's OK.

• The engine has this

  Transport transport;
  void onTransportUpdated();
  std::array<float, numTransportPhasors> transportPhasors{};
  void updateTransportPhasors();

so go stare at that. I think the mistake I made is that everyone gets the same transport phasor set. So I propose something roughly akin to

1. Replace that code with a sort of 'single clock phasor' which has int beatPhasor, float subBeatPhasor
2. Add something like `engine::configPhasorValue(beatPhasor, subBeatPhasor, PhasorConfig) which does the equivalent of updateTransportPhasor. (This has the side effect of doing that modf per zone so we may want to, once this is done, open an issue to cache phasors by config for performance reasons)
3. Add a PhasorProcessor (different than the storage) which calls that and presents the value. Make one a member on voice and bind that value to the voice mod matrix. Similarly make that a member on group and bind it to the group matrix, removing the old phasor bindings. You'll probably need more notes here but luckily I refactored all the phasors to be shared in modulation_shared/TransportPhasorBase
4. code, test, ask on discord at this point basically.

[Andreya-Autumn]

Tackling this now. Just to be sure @baconpaul, the "make it stream" example I'm meant to follow is the SC_STREAMDEF macro in modulation_traits, no?

[Andreya-Autumn]

...and if so. How exactly should I deal with the enums? I see there's a STREAM_ENUM macro but it's not clear to me how that interacts with the stream def one.

[baconpaul]

Yes And for stream enum it’s thee parts By the enum in the header define a to string pair - there’s a macro for that just look at play mode or lfo curve shape or what not In the cpp implement it Then define it streamable in the json

this seems a lot but it stops us being sensitive to streaming breaks from enum reordering

[Andreya-Autumn]

Ah right ok! It's coming back slowly sorry. Haven't been outside of processors much... 😅 Will take another dig at it tomorrow.