Test packages, release 0.6.1

[mgeier]

We didn't want to widely announce release 0.6.0 yet, because the packaging with brew and Deken is quite experimental and should be thoroughly tested first.

Once we have tested the packages, fixed any errors and updated the docs, we should make a new release 0.6.1, which we then should announce to a larger audience.

Here's what needs testing:

brew

With a bit of luck, the SSR can be installed with:

brew install SoundScapeRenderer/ssr/ssr

I know this is a bit repetitive, but I didn't have a good idea how to avoid this.

As mentioned in https://github.com/SoundScapeRenderer/ssr/pull/331#issuecomment-1412575341, the "bottles" are generated 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.

It is important to check whether the HTML/JavaScript files for the browser GUI are served correctly. To test this, start with ssr-binaural --websocket-server and then open http://localhost:9422 in a browser (which should show the 3D interface).

Deken

I have uploaded the package (with a bit of hackery, see https://github.com/pure-data/deken/issues/285), which should cover macOS (Intel), Windows (64bit) and Linux.

I tried it on Linux, found the package, could install it, but then I didn't know how to use it ... just creating [ssr_binaural~] didn't work. [UPDATE: I added the ssr sub-directory to the search path, now it works]

Debian package

@umlaeute It would be great if you could have a look if you have time.

I think the main difference to the previous version is that we are now shipping HTML and JavaScript files for the browser GUI. Those files are included in the tarball, but I guess Debian's policy requires to build them from source? This should be done automatically if yarn is installed. It can be requested explicitly with --enable-browser-gui.

[umlaeute]

It would be great if you could have a look if you have time.

sure. Debian is currently at the beginning of the freeze cycle for the next release, I might just be able to get it ready in time.

Those files are included in the tarball, but I guess Debian's policy requires to build them from source?

yes.

This should be done automatically if yarn is installed.

but we (Debian) do not have network access during build time. That is: we cannot use any 3rd party package manager (npm, yarn, pip...) to install additional dependencies "from the internet".

EDIT i've moved my ramblings about Debian-packaging ssr-0.6.0 to #331

[umlaeute]

after investigating the situtation, 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)

[mgeier]

I might just be able to get it ready in time.

That would be great!

That is: we cannot use any 3rd party package manager (npm, yarn, pip...) to install additional dependencies "from the internet".

