Make autostart of VM configurable about voicemeeter-api-python

[onyx-and-iris]

Yes, this exact question was asked on the forum. Vincent said he would look into it.

[onyx-and-iris]

Hi, thanks for raising the issues.

Regarding question 1.
The reason {Remote}.run_voicemeeter() is called immediately after a login (if login returns 1) is because if it isn't, any further api calls will return error code -2: no server., which in turn will raise a CAPIError. This also launches the GUI which I assume is the issue here. I understand if launching Voicemeeter with the commandline it's possible to use the -h flag to hide the GUI as noted in the documentation page 91, however, this doesn't seem to be an option with VBVMR_RunVoicemeeter. This is probably worth asking Vincent about, perhaps the API call can be extended to allow running Voicemeeter without showing the GUI.

In any case, I can think of a few options.

• If it's that you don't want the GUI showing you could run vm.command.hide() immediately after logging in, this will show the GUI for a split moment and then hide it.
• Launch Voicemeeter independently with a custom function, something like this
• Add such a function to this interface... although first I would probably ask Vincent kindly if he would modify the VBVMR_RunVoicemeeter function.

Regarding question 2.
So I double checked now and you are indeed correct, there is a bug! In {Remote}.run_voicemeeter() it should read if kind_id == "potato" and bits == 64:.

However, I do still think there is worth to letting people choose a 32,64 bit version, since I've read that some ASIO drivers seem to work better with either a 32 or 64 bit VM. I should note that this is only relevant for Potato kind.

I will investigate this soon.

[Kariton]

Wow, what a detailed, well explained feedback. :)

well - if the started VM version is 64bit im already happy.
i could change my setup and be done.

regarding the automatic startup in "headless mode":
maybe it is possible to raise a more appropriate error instead of "just starting stuff".

untested thought: banana is running and potato is triggered in the script.
potato would not start and the script would retry forever (?)

[Kariton]

well...
startet banana and triggered my script:

INFO:voicemeeterlib.remote.RemotePotato:RemotePotato: Successfully logged into Voicemeeter Potato version 2.1.0.8
INFO:voicemeeterlib.event.Event:now listening for pdirty, mdirty events
INFO:voicemeeterlib.subject.Subject:MacroFeedback added to event observers

Potato version 2.1.0.8
🤣

[Kariton]

a0d6574 fixed the problem with 64bit / 32bit for me.

[Kariton]

hmm, while VM starts correctly it does not start the MacroButtons despite the fact i have configured it to do so.
(minor issue - now the macros are itself in the autostart)

[onyx-and-iris]

I've given this some thought and I will actually close this issue for now.

As discussed earlier, regarding point 1, actually Voicemeeter needs to be started before api calls can be made, the issue is around the GUI being shown. I've left a message for Vincent asking if anything can be done in the api. Otherwise, I think the best option is to just knock up a custom function for launching Voicemeeter but I would suggest that task is better delegated to the consumer, rather than being integrated into the interface. Point 2 has been resolved, thanks for noticing the bug.

About giving the option to choose 32,64 bit versions, this would mostly be for those people who have problems with their ASIO drivers but a) I don't know how widespread this issue is b) a big update is just around the corner and the Voicemeeter devs claim to have fixed most of the driver related issues people were having.

So I'll postpone this change for now, perhaps if the issue gets raised again I may investigate it then.