I’m trying to render an edit to file. It sort of works but the rendered file sounds very different from what I’m hearing when playing back the edit. In particular:
Muted tracks are still included in the rendered file. (Do I need to exclude them from tracksToDo in the call to renderToFile?)
Thanks, ok, then at least I know that I have to look elsewhere… perhaps the volumes aren’t set the way I think etc.
I don’t really understand this line though?
Yeah, it looks a bit weird out of context. It has to do with how the function is called. In this case I guess I could have just referenced song rather than assigning a new pointer. In any case it seems unlikely that it would be related to the quality of the rendered audio file
for (auto i = 0; i < te::getAllTracks(*song).size(); i++) {
auto *at = te::getAudioTracks (*song)[i];
Your index i will range over all tracks, but you’re using it to index into an array of only the audio tracks, so some of them are out of range, and that’s where your nullptrs come from. Get modern and try range based for loops instead.
Re: the levels, some audio devices let you get away with playing back audio that goes above 1.0 by compressing it to avoid it sounding distorted. So it could be just that your mix is too loud and will get clipped when flattened into a wav file, but sounds OK when you render it live.
After spending a couple of hours on this problem, I suddenly realised that I might have misinterpreted your answer: I thought you were saying “that shouldn’t happen” but what you were actually saying was that I shouldn’t include the muted tracks when calling renderToFile! Correct?
This indeed seems to have been the case. At first this seemed unlikely as I was only playing back an audio file without changing the volume plugin. But it turned out that the culprit was a reverb plugin – for some reason the built-in reverb multiplies the dry gain value by 2, so my gain setting of 1.0 meant that the dry signal was doubled in gain.
This increased signal still played back fine on CoreAudio, probably because of some internal compression/limitation as you said.