You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, a few features such as cue, loops but also waveform rendering relies on the track sample count to function properly. They all assume tracks being in stereo. This is misleading as the samples count isn't providing a useful information as there is no way to know if the count has been normalised to stereo (e.g for mono or stem tracks)
In order to clean this up, we should:
Add a new CO track_frames which provide the true frame count of the loaded track (sample count/number of channel)
Replace internal features relying on track_samples to use the frame count instead. Persistence (e.g for cues and loop) will continue using framecount x 2 to maintain backward compatibility)
Deprecate track_samples in the code and in the manual in case user have built up integration with it. In the meantime, its value should be kept to framecount x 2 in order to ensure backward compatibility (e.g with custom community mapping)
Note that currently, there is no track_channels to provide the channel count (and allow computing the true sample counts) but it looks like that isn't something that can be of use just yet, so we should refrain from proactively adding this CO. if it gets required in the future, it should be trivial to add.
The text was updated successfully, but these errors were encountered:
That's right but it doesn't matter because track_samples's value is always framecount x 2, so even if some features do use sample counts (like loops and cues), they actually doesn't use the true sample count but always that framecount x 2, meaning they can be replaced with that new CO, and so we can expose "true" information, as opposite to falsify the sample count. Or did you mean something else?
Currently, a few features such as cue, loops but also waveform rendering relies on the track sample count to function properly. They all assume tracks being in stereo. This is misleading as the samples count isn't providing a useful information as there is no way to know if the count has been normalised to stereo (e.g for mono or stem tracks)
In order to clean this up, we should:
track_frames
which provide the true frame count of the loaded track (sample count/number of channel)track_samples
to use the frame count instead. Persistence (e.g for cues and loop) will continue usingframecount x 2
to maintain backward compatibility)track_samples
in the code and in the manual in case user have built up integration with it. In the meantime, its value should be kept toframecount x 2
in order to ensure backward compatibility (e.g with custom community mapping)Note that currently, there is no
track_channels
to provide the channel count (and allow computing the true sample counts) but it looks like that isn't something that can be of use just yet, so we should refrain from proactively adding this CO. if it gets required in the future, it should be trivial to add.The text was updated successfully, but these errors were encountered: