Syrinscape in Bitfocus Companion

[jaywilliams916]

Just wanted to share a fun little project I’ve been working on.

I use Foundry VTT with the Syrinscape Controller module, but I found the built-in controls a bit limiting, and the search didn’t work particularly well for how I like to run my soundscapes.

I already use Companion (Stream Deck automation software) on an iPad to control a lot of things in Foundry, like scene switching, showing and hiding characters and tiles, and other GM controls. I wanted to be able to control Syrinscape from the same interface so I wouldn’t have to keep another window open during a session.

So I started building it.

Using the Syrinscape API (huge thanks to the team for providing this!), Companion sends requests whenever I press a button. The audio itself still plays through the Syrinscape Foundry module, so everything continues to route into Foundry the same way as normal.

Each button press also triggers a request to pull the current Syrinscape state. If the state response says the ID for that element or mood is playing, the Companion button switches to an active state. If the state response says that ID is already playing, pressing the button again will send the stop command instead.

It’s been working really well so far and makes running soundscapes during a session much smoother.

Warning: Harpy scream jump scare in audio.

[Steve]

Oh that sounds fantastic! thanks for sharing

[ryan.cassar]

Very nice! This is exactly the kind of thing we like to see people using the API for, making their own interfaces that work well for them and promotes the use of sound in their games, and I’m glad to hear you have seen some success in this direction, great work!

I’m not familiar with how the Companion software works, or what your plans are with this, but do you think this is something you could at some point release the module for others to use too?

If there are any questions you have about how things work, or parts of the API you feel are missing/broken, be sure to let us know (not making any promises regarding what we will do in response, but you never know until you ask ).

Again, I’m not familiar with the capabilities of Companion, or what you can do as a module developer, but I have a thought based on what you have said here. It sounds to me like you are making a request to the /online/frontend-api/state/ endpoint after every request you make to trigger the action of the buttons.

This is fine, and a reasonable thing to do to update all of your button states to show what is playing, and so the buttons know what they should do when clicked, especially after a Mood start when you may not know which Elements were started or stopped. It does however mean you are not being updated live as the session state changes, at least in the situation where something else might be making changes (such as you in the Master Interface or inside Foundry).

You could add a separate button that just made the state request and updated the button states when you knew this has happened, but if you could somehow embed the JavaScript player integration into your extension, you might be able to listen to the JS events it provides on state change so your buttons can react to any changes made by any integration. You should be able to ignore a lot of the implementation details the docs outing regarding setting up a UI and visualisations, and just focus on the Init, Configure and Events sections.

If there is enough demand for this sort of limited “Events only” Player sort of integration, we could potentially expose a stripped down version of the Web Socket protocol that only passes session events, without the extra details the Web Player needs to actually play the content.

Feel free to let me know how you get on, and thanks again for sharing your experiences! Looking forward to hearing more, and stay awesome