Update 2023-07-22-liquidsoap-2.2.0.md

_posts/2023-07-22-liquidsoap-2.2.0.md

@@ -3,63 +3,49 @@ layout: post
 title: Liquidsoap 2.2.0 is out! 🎉
 ---
 
-We are delighted to announce the release of **Liquidsoap 2.2.0**! It is now available on [our release page](https://github.com/savonet/liquidsoap/releases/tag/v2.2.0)
-and should be available [via opam](https://opam.ocaml.org/packages/liquidsoap) shortly!
+We are delighted to announce the release of **Liquidsoap 2.2.0**! It is now available on [our release page](https://github.com/savonet/liquidsoap/releases/tag/v2.2.0) and should be available [via opam](https://opam.ocaml.org/packages/liquidsoap) shortly!
 
-This release comes almost 4 months after the last stable release from the `2.1.x` release cycle and 14 months (!) after forking
-the `2.2.x` release branch! It includes some exciting changes in track muxing/demuxing, HLS, sound processing and more. 
-See below for a detailed list!
+This release comes almost 4 months after the last stable release frdom the `2.1.x` release cycle and 14 months (!) after forking the `2.2.x` release branch! It includes some exciting changes in track muxing/demuxing, HLS, sound processing and more. See below for a detailed list!
 
 ## ✨ New features
 
 Here are the highlights:
 
 ### 🎛️ Multitrack
 
-This is by far the biggest change in this relase! This brings the ability to demux and remux tracks inside sources, making it possible
-to:
+This is by far the biggest change in this relase! This brings the ability to demux and remux tracks inside sources, making it possible to:
 * Encode video with multiple audio tracks
 * Create audio-only and audio/video streams from the same content, for instance a regular audio stream and one with the studio's video.
 * Drop or specify which metadata or track marks track should be used.
 * Apply specific audio effect or encoding to different tracks
 
-And much more! The full documentation is [here](https://www.liquidsoap.info/doc-2.2.0/multitrack.html). We plan on expanding this
-support in the future in particular to allow track selection based on language, encoded content etc.
+And much more! The full documentation is [here](https://www.liquidsoap.info/doc-2.2.0/multitrack.html). We plan on expanding this support in the future in particular to allow track selection based on language, encoded content etc.
 
 ### 🏷️ HLS metadata
 
-At last! We now support metadata in HLS streams using a timed ID3 stream for `mpegts` container and plain ID3v2 tags for 
-`adts`, `mp3`, `ac3` and `eac3` formats. There is currently no support for metadata with `mp4` containers.
+At last! We now support metadata in HLS streams using a timed ID3 stream for `mpegts` container and plain ID3v2 tags for  `adts`, `mp3`, `ac3` and `eac3` formats. There is currently no support for metadata with `mp4` containers.
 
-This feature is **enabled by default** so you might want to check if it impacts your listeners before pushing it 
-to production. It can be turned off by setting `id3` to false on your HLS streams.
+This feature is **enabled by default** so you might want to check if it impacts your listeners before pushing it  to production. It can be turned off by setting `id3` to false on your HLS streams.
 
 Full documentation is [here](https://www.liquidsoap.info/doc-2.2.0/hls_output.html#metadata).
 
 ### 🎨 Colored logs
 
-Small change but not the least important! Logs are now colored by default when printed on the console. This finally makes it possible
-to read logs with high level of details!
+Small change but not the least important! Logs are now colored by default when printed on the console. This finally makes it possible to read logs with high level of details!
 
-We are aware of the need for more developer tooling and quality of life improvements! In the next release cycle, we hope to work on code
-formatting, highlighting and more!
+We are aware of the need for more developer tooling and quality of life improvements! In the next release cycle, we hope to work on code formatting, highlighting and more!
 
 ### 🕸️ New HTTP API
 
-Interacting with your scripts is essential and, for this, web interfaces and APIs are really useful. In order to make
-our HTTP server easier to use, we wrote a new web API that is very close to node express' API and should be fairly easy to
-use! The documentation is [here](https://www.liquidsoap.info/doc-dev/harbor_http.html#nodeexpress-api)
+Interacting with your scripts is essential and, for this, web interfaces and APIs are really useful. In order to make our HTTP server easier to use, we wrote a new web API that is very close to node express' API and should be fairly easy to use! The documentation is [here](https://www.liquidsoap.info/doc-2.2.0/harbor_http.html#nodeexpress-api)
 
 These changes also included a revamping of our SSL support which is now modular and with a new TLS optional support!
 
 ### 🎚️ Native stereotool support
 
-While commited to open-source through and through, we also do want to meet our users where they are. To this end, it
-seems that a lof of them want to use the proprietary stereotool audio processing. Up until this version, the only option
-was via the external command line encoder and this was not satisfactory. 
+While commited to open-source through and through, we also do want to meet our users where they are. To this end, it seems that a lof of them want to use the proprietary stereotool audio processing. Up until this version, the only option was via the external command line encoder and this was not satisfactory. 
 
-With this release, it is now possible to use the shared library distributed by the author, which provides support for 
-an new `stereotool` internal operator that is much easier to integrate. See the documentation [here](https://www.liquidsoap.info/doc-dev/stereotool.html).
+With this release, it is now possible to use the shared library distributed by the author, which provides support for  an new `stereotool` internal operator that is much easier to integrate. See the documentation [here](https://www.liquidsoap.info/doc-2.2.0/stereotool.html).
 
 ### 📟 Records enhancements
 
@@ -86,67 +72,46 @@ end
 
 ### 🪢 Support for YAML parsing/rendering
 
-Following the recent [JSON parsing](https://www.liquidsoap.info/doc-2.2.0/json.html) feature, we now support [YAML parsing](https://www.liquidsoap.info/doc-2.2.0/yaml.html)
-in a very similar was as json.
+Following the recent [JSON parsing](https://www.liquidsoap.info/doc-2.2.0/json.html) feature, we now support [YAML parsing](https://www.liquidsoap.info/doc-2.2.0/yaml.html) in a very similar was as json.
 
 ### 🔮 Memory optimization
 
-While we are aware that memory consumption with this release may have increased a bit due to on-going changes, we have done our best to introduce more
-ways to control it and understand its usage.
+While we are aware that memory consumption with this release may have increased a bit due to on-going changes, we have done our best to introduce more ways to control it and understand its usage.
 
 In particular, we now support the alternative [jemalloc]() memory allocator, enabled in all our release assets and configurable via the internal settings.
 
-We also introduced two new audio content formats, `pcm_s16` and `pcm_f32` that can be used to store audio
-internally as, resp., 16-bit signed integers or 32-bit floating point numbers. Our default internal format being OCaml's
-native 64-bit floating point numbers.
+We also introduced two new audio content formats, `pcm_s16` and `pcm_f32` that can be used to store audio internally as, resp., 16-bit signed integers or 32-bit floating point numbers. Our default internal format being OCaml's native 64-bit floating point numbers.
 
 We also added a new `track.audio.defer` operator that can be used to buffer large amount of audio data without impacting performances.
 
-You can read more about memory utilization in liquidsoap [here](https://www.liquidsoap.info/doc-dev/memory.html).
+You can read more about memory utilization in liquidsoap [here](https://www.liquidsoap.info/doc-2.2.0/memory.html).
 
 ### 🐪 Switch to `dune` and javascript runtime
 
-While perhaps more exciting to developers, the project has now fully moved to the OCaml `dune` builder. This 
-provides an extra level of flexibility, In particular, we were able to extract the code that is specific to the
-liquidsoap language, that is everything that pertains to parsing/evaluating/type checking without the streaming and
-system specific operators and export it as an [online playground](https://www.liquidsoap.info/try/). We're not sure yet
-what we'll do with it. It might be possible, for instance, to write a javascript backend to use liquidsoap scripts 
-with the [Web media APIs](https://developer.mozilla.org/en-US/docs/Web/Media)!
+While perhaps more exciting to developers, the project has now fully moved to the OCaml `dune` builder. This  provides an extra level of flexibility, In particular, we were able to extract the code that is specific to the liquidsoap language, that is everything that pertains to parsing/evaluating/type checking without the streaming and system specific operators and export it as an [online playground](https://www.liquidsoap.info/try/). We're not sure yet what we'll do with it. It might be possible, for instance, to write a javascript backend to use liquidsoap scripts  with the [Web media APIs](https://developer.mozilla.org/en-US/docs/Web/Media)!
 
 ## 🕵️ Versioning and release assets
 
-For a little over a year now, we have switched to _rolling release cycles_ with maintenance and bugfixes applying
-only to the current release cycle. Regular releases are tagged `vX.Y.Z` (for instance `v2.2.0`) on github and docker while on-going releases are tagged
-`rolling-release-vX.Y.Z`.
+For a little over a year now, we have switched to _rolling release cycles_ with maintenance and bugfixes applying only to the current release cycle. Regular releases are tagged `vX.Y.Z` (for instance `v2.2.0`) on github and docker while on-going releases are tagged `rolling-release-vX.Y.Z`.
 
-When an initial release, for instance `2.2.0`, is being worked on, bugfixes and user issues were being addressed for users using the `2.1.x`
-releases. While we would like to extend support, this is the best that we can do with our limited resources!
+When an initial release, for instance `2.2.0`, is being worked on, bugfixes and user issues were being addressed for users using the `2.1.x` releases. While we would like to extend support, this is the best that we can do with our limited resources!
 
-At any given time, the `rolling-release-vX.Y.Z` denotes the released being worked on. For stable releases branches, this would be for instance, 
-`rolling-release-v2.2.1` after release `v2.2.0`. For a yet-to-be released initial version, this would be for instance `rolling-release-v2.3.x`.
-We try our best to make those releases as bug-free as possible. Using one of them to test your production script also guarantees the fastest response
-to bugs and issues!
+At any given time, the `rolling-release-vX.Y.Z` denotes the released being worked on. For stable releases branches, this would be for instance, `rolling-release-v2.2.1` after release `v2.2.0`. For a yet-to-be released initial version, this would be for instance `rolling-release-v2.3.x`. We try our best to make those releases as bug-free as possible. Using one of them to test your production script also guarantees the fastest response to bugs and issues!
 
-For release assets, we try to maintain two packages for debian and ubuntu distributions, one with the latest LTS or stable and one with a recent
-release. The new `minimal` assets are, as the name suggests, _minimal_ builds. They contain a limited set of features and standard library operators.
-Minimal builds are intended for most production run and should limit the risk for issues such as segfault and etc. If your script can run with it,
-we recommend it over the fully featured builds. 
+For release assets, we try to maintain two packages for debian and ubuntu distributions, one with the latest LTS or stable and one with a recent release. The new `minimal` assets are, as the name suggests, _minimal_ builds. They contain a limited set of features and standard library operators. Minimal builds are intended for most production run and should limit the risk for issues such as segfault and etc. If your script can run with it, we recommend it over the fully featured builds. 
 
 For each release asset, you can consult the associated `.config` file to see which features are enabled.
 
-Docker release images are located at: `savonet/liquidsoap:v2.2.0`. The release tag may be updated if needed. You can use git sha-based images to pick
-a fixed build, e.g. `savonet/liquidsoap:<sha>`
+Docker release images are located at: `savonet/liquidsoap:v2.2.0`. The release tag may be updated if needed. You can use git sha-based images to pick a fixed build, e.g. `savonet/liquidsoap:<sha>`
 
 Lastly, we may update the list of release assets on the github release page. If you are looking for permanent release asset links make sure to checkout
 [savonet/liquidsoap-release-assets](https://github.com/savonet/liquidsoap-release-assets).
 
 ## 🧮 Migration guide
 
-We listed most of the migration issues you might run into on [this page](https://www.liquidsoap.info/doc-2.2.0/migrating.html). The detailed changelog
-below may also help.
+We listed most of the migration issues you might run into on [this page](https://www.liquidsoap.info/doc-2.2.0/migrating.html). The detailed changelog below may also help.
 
-As a reminder, we strongly recommend to test your script in a stagging environment, even between minor releases, to make sure that
-everything is working correctly before pushing a new liquidsoap version to production!
+As a reminder, we strongly recommend to test your script in a stagging environment, even between minor releases, to make sure that everything is working correctly before pushing a new liquidsoap version to production!
 
 ## 📖 Changelog