sorry that I add a layer of complexity here.
I have no spare time at the moment to investigate (even if I would love to..) this behaviour, but even if I'm uncertain if it's related I decided to post this link to a "problem" which is similar when you bounce or just play back. It seems only a problem when you trigger sound with midi, but maybe the warp marker are handled similar to midi.
I posted this some time ago and there is also a video which shows the problem.
http://forum.ableton.com/viewtopic.php? ... ilit=video
disclaimer:
I don't have any problems with the sound quality in ableton. for most mixing processes a 1 sample offset does have absolutely no bad effect , but for parallel processing even a 1 sample offset can be a problem which is noticeable and I like to do that a lot for sound design. And to prevent a "oh ableton sucks" rumour: I have tested this with another big sequencer too and it has the same problem even if it's different in detail.
Audio engine bug - Consolidate not as per manual.
-
mr.ergonomics
- Posts: 919
- Joined: Thu Nov 08, 2007 3:12 am
Re: Audio engine bug - Consolidate not as per manual.
I didnt look at you video and only skim read the other referenced thread.
It looks related to the issues related to there being mutiple ways of arriving at a point in sample time and that sample accuracy at an arbitary playback position cannot be guaranteed for all tempos.
I guess the issue gets confusing because the first pass over a point in music time may yield a different point in sample time according to how the playback poition got there - which is what points 1, 2 and 3are about fixing to make the behaviour predictable at leastt even if the CPU overhead f ensuring 100% accuracy all the time is not a reasonable trade off.
As I said, sample accuracy of this nature is a common problem with implementing a DAW, so all we can reasonably ask for at this time is consitency and repeatability according to well defined rules rather than perfection.
Of course, I would still like an option at times to choose to take the likely CPU hit and have 100% perfection for specific tasks where it is needed
It looks related to the issues related to there being mutiple ways of arriving at a point in sample time and that sample accuracy at an arbitary playback position cannot be guaranteed for all tempos.
I guess the issue gets confusing because the first pass over a point in music time may yield a different point in sample time according to how the playback poition got there - which is what points 1, 2 and 3are about fixing to make the behaviour predictable at leastt even if the CPU overhead f ensuring 100% accuracy all the time is not a reasonable trade off.
As I said, sample accuracy of this nature is a common problem with implementing a DAW, so all we can reasonably ask for at this time is consitency and repeatability according to well defined rules rather than perfection.
Of course, I would still like an option at times to choose to take the likely CPU hit and have 100% perfection for specific tasks where it is needed
Nothing to see here - move along!
Re: Audio engine bug - Consolidate not as per manual.
Hello,
Let's say you have two tracks with identical Clips, both with enabled Groove feature and you use Utility to cancel the phase: all fine.
If you now consolidate one track, the phase will cancel again if you disable Groove for both Clips afterwards (the original and consolidated Clip). If you commit the Groove before consolidating, all is fine.
I don't think it's a technical bug, more an oddity with the Groove feature. In any case, will look deeper into this.
Thanks,
Christian
Let's say you have two tracks with identical Clips, both with enabled Groove feature and you use Utility to cancel the phase: all fine.
If you now consolidate one track, the phase will cancel again if you disable Groove for both Clips afterwards (the original and consolidated Clip). If you commit the Groove before consolidating, all is fine.
I don't think it's a technical bug, more an oddity with the Groove feature. In any case, will look deeper into this.
Thanks,
Christian