I’m a reasonably competent (not expert, just competent) C++ developer, but I’m having a hard time finding a way in with Tracktion Engine. The examples are great as a grab bag of recipes for different functionality, but the whole blob is so tightly coupled that it is very hard for a beginner to understand what’s happening - every file seems to include or be included by a heap of others.
What I would personally like, and think many others would find useful, would be the following:
A separate repo, containing only:
The tracktion_engine repo itself (as a submodule)
A simple CMakeLists.txt
A README explaining how to build
A single “main.cpp” file with the only#include being the engine itself…
Ideally without any GUI code, i.e. headless…
That does the simplest meaningful musical task possible, for example:
Play a single note on a built-in synthesizer, send to default out
Play a single WAV file (could be embedded as binary data, fine if it’s super short & low-res), send to default out
Take the default audio input, route it to a built-in effect, send to default out
As long as it fits into a single file, ideally <100 lines, and makes an actual sound, I don’t really care what it does! Just that it provides a starting point that doesn’t pull in a million other things.
I absolutely understand that maintaining Tracktion Engine as an OSS library is extra work and secondary to your duties to Tracktion the product, and if there is nobody available to create this I would happily do it myself, I would just need a bit of guidance!
Thanks for reading, and thank you for making this incredible tool for us!
Hi @debrisapron thanks for your interest and sharing your example.
I thought our readme page gives most of the setup info you need but maybe we relied too heavily on people understanding that it’s a juce module.
Regarding most of the other comments, it’s a difficult balancing act.
There is a single CMakeLists.txt file in the root you can run and then just build and run the DemoRunner target. I’m not sure we could make that much simpler, it’s simpler than the JUCE one even as you don’t have to define anything upfront.
Then would maybe linking to the Demos dir directly be beneficial?
The PlaybackDemo is ~100 lines of code and just plays back an audio file.
The tutorials folder is supposed to provide some more in-depth explanation about what each of the demos do, and introduce some core concepts:
But I agree we could do a better job of explaining what each demo actually demonstrates.
Ultimately it’s difficult to show something compelling with enough utility for people to find useful.
We then have to balance that up between adding more functionality for commercial license holders and working on Waveform ourselves.
I’d love to see the community around TE grow and people share their own examples and knowledge etc. though so thanks for that
Hi Dave, I would say that the problem is in the dependencies each app pulls in. You can’t simply compile, for example, PlaybackDemo.h because it’s coupled with the Demo Runner and Utilities.h, through which it pulls in lots of other GUI stuff like settings dialogs, file browsers etc. Of course, this is 100% necessary for an app that actually does something meaningful! However what I wanted was an example like the classic “Hello World”, which very deliberately doesn’t do anything meaningful. The point is to show only functionality specific to TE, without any other distractions (GUI, file I/O, glue code, generic C++ resource management stuff etc etc).
To be clear, I think the Demo Runner is a very useful resource for real-world apps, I’ve been using it a lot as a source of “recipes” for my own app. But as a first introduction to TE, I think it’s quite complicated.
Anyway, thanks very much for your work on TE and I hope someone finds what I did useful!
