There seems to be something i don’t get with Supernova. This works:
Server.scsynth;
s.boot;
play{SoundIn.ar(4)};
But this is silent:
Server.supernova;
s.boot;
play{SoundIn.ar(4)};
Running s.meter
also confirms the silence.
Why?
There seems to be something i don’t get with Supernova. This works:
Server.scsynth;
s.boot;
play{SoundIn.ar(4)};
But this is silent:
Server.supernova;
s.boot;
play{SoundIn.ar(4)};
Running s.meter
also confirms the silence.
Why?
What platform are you running on?
OS X 10.12.6 (plus 20 characters…)
It works if i lower the numInputBusChannels to 16 (thanks to Marcin on the mailing list who pointed me in that direction). Solves the problem for now. But this requires further investigation i think.
For the record this is now filed as an issue
This bug seems to be back again. I had 64 i/o set in my startup file and couldn’t get audio in on my RME UCX running supernova. Not sure when this happened exactly but i’m on SC 3.11.1 on Mac OSX 10.14.6 right now. The related issues on GitHub are closed. What is the drill here? Should i ask for them to be reopened or file a new one?
I think Mac OS might have locked microphone access down again.
I’d shut down all parts of SC, then go to system settings and privacy - in there should be settings for microphone access. Remove it if it is selected … then start SC. Boot the server (and I believe you will still have silence). Kill everything again, then go back to system settings and select the permission again.
Then hopefully the sound comes back. If it doesn’t, mention it here and I’ll try to repro.
Thanks, i’ll try that. But it does work with scsynth. Are the permissions different for supernova?
I imagine so - it’s two different programs.
/*
Josh Parmenter
www.realizedsound.net/josh
*/
Actually, I don’t think it’s about permissions. What requests the permissions is the parent process started from Finder, SuperCollider (IDE/sclang) in this case, regardless of which server process is being used (I might be wrong though).
I remember supernova had some issues when the number of requested channels differed from what the hardware provided. It should all be fixed in 3.12.0-rc1, can you try that?
3.12.0-rc1 seems to do the trick! Thanks for your work on this release.