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?
I could run your firmware on my patch.Init() to confirm/test so please feel free to share!
From my understanding, the audio outputs are filtered so it’s not suited for outputting CVs that are slow or static. So I’m curious as to if you found a workaround.
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).
#include "daisy_patch_sm.h"
using namespace daisy;
using namespace patch_sm;
DaisyPatchSM patch;
void AudioCallback(AudioHandle::InputBuffer in,
AudioHandle::OutputBuffer out,
size_t size)
{
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
}
}
int main(void)
{
patch.Init();
patch.SetLed(true);
patch.StartAudio(AudioCallback);
while (1)
{
}
}
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?
