Not an issue, just a thank you!

[daenney]

I spent a day toying with the API you expose to automate some behaviour on my system on mixer state changes. It was really easy to get this going thanks to the wiki page on the API. It's silly, but it's incredibly satisfying.

So I just wanted to say thank you, but I couldn't find anywhere to do it aside from the issue tracker.

[FrostyCoolSlug]

Hi There!

It's always great to see people playing around with the API, looks like you've got a pretty creative use for it!

It was definitely interesting to see the IPC mechanism implemented, I know a lot of people simply have the Web Socket address configurable, but this comment caught my attention.. Definitely not desired behaviour!

So I've added a fix for that, the IPC will now correctly throw back the cause of the parsing error, and I've also updated the wiki to remove references to the long deprecated GetHttpState command (I have a feeling these two things are related). This should all go out with the next release.

Thanks!

[daenney]

updated the wiki to remove references to the long deprecated GetHttpState command (I have a feeling these two things are related).

They are, it's how I discovered that issue :smile:. Having the timeout around the read operation is useful either way, so in the end that worked out.

[daenney]

It was definitely interesting to see the IPC mechanism implemented, I know a lot of people simply have the Web Socket address configurable

Ah yeah, I can see that. Honestly I probably would have turned it into a configuration option if the wiki hadn't pointed at getting that through the socket. It's nice that you can do it that way though, since it allows the system to fully figure itself out. I definitely appreciate the feature.

One thing I was wondering about that, is there a way to configure the socket location? I don't mind /tmp, but since it's part of my user session I typically stash those in XDG_RUNTIME_DIR instead.

[FrostyCoolSlug]

One thing I was wondering about that, is there a way to configure the socket location? I don't mind /tmp, but since it's part of my user session I typically stash those in XDG_RUNTIME_DIR instead.

It's not possible to change this, it's hard coded in many places and was a very conscious decision.

Firstly, was the desire to avoid applications that use it needing any amount of 'boiler plate', for example the Utility UI Wrapper, which is used by many people on various platforms would suddenly need a new command line argument, as it needs to locate the Utility's IPC socket to be able to start, the same would apply to your app, as well as various other apps which exist, hell, even the goxlr-client binary would need it, so being able to move it creates a hard requirement on some level of boiler plate in all languages to be able to support, and also a requirement for the user to remember to use that parameter, and remember where the socket is.

Secondly, If we looked at automatic detection, we kinda run into a similar problem, anything wanting to use the Utility would have to dig around the system to try and find the runtime location, XDG doesn't exist in some window managers, nor does it exist on MacOS, so all apps would have to go through the same steps as the daemon does when it's creating the socket in order to locate where the socket may be (again, another chunk of boiler plate spanning many languages and implementations), you can also run the risk of something running in a way that XDG may not be present, despite the socket being in an XDG location, so it can never be found..

And finally, while yes, the daemon runs as part of your user session, it is not per-user. If two goxlr-daemon processes spawned up, they would both conflict and fight with each other, rendering the GoXLR mostly useless. Messages are sent to the device in a sequential fashion via libUSB, having two processes sending together would result in sequence breaking and constant attempts to reset and reload to fix. So during startup, regardless of the user starting it, it will probe /tmp/goxlr.socket to see if there's a utility already running on the other side, and will abort its launch if it finds one. Having the socket in a user specific location would make it impossible for this test to be performed across accounts.

/tmp ends up being a simple and reliable location for the socket that allows applications (and the utility itself) to automatically figure things out, without the need for large amounts of extra code or consideration.. So it'll likely be stuck there :)

[daenney]

That makes a lot of sense. Thanks for the explanation.

[FrostyCoolSlug]

No problem I'm gonna close this one now :)