Audio inputs aren't working anymore
-
@Christoph-Hart Have you had the time to analyse this issue, please?
-
Bump bump
-
@Christoph-Hart Hmm... Nothing on this issue?
-
@ustk Have you figured out which commit caused the issue?
-
@d-healey In the first post ;)
-
@ustk did this ever get solved?
-
@DanH I'm not sure actually, as I use my own Hise branch where I reverted the commit that was causing the issue...
And for whatever reason, I can have my branch running in Xcdode with no troubles while the develop branch always fires an assertion, but this might not be related to that reverted commit... -
@ustk ah yes I remember you edited the source code to enable the inputs, is that right?
-
@DanH Exactly
-
@ustk was it a simple edit?!
-
@DanH we talked about it together here :)
https://forum.hise.audio/topic/6875/macos-microphone-access-issue -
@ustk haha! I thought I remembered something
13 files... that's a lot! If you're willing to share details let me know, no problems if not! :)
-
@ustk said in Audio inputs aren't working anymore:
@Christoph-Hart Since I've pulled the last commits to my branch I cannot have audio inputs anymore.
The culprit seems to be the - added audio & MIDI clip file drop to DAW timeline simulator commit.I still
FORCE_INPUT_CHANNELS
like before but nothing... (so it's not related to theUSE_BACKEND
flag that comes with that commit, which anyway is 1 obviously)So is it possible for the two friends to coexist? (audio IN and Timeline Simulator)
Would this be possible to have it fixed, please, Christoph?
-
@Christoph-Hart Found the culprit... Is it safe to do this?
void BackendProcessor::processBlock(AudioSampleBuffer& buffer, MidiBuffer& midiMessages) { #if !HISE_BACKEND_AS_FX && !FORCE_INPUT_CHANNELS // <- Added the FORCE_INPUT_CHANNELS preprocessor def buffer.clear(); #endif
If ok for you I'll push a request
-
@Christoph-Hart Hmmm... Something else happened on top of everything. Somehow, the input is directly sent to the output internally.
It's always been the case since I opened up the possibility of activating the inputs (and I think it's totally normal), but a muter in a container always solved this to keep the separation.
Now even with a muter, the input is still leaking into the output and completely ruins my project. I wonder if this can be related to the recent channel fix/improvement you've made. Any idea how to solve this or at least where to look?
-
@Christoph-Hart Seems that I found the culprit, but please I need your light to see if it's safe.
I re-enabled the following lines that were removed by the commit https://github.com/christophhart/HISE/commit/799694e1f330fd82aa827a36b756ffa4e14d4d7d,
but this time with an inverted preproc like in the screenshot (it was!FORCE_INPUT_CHANNELS
)Without this fix and with the FORCE_INPUT_CHANNELS flag enabled, audio input is summed twice because I do this too to get the inputs working:
(this explains why a muter just removed one part of the signal while the rest was still going through)void BackendProcessor::processBlock(AudioSampleBuffer& buffer, MidiBuffer& midiMessages) { #if !HISE_BACKEND_AS_FX && !FORCE_INPUT_CHANNELS // added !FORCE_INPUT_CHANNELS to keep inputs buffer.clear(); #endif
Will this cause big problems?
-
@ustk yes this will mute any sound created in child containers which is why I pushed that commit.
-
@Christoph-Hart Effectively, so I need to find a way to make this work like before without rolling back your entire update...
Do you consider implementing audio inputs in an official release? It would be much easier than correcting what changed each time you fix something related to channels or buffer processing, knowing that I am not the only one who needs audio inputs... -