Wanted to share a technique I have been using to manage Engine COMPs easily. There’s not a lot of examples of creative ways to use the Engine COMP. Hopefully you find this as handy as I do.
One of the biggest drawbacks for the Engine COMP is that you can’t edit its contents without opening a second TD instance, saving an updated .tox, and re-initializing. While this technique doesn’t solve the second two problems, it does allow you edit and test within a single instance of TD. Examples are attached below. In the example, I am using the Engine COMP to normalize midi values. A real world example would be to handle MIDI to OSC outputs without slowing down the main application.
How this works:
- The “handler” Base COMP acts as the source. Edits can be made here and saved to a .tox.
- The “engine” is the Engine COMP with the “handler” .tox as a source.
- A toggle button acts as Engine COMP On/Off (Multithreading On/Off)
- This button’s output:
** Inversely toggles each COMP’s “allowCooking” flag
** Acts as the index for the output switch
This works pretty well for me, but I have noticed some caveats:
- Make sure the “handler” Base COMP is active when you save the .tox, otherwise there will not be output from the Engine COMP
- Make sure the switching network is configured prior to initializing the Engine COMP. I have seen some weirdness with having the .tox loaded and the source Base COMP active at the same time, including a hard freeze on TD. I think this was related to the first caveat, but additional testing is required.
This can be extrapolated throughout your projects. I have several places where I use an Engine COMP and this allows for a global “Engine On/Off” control. In other words, this becomes a master “Multithreading On/Off” switch in my project.