OK, then it doesn't work for now, that's fine (as I said in #331).

I guess if we want to have this in a later version of the Debian package, we would have to build the browser GUI with existing Debian packages, right?

https://packages.debian.org/search?keywords=webpack https://packages.debian.org/search?keywords=libjs-three https://packages.debian.org/search?keywords=node-three-orbit-controls

It looks like the most important things are available, but I have no idea how complicated it would be to make this actually work.

But anyway, that's not necessary now and we can talk about it at a later time.

[mgeier]

I tried the Pd externals on Linux again: I added the ssr sub-directory to the search path, then I could instantiate the external with [ssr_binaural~ ...]. That's great!

I'm wondering if I really have to add the path manually? I was expecting the external to simply be found after installing it with Deken.

I also tried the Pd external on macOS Monterey (Intel): download from Deken worked, I had to add the ssr subdirectory to the path as well, then I got an error:

externals/ssr/ssr_binaural~.pd_darwin: dlopen(/Users/geier/Documents/Pd/externals/ssr/ssr_binaural~.pd_darwin, 0x000A): Library not loaded: 'libmysofa.1.dylib'
  Referenced from: '/Users/geier/Documents/Pd/externals/ssr/ssr_binaural~.pd_darwin'
  Reason: tried: 'libmysofa.1.dylib' (relative path not allowed in hardened program), '/usr/lib/libmysofa.1.dylib' (no such file)

And indeed, the .dylib file is missing!

I've created #333, maybe that helps? [UPDATE: yes!]

Finally, I also tried brew install SoundScapeRenderer/ssr/ssr, and it works perfectly! Including browser GUI. When I enabled the --websocket-server, I had to provide an admin password to allow the network access, but I guess that's fine. Other than that, I had no annoying questions whether I'm sure to run this program because it's dangerous or anything like that.

[umlaeute]

I tried the Pd externals on Linux again: I added the ssr sub-directory to the search path, then I could instantiate the external with [ssr_binaural~ ...]. That's great!

I'm wondering if I really have to add the path manually? I was expecting

With my Pd-hat on: I think your expectation is flawed.

The proper way is to add [declare -path ssr] in your patch, and after that, you can use [ssr_binaural~].

Am alternative approach would be to skip the ssr_ prefix altogether and instead go with [ssr/binaural~], but that somewhat breaks symmetry with the CLI binaries (and might get you into trouble, if you also wanted to use an unrelated [binaural~] object.

[mgeier]

The proper way is to add [declare -path ssr] in your patch, and after that, you can use [ssr_binaural~].

Thanks, I didn't know that! With that, it works!

[mgeier]

I just tried the Debian package and it works like a charm, thanks @umlaeute!

Since the browser GUI files are not included, I have created a 404 page with some hopefully helpful suggestions: #336.

[HaHeho]

I had the following thing happen already multiple times when doing general homebrew updates (this example is on an M1, but it also happened on an macOS Intel):

$ brew update && brew upgrade

[...]

==> Upgrading fmt
  9.1.0 -> 10.0.0

==> Pouring fmt--10.0.0.arm64_ventura.bottle.tar.gz
🍺  /opt/homebrew/Cellar/fmt/10.0.0: 27 files, 1.2MB
==> Running `brew cleanup fmt`...
Removing: /opt/homebrew/Cellar/fmt/9.1.0... (27 files, 1MB)
Removing: /Users/user/Library/Caches/Homebrew/fmt--9.1.0... (292.9KB)

[...]

==> No outdated dependents to upgrade!
==> Checking for dependents of upgraded formulae...
Disable this behaviour by setting HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
==> Reinstalling 1 dependent with broken linkage from source:
soundscaperenderer/ssr/ssr
==> Fetching soundscaperenderer/ssr/ssr
==> Downloading https://github.com/SoundScapeRenderer/ssr/releases/download/0.6.
Already downloaded: /Users/user/Library/Caches/Homebrew/downloads/9af04d5f5899266b5a5a410fcc9e6b2b462e09b90abfaca862874ee5b5a539f1--ssr-0.6.0.tar.gz
==> Reinstalling soundscaperenderer/ssr/ssr
==> ./configure --prefix=/opt/homebrew/Cellar/ssr/0.6.0 --libdir=/opt/homebrew/C
==> make install
🍺  /opt/homebrew/Cellar/ssr/0.6.0: 79 files, 24.6MB, built in 20 seconds

I believe this was happening because the fmt dependency of ssr was updated? I have not seen this behaviour with any other package or cask from brew. Is this intended?

[mgeier]

Is this intended?

I don't know. I was not aware of that behavior.

But maybe ... if the fmt library has made API changes in the new version I'm not really surprised that the SSR has to be re-compiled. Maybe that's how "broken linkage" could be understood?

Re-compiling is annoying, but I hope that doesn't happen too often.

We might also be able to specify an explicit version for fmt, but even if that's possible, I'm not sure if it's actually a good idea.

[mgeier]

I would like to release version 0.6.1 within the next few days.

I have just created a few new documentation PRs. Other than that, everything should be ready. The Windows stuff will have to wait until the next release, which is hopefully soon!

Is there anything else that needs to be done before the 0.6.1 release?

[mgeier]

I have just released version 0.6.1 and I'm now writing an announcement for the mailing list.

I'm closing this issue, if there are any problems, please open a new issue.

[mgeier]

I have announced the new version at the SSR mailing list and at the Linux Audio Announce and Pd Announce mailing lists.

Should we announce it anywhere else?

[umlaeute]

i don't see any announcement on "Linux Audio Announce", but might have missed it.

and hah: you forgot to mention that the you SSR-0.6.1 is already available in Debian (sid, of course). just kidding.

[mgeier]

i don't see any announcement on "Linux Audio Announce", but might have missed it.

Thanks for checking. There was a few days of delay, maybe my message had to be verified by a moderator or something. I think in the meantime it was sent out: https://lists.linuxaudio.org/hyperkitty/list/linux-audio-announce@lists.linuxaudio.org/thread/4GEYWOZ3RYTT6TBXZXHM36FIQ5CMA5NL/

and hah: you forgot to mention that the you SSR-0.6.1 is already available in Debian (sid, of course). just kidding.

Oh wow, I didn't expect you to be that fast!