I’m sorry @benjamin, but can you explain to me exactly how “Syrinscape Online works well with FG” - because as far as I am aware, it does not work with the DOE:Sound, which is how the majority of people who use FG and Syrinscape (in an automated way) use the two products - FG=>DOE:Sound=>Syrinscape Desktop (not Syrinscape Online).
I thiiiiiink we can look up above on this thread @Dulux_Oz at the comments by @ben?
No?
We just need to impliment a way of catching the calls rather than opening a browser every time AND change over to the new links.
I thought we had this discussion already?!? 
Yes, we had - but the Thread is on the DOE:Sound Extension, and the question from @mike1 yesterday was if I had gotten the DOE:Sound working with FGU and with Syrinscape Online - the answer to which, in short, was no, and I added I had doubts because of the issues getting Syrinscape Online working with FG because of the differences oin how Syrinscape Online works compared to how Syrinscape Desktop works.
I also said we’ll have to wait and see.
Your comment - “Syrinscape Online works well with FG” - is, as I pointed out, (to the best of my knowledge) not correct: Syrinscape Online does not work well with FG (and the DOE:Sound) - it doesn’t work at all - this is (as unpalatable as it is for me and, I’m sure, you) an objective fact - unless something has changed in the last couple of months that I’m not aware of - and if something has changed then I’ll be happy to confirm it does now work and promote it heavily both here and on the FG Forums.
Not, if you have proof that Syrinscape works with FG Unity (know as FGU) because you’ve been able to test it out with the Alpha release of FGU, than that’s absolutely fantastic - and I’ll confirm as such as soon as I can get my hands on a copy of FGU myself, but even if that is th case, accidetly misleading your customers in saying that “Syrinscape Online works well with FG” in a DOE:Sound thread is something I have to correct and/or clarify.
I’m neither an expert on DOE:Sound nor Syrinscape, but I firmly believe that we’re using both and it works for us…
… but we’re also using the small tool I described above to work around the ‘open a browser’ limitation.
So, while it does seem to work for us (potentially we’re not using the full feature set of either DOE:Sound nor Syrinscape, I wouldn’t know) it only works because we fixed it locally. Syrinscape should make this possible out of the box though?
1 Like
You had to change all the links you actually want to use, correct? @ben
i reckon it’d be great to make the TOKEN interchangeable or settable somehow, so that they don’t have to be a part of the copied in link (since the token is unique to the person running the game).
A little bit of work to do on both sides, but do-able.
I suppose we should all wait for FGU to come out and then work with that OR even better work directly with Smite Works to integrate properly straight out of the box (talking has been happening).
I am chiming in here to confirm that the “proxy” app created by @ben is pretty much exactly what we built and install alongside the genre players. Our version handles requests for the OS to open syrinscape-player://... URLs by sending an http://localhost:<PORT>/... request to a local web server running in the genre player app.
And this proxy app is pretty much exactly what is needed (thanks @ben!) to work around FG / DOE:Sound limitations (it sounds like it can only request the OS to open a URL, it cannot send an HTTP request itself) to work with Syrinscape Online.
The Syrinscape Online (beta) API is accessible over HTTP to any person or app with an internet connection, and works in a way that is typical for online APIs. Clients send an HTTP request to trigger an action and get an HTTP response indicating success.
The use of this proxy app is not at all required for the normal operation of Syrinscape Online, or even for a typical 3rd party integration. Even players using integrations (like FG / DOE:Sound) that do require it, might not run the Online Player on the same machine as the integration.
And so, I do not believe that the proxy app should be installed or run with the Online Player. I think the right place to supply (via download link) and document the use of the proxy app is alongside any 3rd party integrations that need it.
But we can build and code sign such an app, and @Dulux_Oz can direct link to it from our servers, if it helps.
I thought @Dulux_Oz was also in agreement on this point, having previously indicated to us that the proxy app seemed like a workable solution, and that he could put it alongside DOE:Sound and update the instructions for those who want to use it.
If that is no longer the case, we can make a sticky post here or an FAQ on syrinscape.com about how to use the proxy app to fix the DOE:Sound integration with Syrinscape Online.
It would be great to also make a small change to the DOE:Sound extension to work with the proxy app and the remote control links provided by the master interface as-is, so users do not need to manually transform the https://syrinscape.com/... URLs into syrinscape-online://... URLs. It could leave syrinscape-player://... URLs untouched and so it would work with the genre players and the Online Player.
This is not exactly true, even if all users are on Windows. @benjamin has already described a few points of difference. I will point out the main ones I see:
- Only the GM needs to have access to the soundset content.
- Players do not need to pre-install all the soundset content the GM might want to use.
- Better sync. The genre players almost always apply some randomisation to the element parameters (e.g. sample playlist, sample position and movement in 3D space, delay between samples, etc.) Individually controlled genre players will each generate their own settings for these in response to every
playcommand. Syrinscape Online ensures that all players generate the same settings. For example, with individually controlled genre players, players may get a different music playlist, or a timely dragon roar or other effect that only one player hears, etc. - The GM can adjust global and individual element volume for all players. (Players can still set their global volume locally.)
- The GM can use the master interface to search for and jump into any soundset and play any element, without having previously added their remote control links into FG.
- Works on macOS.
So even if it does require installing one more app, some users may prefer to do that.
I am not sure I understand this comment. You do need to install the Online Player. You do not need to install soundsets. And you do not have to install it on the machine running FG / DOE:Sound or the Syrinscape Online master interface.
Yes, you might need to install one extra app if you have nothing already installed, but if you want to install Fantasy and Sci-Fi genre players, or have already installed the Online Player (somewhere), that is also no longer true.
And if it is only the GM who needs to trigger Syrinscape via FG / DOE:Sound, only the GM needs to install the proxy app.
Yes (edit: If I remember correctly our GM was able to do this with a simple search and replace in some XML file even? As in, I think this was a quick thing and not a one by one manual process)
That is what I do. The application has a configuration file containing the token. FG/DOE:Sound are configured to use something like “syrinscape:foo/bar” which will be turned into a request to (not the actual thing of course, just the idea) https://api.syrinscape.com/foo/bar?TOKEN=secretTokenHere"
O.M.G. This is sweet! Well done! 
Exactly. It does an ‘open’ (as you can simulate, say, by running the ‘start’ command in a terminal) and therefor has no control about what exactly handles the URL (typically of course: the default browser, opening a window for that link).
While I completely understand the reasoning behind this and agree to a point: Why … not bundling it anyway? You’re distributing an installer, so the user already needs elevated privileges/admin rights (one argument against the registry changes required I could understand). It’s virtually impossible to clash with another protocol handler for something like ‘syrinscape-online’. The binary itself - however you build it - is absolutely tiny and dumb/simple. So it would add a few kb and a registry entry that non DOE:Sound users might not need, but … why not? It would even be internally consistent with the desktop app.
In the end, users probably don’t care if DOE:Sound or Syrinscape “fix it”. But I’d argue you already have exactly the right thing anyway and reach more users by exposing the API in this fashion. It would be sad if the official solution takes forever because two parties each would prefer the other side to handle it.
I have to vote with Ben here. I don’t see a reason not to bundle it (if it was large or might cause conflicts my opinion would change). By bundling it, you are adding an additional supported API which makes it possible for additional third party integrations to easily work.