As discussed in #10, I created a plugin to apply positive and negative delays to audio.
I named it simply "offset" since during development, I had the thought that there is actually no reason why it should have "artificial" in its name.
Another notable difference is that I added a toggle button to let the user decide if the offset should be automatable or not. The reason is the following:
If it should be automatable, the plug-in must always report its maximum latency to the host in order to be able to possibly apply the (positive) maximum offset when rolling. This inherently leads to a delay when starting the transport if the plug-in is not actually set to the maximum offset.
When this option is disabled, the plug-in will always report its currently minimum required latency, which avoids a delay when starting the transport.
Also, I added a two tiny extensions to the markup language.
You can either pull in the commits as they are or ask me to squash all or some of them in case you don't like some changes.
As discussed in #10, I created a plugin to apply positive and negative delays to audio.
I named it simply "offset" since during development, I had the thought that there is actually no reason why it should have "artificial" in its name.
Another notable difference is that I added a toggle button to let the user decide if the offset should be automatable or not. The reason is the following: If it should be automatable, the plug-in must always report its maximum latency to the host in order to be able to possibly apply the (positive) maximum offset when rolling. This inherently leads to a delay when starting the transport if the plug-in is not actually set to the maximum offset. When this option is disabled, the plug-in will always report its currently minimum required latency, which avoids a delay when starting the transport.
Also, I added a two tiny extensions to the markup language.
You can either pull in the commits as they are or ask me to squash all or some of them in case you don't like some changes.