sensorium / Mozzi

sound synthesis library for Arduino
https://sensorium.github.io/Mozzi/
GNU Lesser General Public License v2.1
1.05k stars 184 forks source link

RFC: Analog input scaling - what's the best approach #232

Closed tfry-git closed 1 month ago

tfry-git commented 5 months ago

Since some years, updateAudio() can be platform independent in so far as scaling to the required audio resolution can be done, automatically.

Where we still have differences is analog (audio or non-audio) input. mozziAnalogRead(), and getAudioInput() return values in a platform specific range. It should be possible to address this quite easily, by adding another configuration define like:

#define MOZZI_ANALOG_READ_RESOLUTION 12

All ports will then either have to make sure they perform reads at that resolution, or they can set some internal define telling what resolution analog reads actually have, internally. Then mozziAnalogRead() and getAudioInput() can trivially return values that have been shifted, accordingly.

So far so good. What I'd like to pick your brains about: What should be the default behavior, when users do not set MOZZI_ANALOG_READ_RESOLUTION? Essentially, I think the options are:

Thoughts?

tomcombriat commented 5 months ago

I thought about that some time ago, and my ideas converged on the opposite approach: I came to the idea that every port should also give, as an accessible parameter say NATIVE_ANALOG_READ_RESOLUTION, their native ADC resolution.

With that, sketches can be made platform independent for instance by doing:

uint8_t midi_note = MOZZI_SHIFTR(mozziAnalogRead(pin), NATIVE_ANALOG_READ_RESOLUTION - 8); // returns a 8bits value, whatever the input range

(reusing the MOZZI_SHIFTR from FixMath ;).

I did not thought it completely through, but that might also be an approach to consider.


Edit: could also be made prettier by wrapping it up, like

uint8_t midi_note = MOZZI_AUTO_ADC(mozziAnalogRead(pin), 8); // returns to 8bits resolution using MOZZI_SHIFTR internally
tomcombriat commented 5 months ago

Otherwise, I would be in favor of returning to 16 bits resolution: 10 bits do require a 16 bits container anyway, better not to be blocked in the future and provide the best resolution, by default, for platforms that can provide it.

Also, we are breaking a lot of things for Mozzi2.0 already…

tfry-git commented 5 months ago

Also, we are breaking a lot of things for Mozzi2.0 already…

I'm still sort of optimistic, that most sketches will continue to work, even if perhaps with warnings.

Anyway, building on your feedback, my next suggestion would be:

If no desired analog resolution is configured, mozziAnalogRead() continues to return the platform specific resolution, but with a warning. If something is configured, use that, without a warning.

In addition, create a new function mozziAnalogRead16(), which always returns the result shifted to 16 bits. (Possibly also mozziAnalogRead<byte resolution>(), but that may be overkill).

(Rationale: We're only dealing with two functions, here, mozziAnalogRead() and getAudioInput(), so integrating the wrapper into the function will me more comfortable, without adding much API bloat.)