Release 0.6.0

[mgeier]

Preparation for the new release.

Any last minute changes?

Anything I forgot in the NEWS?

[mgeier]

Some additional information:

We will not provide an App Bundle for macOS this time. Instead, we will provide an experimental Homebrew package (built at https://github.com/SoundScapeRenderer/homebrew-ssr).

We don't really know if that will work correctly, so the plan is to try this with the 0.6.0 release, and if it works (or after we fixed any problems), we'll update the documentation, maybe remove more App Bundle stuff and then make a new 0.6.1 release soon.

We are also planning to provide the Pd externals via Deken.

[chris-hld]

Hi, I just wanted to report that with the recent changes it was quite smooth to make the windows version compile.

https://github.com/chris-hld/ssr/tree/ssr-windows-0.6.0

The only problem I stumbled across was an implicit conversion error from fs::path to stf::string, which for some reason didn't work with g++11. Maybe it is worth considering the explicit .string() for these cases (only complained in 4 cases)?

[HaHeho]

I am excited about the Homebrew release. I will be able to test it on several systems.

However, I would say that the app bundle is generally easier to start with (for people who are not using homebrew otherwise). EDIT: I saw your reason for dropping the app bundle in another thread.

[mgeier]

@chris-hld

Cool, that's great news!

Maybe it is worth considering the explicit .string() for these cases (only complained in 4 cases)?

Sure, why not.

I'll release 0.6.0 anyway, but would you like to make a PR for 0.6.1?

@HaHeho

It would be great if you could test different systems!
Please note that the bottles (https://github.com/SoundScapeRenderer/homebrew-ssr/releases) will be created by Github Actions, which currently only supports Big Sur and Monterey, and only Intel.
My hope is that the SSR package can still be installed on other systems, but it will have to be compiled from source, which might take a long time.

And for the record (in case somebody else is curious): We dropped the App Bundle because the code signing and notarization process is just too complicated and annoying. This is also the main reason why we didn't make a release for about three years.

[mgeier]

I've made the release: https://github.com/SoundScapeRenderer/ssr/releases/tag/0.6.0

And here are the next steps: #332

[umlaeute]

i'm going to post my questions with packaging ssr-0.6.0 here (rather than in #332).

so:
i see that the documentation uses the (your) insipid sphinx theme.
since this theme is not yet packaged for Debian (and a NEW package certainly won't make it into Debian before the full freeze), i wonder whether it is possible to (temporarily) use a different theme (one that is available in Debian), without losing functionality.

[umlaeute]

after investigating the situtation of building browser-gui myself, i wonder whether i shouldn't just leave out the browser-GUI from the Debian package for now.

the release description says:

an experimental browser-based 3D GUI

as such i take it that this is an optional feature, that might become more important in the future (but we will still be able to use use an ssr that lacks the browser-gui)

(I originally posted this in #332, but am now moving it here...)

[mgeier]

i wonder whether it is possible to (temporarily) use a different theme (one that is available in Debian), without losing functionality

Yes, that's no problem. You can use html_theme = 'sphinx_rtd_theme', as we had before. Or any other theme of your choice.

The only thing is the last block of text in index.rst, with the title "How To Navigate This Site". This is specific to the insipid theme and should be removed.

leave out the browser-GUI from the Debian package for now

Yes, that's no problem. I think Debian users are capable enough to get the pre-built HTML/JS files from the tarball and just open index.html in the browser.
That's all there is to it, it's just a convenience that the SSR serves those files (there is just a little bit of magic involved to get the host and port, but as long as the default is used, everything should still work).
The important thing is that the WebSocket server is available.

we will still be able to use use an ssr that lacks the browser-gui

Yes, but the browser GUI is the only way to show 3D scenes.

This is probably not that important for this release, but in a few months I'm planning to include support for 3D scenes (#155), and at that point a 3D GUI would be very helpful.

the release description says:

an experimental browser-based 3D GUI

I'm mostly stressing this because it has many missing features, it is very bare-bones.
It does actually work, but it doesn't look too great.

I see it as a proof of concept and as a placeholder until we get something better, but this might never happen.

[umlaeute]

thanks for the feedback. this helped tremendously.

i have just uploaded the updated packages to Debian.
if you notice anything strange, please let me know.

[HaHeho]

I tested the 0.6.0 homebrew package on an Apple M1 according to the instructions in #332, but I will post my observations here.

1. The system was an untouched Apple M1, no further dev resources installed before. The installation via brew worked without any issues. Obviously tons of packages had to be installed which took a few minutes. I believe the SSR itself was built from source, which on its own was completed within seconds regardless, surprisingly. Very nice!!

2. After installation, a few macOS security warnings regarding microphone access when starting the jack server had to be accepted. This is of course expected, since also jack was installed on the system for the first time during the SSR setup. Granting the microphone access will make the first jack or ssr executions fail regardless. But this is probably also expected and a retry executes successfully.

3. I did only a very quick test running brs_example.asd but this seemed to have worked without any problem. There was only one warning given, which seems harmless and not related to the SSR.

***********************************************************************
* Message from libecasoundc:
*
* 'ECASOUND' environment variable not set. Using the default value
* value 'ECASOUND=ecasound'.
***********************************************************************

[mgeier]

Thanks @HaHeho, that's great news!

Yes, the SSR is expected to be compiled from source on M1, because the bottles (https://github.com/SoundScapeRenderer/homebrew-ssr/releases) are only available for Intel (because Github actions still doesn't support M1: actions/runner-images#2187).

But great that it works nevertheless!

The ECASOUND warning can be ignored, since the ecasound binary should be in the PATH when installed by brew. See also https://ssr.readthedocs.io/en/0.6.0/issues.html#annoying-ecasound-message

This was not shown in previous versions when using the App Bundle, because the ECASOUND variable was set to the correct path here:

ssr/data/MacOSX/run-ssr.applescript

Line 50 in 94b9172

set command to "export ECASOUND=\"" & ssrBinPath & "/ecasound\" ; cd \"" & ssrBinPath & "/../../..\" ; \"" & ssrBinPath & "/ssr\" " & rendererOption & options & " && (echo SSR quit normally with exit code $?) || (echo SSR encountered an error and had to quit. See above. Exit code: $?)"