Skip to content

v0.7.0

Choose a tag to compare

@github-actions github-actions released this 25 Jan 16:33
· 171 commits to main since this release
493e36a

A major resampling bug discovered in 0.6.0 was fixed, apologies to everyone who encountered it. 0.6.0 was pulled for this.

A new lighting engine has been added that mimics grandMA style lighting consoles. There are multiple layers and multiple effects. It exists entirely differently from the MIDI to DMX conversion that was written before, but it lives along side the previous functionality. In general, I found the MIDI to DMX engine to be too cumbersome so I'm hoping this new engine is easier to deal with. It has its own DSL as well. Feedback on all of this would be appreciated.

The play-direct command was removed, as I think it's outlived its purpose, which was largely for testing.

OSC commands now broadcast back to any connecting clients. Right now these clients are never forgotten, so it's possible to DDoS mtrack, so be responsible with your network security!

Release notes for 0.6.0:

Note: You can now explicitly specify the sample rate, sample format, and bits per sample for your audio device. This may be a breaking change depending on the audio files you have been using. Please test before playing live!

Transcoding has been added to mtrack. This allows audio files and audio devices to have mismatched sample rates and formats, making it easier to deal with files from multiple sources. This also adds the ability to configure the target output format for an audio device.

A new way of reading files has been added: SampleSources, which will hopefully allow us to build different types of input sources in the future. This will make it easier to introduce other input file types like FLAC, Ogg, MP3, etc. Along with this was a good bit of performance tuning. The transcoding introduces increased performance requirements, but this was reduced as much as possible.

Finally, audio is now played in a constant stream as opposed to opening up a new stream per file. Combined with the transcoding work, this should make CPU usage very consistent. In my testing, it seems that the biggest performance hit is from libasound's speex_resampler_process. The rubato method is extremely efficient, so I recommend targeting your audio device's native sample rate/format.