Ported Rings firmware into Clouds

So I just managed to port the Rings firmware (mostly) into both my diy Clouds modules (with the aim of getting multiple voices playable via an FH-2 without having to build more Rings modules).

Rerouted all of the ADC channels so that they correspond to the Clouds inputs and pots (with the exception of the attenuverters). Also managed to modify the LED code so that it recognises the resonator and polyphony modes. I might even make the Freeze button (unused at the moment) change between Easter Egg mode.

One thing I still need to develop understanding of is the normalization probe (which is absent in Clouds). I rerouted the GPIO pin for the trigger input in the Clouds hardware to correspond to the Strum input in the Rings code (GPIOB, GPIO_Pin_6) and this works in Easter Egg mode with nothing plugged into the input, however, in normal mode, the trigger does nothing except causes the LEDs to flash.

Firstly, what is the purpose of the normalization probe?

Secondly, can any pin in the STM32 be used as a normalization probe (e.g. can I use the GPIOB, GPIO_Pin_7 as a normalization probe, which was for the Clouds Freeze CV input)?

1 Like

Any pin can be used.

This pin is toggled pseudo-randomly. If the same pseudo-random pattern is read on a CV, audio, or trigger input (STRUM, V/O, or IN in Rings), we know that nothing is patched in the corresponding input.

You may have to adjust the rate of the random pattern, and the code matching the audio/CV/trigger input with this pattern to account for the fact that clouds’ audio and CV inputs may have a different bandwidth or polarity from Rings’.

The random triggers are a hint your code is not working and the module does not detect that the trigger input is unpatched.

1 Like

Thanks Emilie, I think I understand now. So the normalization probes is just for detecting whether an input is patched or not.

Currently, I’m not getting random triggers. The issue that I’m having is that in Normal mode, patching anything into the strum input does nothing except flickers the LEDs.

I messed around with the code some more and discovered that it has something to do with the exciter normalization. The trigger seems to work when I make the following modification to the internal exciter line below:

  bool internal_strum = normalization_detector_trigger_.normalized();
//  bool internal_exciter = normalization_detector_exciter_.normalized();
  bool internal_note = normalization_detector_v_oct_.normalized();
//  performance_state->internal_exciter = true;// internal_exciter;
  performance_state->internal_strum = internal_strum;
  performance_state->internal_note = internal_note;
  performance_state->strum = trigger_input_.rising_edge();

Then normalization detection doesn’t seem to work for the audio input.

As I said, you have to consider that Clouds’ audio input has a different polarity, latency and possibly bandwidth compared to Rings’. Try reworking DetectAudioNormalization.

Thanks, I managed to get the trigger input working by changing some values in DetectAudioNormalization and Random::GetWord().

Now, I just need to work out how to get normalization detection working for the v/oct input.

So I’m not having any luck triggering notes with a cv patched only to the v/oct input. Is this because on the Rings circuit, the normalization probe is connected to both the trigger and v/oct inputs, whereas on the Clouds circuit, it is independent?

There is no normalization probe in the Clouds circuit.