Volume Automation - gremlins and inconsistencies

[Skap]

Any updates on this one?

 

[parityflux]

Thanks for the poke, Skap. I am nearly certain the tracks in the _AAF folder contain some corruptions, because I can delete those tracks and the issue resolves. Deleting only the objects does nothing -- the tracks need to be deleted. Lawrence at Presonus has everything I supplied him to recreate the issue and said he would check it out when he had time. That was December 9th. Whether that makes it up the chain to developers is unknown. I sent a 9-page PDF with images and text reporting of the issue. I can't attach it here because of the file size.

Regarding the _AAF folder: I created that folder, and then dragged over the tracks from another .song file (via the Browser) to the folder. Said song file was an unedited direct import of an AAF file from the film editor (the editor uses Adobe Premier Pro).

 

[parityflux]

Additionally, If I render the file as it is, with most of the IP removed and with all of the tracks in the _AAF folder DISABLED (and emptied of objects), the offline render runs at 48x real-time and is a bad render. If I delete the 12 or so emptied and disabled tracks, the render runs at 58x real-time and is a good render. So something is up -- something no one can identify unless you are the developer. I did due diligence, I did my part, I thought I did them a solid. It is in Presonus's hands.

 

[Craig Anderton]

Maybe I missed it but I don't see where you tried the real-time render? FWIW I've had mysterious rendering problems happen in programs from <ahem> two competitors, and real-time renders always fixed them. I know a real-time render isn't convenient, but at least with the other programs I couldn't find any other solution. I hope PreSonus can track down your issue.

 

[lowerfreq]

Maybe I missed it but I don't see where you tried the real-time render? FWIW I've had mysterious rendering problems happen in programs from <ahem> two competitors, and real-time renders always fixed them. I know a real-time render isn't convenient, but at least with the other programs I couldn't find any other solution. I hope PreSonus can track down your issue.

I think he tried it here, if I am reading the post correctly:

"Great idea. I should have thought of this. Maybe subconsciously I didn't want to wait for a 10.5 minute render under deadline conditions. Rendering in realtime fixed both 1 and 2 of my original post. I think it's time to report a bug, because this shouldn't happen for such a simple project. Rendering barely touches the CPU. As expected, in rendering it again offline, the issue reappeared."

 

[Craig Anderton]

I think he tried it here, if I am reading the post correctly:

Not sure how I missed that, but it's reassuring that real-time render remains a fallback for these kinds of issues.

 

[Skap]

Thanks for the poke, Skap. I am nearly certain the tracks in the _AAF folder contain some corruptions, because I can delete those tracks and the issue resolves. Deleting only the objects does nothing -- the tracks need to be deleted. Lawrence at Presonus has everything I supplied him to recreate the issue and said he would check it out when he had time. That was December 9th. Whether that makes it up the chain to developers is unknown. I sent a 9-page PDF with images and text reporting of the issue. I can't attach it here because of the file size.

Regarding the _AAF folder: I created that folder, and then dragged over the tracks from another .song file (via the Browser) to the folder. Said song file was an unedited direct import of an AAF file from the film editor (the editor uses Adobe Premier Pro).

Thank you, parityflux, for the update and for all the effort you’ve done here for us users and for PreSonus/Fender. I do believe that Lawrence at PreSonus is the same Lawrence that used to be a power user frequenting the old Studio One user forums. If so, he’s a 100% solid player.

 

[Lukas]

If so, he’s a 100% solid player.

Absolutely.