I don’t know if this is expected for Daisy hardware in general, or maybe the patch.Init() specifically, or maybe something is wired wrong in my module, but when I try sending a constant positive value to the audio outputs on my patch.Init(), I get a negative voltage coming out of the hardware. Specifically, if I write 1 to an audio channel, I see about -9V being output (the max negative voltage it will output). And if I write -1 to the channel, then approximately +9V is output.
Although the audio inputs are AC-coupled, the audio outputs can output a constant voltage, so I have been exploring using the audio outputs for modulation signals. It’s nice that they are bipolar as opposed the dedicated unipolar CV / LED outputs.
I want to continue using the audio outs for CV but I’m wondering if I share my firmwares, is this negative voltage behavior expected and consistent? Does it make sense to be writing code like OUT_L[i] = cv_value * -1?
Here’s some firmware that demonstrates the behavior. Per the above discussion, I guess this will only work on Patch SM hardware (I do not have a Seed).
using namespace daisy;
using namespace patch_sm;
void AudioCallback(AudioHandle::InputBuffer in,
for (size_t i = 0; i < size; i++)
OUT_L[i] = 1; // outputs approximately -9V on patch.Init() (Daisy Patch Submodule) hardware
OUT_R[i] = -1; // outputs approximately +9V
With gen~ and Oopsy, you can simply connect a [float 1] or [float -1] operator to the [out 1] and [out 2]. It behaves the same.
The Patch SM audio outputs have a nice wide range of almost -9V to 9V, and since it apparently is DC-coupled, this can be quite useful for things like envelope generators. But I have to output all negative values to get a proper envelope signal. That’s fine, but since it seems backwards, it makes me concerned about how “future proof” my code is.
It sounds like @tele_player is confirming this inverted output behavior. It’s consistent on my hardware at least.
But my main question remains: Can I assume patch.Init() / Patch SM modules will all behave and continue to behave this way?
Worst case I guess it could be a firmware build option or configurable via SD card if the behavior changes in a future iteration of the hardware. I’d still like to know what to expect.
That’s cool to know! I should try that out with my patch.Init(). Always neat to add some CV outs without any hardware modifications
There was a conversation about the PWM being inverted in that oopsy prerelease thread, so I’ll add a link to this post on that thread. If you want to, you’re more than welcome to open a new issue on the oopsy GitHub about this. Thank you!
If you want to, you’re more than welcome to open a new issue on the oopsy GitHub about this.
I’m hesitant to treat this as a bug in Oopsy because it happens in raw C++ code too.
If we’re going to look at this behavior as an issue, I think the problem is in libDaisy. I believe fixing it there will automatically fix it in Oopsy, since Oopsy just generates C++ code that uses libDaisy, right?