Trying to understand adstatus behaviour
Take a look at the following super simple batch
Its just an adstatus 0 connected to a umenu - nothing to it. Just adding it here in case it helps. Reports my inputs / what hardware is in use for inputs.
I've been attempting to build a patch that re-connects to particular inputs / outputs whenever possible (using a 5 sec heartbeat rather than real time) - but thats another story. Made some interesting discoveries, and also managed to crash max a lot :). Thats just me discovering though.
However, tonight when finishing up another idea, I noticed some slightly unexpected behaviour. For giggles, (and just following my nose) I printed the output of adstatus to the console - and saw something super interesting. To me at least. Its likely well known to many knowledgable folk here.
Whenever I went into the Audio Status menu (options) - and changed the audio driver to none, adstatus sent a clear, and just a single clear message - as expected.
However, when I changed back to "core audio" it would send out a bunch of messages with strange (to me) behaviour. Its like it repeated itself entirely - but also, the "set 2" messages (to get the current list of inputs) seemed repeated for no reason at all.
Output changing from "none" to "core audio"
adstatus-output: clear
adstatus-output: append None
adstatus-output: append "Phone Microphone"
adstatus-output: append "MacBook Pro Microphone"
adstatus-output: append "Microsoft Teams Audio"
adstatus-output: append "Loopback Audio"
adstatus-output: set 2
adstatus-output: set 2
adstatus-output: set 2
adstatus-output: set 2
adstatus-output: clear
adstatus-output: append None
adstatus-output: append "Phone Microphone"
adstatus-output: append "MacBook Pro Microphone"
adstatus-output: append "Microsoft Teams Audio"
adstatus-output: append "Loopback Audio"
adstatus-output: set 2
adstatus-output: set 2
Note getting everything twice - and many "set 2"'s in a row (not exactly doubled completely)
I'm kinda at sea as to why its happening. Is it because the Audio Status menu is actually itself just using adstatus? But then why the odd "set 2" behaviours?
Has anyone got any ideas on what is occuring here? It actually completely explains some other behaviours I saw when trying to implement my reconnect function in entirely different ways - likely even leading me to abandoning the direction and trying something else new.
Adding some more strangeness this morning.
I cannot replicate the behaviour. The messages I'm getting back - having just slept my mac over night - are now pretty much as expected, aside from 3 x "set" messages when selecting a new output.
So selecting "none" as output (I've added a couple extra watch points off the umenu just to be sure - but thats all normal)
midmenuout: None
umenu-out: 0
adstatus-output: clear
adstatus-output: append None
adstatus-output: append "Phone Microphone"
adstatus-output: append "MacBook Pro Microphone"
adstatus-output: append "Microsoft Teams Audio"
adstatus-output: append "Loopback Audio"
adstatus-output: set 0
adstatus-output: set 0
adstatus-output: set 0
And setting to Mac Mic is similar.
I've tried this with and without the audiosettings menu visible, so I don't think thats it.
I'm super confused now for sure.
You should maybe rather spend time getting switching of your in/out or whatever it is,
instead of loosing time trying to understand how menus used by adstatus get controlled.
check for example what gets sent to option 0 menu when driver gets changed.
set driver to none, you'll get this:
clear max window, then set driver to something else
I guess it has to do with all adstatus members that are affected when something in audio settings
get changed, and a need to make sure all menus get updated correctly,
because max stores/recalls all of that for each driver and In/Out option
you don't need adstatus or any menus to configure audio setup,
all can be done using messages to dsp and adsatus.
Thank you! So often its about looking in the right places. Have been reading as much as I can with interest. I'm onto my fourth attempt for achieving what I'm after. I've now had more good reading - appreciated.
Like many here, I have a need to automate some of the audio settings for my patch.
I have been able to achieve a bunch, but I keep tying myself in knots. I'm sure I'll get there.
Essentially, I poll the last known state of the different dsp prefs. I do this by making sure adstatus outputs to a umenu, and that umenu state is sent to a message box. It doesn't work nearly as well as I'd like - updating the settings when there's a problem with them just doesn't always work.
I am now trying updating by sending messages using ;dsp - I just wish there was a way of polling the current status without having to deal with adstatus. I originally went down this path, but it was before I had a better grasp of adstatus and getting the info I need from it.
(I am on mac - and the patch needs to run on different macs with different interfaces and be self healing. The biggest issue is when the interface is turned off but the patch hasn't reset. But occasionally, the patch doesn't connect to the correct input/output device on load, and I have no idea why. Thus this whole little exploratory work.
In all of this though, I have managed to uncover exactly which interface is connected, as well as which computer I'm on all via terminal commands - super useful. I thought that part would be the hardest, but turned out I was super wrong....)
Further issues I had tonight.
I've been using info from one of the posts linked earlier - and it seems to be a good way of setting things up for mac.
dsp setdriver "Core Audio";
dsp prefsr 44100;
dsp prefiovs 128;
dsp prefsigvs 64;
dsp takeover 0;
dsp cpulimit 0;
dsp optimize 1;
#AD inputdevicepref "Microphone (Pink Front)";
#AD outputdevicepref "Headphones (Green Front)";
dsp start
However, there's some super strange behaviour - again, it mirrors some of the other issues I've been having with developing this.
The biggest is that if the audio driver is at any point set to none or non-realtime, then reconnecting with the dsp messages does NOT change the input and output devices in the audio prefs menu. The input and outputs remain greyed out - even though the audio driver successfully connects to core-audio. Its only after MANUALLY selecting core-audio again that the input and output devices show up. Its so strange - and I cannot find anything written about this anywhere.
I've tried delaying the input and output device messages (doing them separately) and nothing works when the above occurs. However, everything works fine in other circumstances.
Max writes preferences for each audio interface it used.
and at the end writes last used audio interface in audioprefs.txt .
which it tries to connect to on next start.
if it does not find it,
then it picks next known and available audio driver, or sets to none.
max writes preferences on quit.
so your game is a bit difficult.
one can of course insist on specific audio driver,
throw error if it is not found etc etc,
but that is only possible once you know all about that device/driver
and which state you want to enforce
here some ideas
Appreciate all this indeed.
And those ideas are all things I've been trying in various forms.
The issue is the unpredictable behaviours when using them vs the audio settings in max itself.
I'll try make a short gif showing whats going on. I have a fairly robust patch which is doing 90% of what I need it to right now - but unfortunately there's still some edge cases it doesn't cover.
I could also be not completely understanding what is going on inside the max audio status page itself.
Ie - here are the correct settings after the patch has set them.
Then if the audio driver is manually changed to "none", the app detects this change, and sets things back. However, inside the audio status page, the input and output device are greyed out.
If I manually just select the "core audio" driver again, everything returns to normal. But no messages to adstatus or dsp manages to right the situation.
This seems to happen no matter the way I set the audio-driver to "Core Audio" in the first place.
Its certainly got me stumped.
This is however quite the edge case. The biggest issue is the interface being accidentally turned off and on again. My patch detects this, detects if any settings at all have been changed, and brings it all back and turns things back on relatively gracefully. It even survives changing to a different (known) interface.
I'm probably worrying about a case that will never occur - but that doesn't stop me from wanting to figure out exactly what is happening.
I don't use Max 9, maybe something is different there from Max 8.
Appreciate your input on all of this. I will def try in 8. I really have zero need for using 9 other than generally keeping things fairly updated.
If anyone else has some ideas about what might be going on. It may even potentially be a bug (but I'm not about to call it that yet - confirmation by others of similar behaviour would be needed first! Its also taken way longer than you'd think to end up figuring out the behaviour specifics - I was perhaps extremely hap-hazard in the way I was testing things.
If I get the time in the next little bit I'll post a larger patch here that can be tested properly. Its integrated within a larger framework that I'll have to take it out from / make sure everything is in one place. I think it will help a lot.