Jump to content
Morten Saether

2022.02 Feedback

Recommended Posts

8 hours ago, msmcleod said:

@gmp - can you also try the project with the latest 2022.02 Update 1?   (2022.02.39)

I tried it with the update, and it still stops at 4:17

Share this post


Link to post
Share on other sites
52 minutes ago, gmp said:

I tried it with the update, and it still stops at 4:17

@gmp the issue is caused because you have the first two tracks going to the Vocal Mix bus. However the Vocal Mix bus goes to a patch point Aux S/PDIF which is not assigned to any track input. This is a corner case that leads to the buffer overflow.  Why is this patch point being used if its not assigned?
I added a new track and assigned its input to Aux S/PDIF and the problem goes away.

I'll see if there is a way to catch this case and handle it better.

Share this post


Link to post
Share on other sites
Posted (edited)
23 minutes ago, Noel Borthwick said:

@gmp the issue is caused because you have the first two tracks going to the Vocal Mix bus. However the Vocal Mix bus goes to a patch point Aux S/PDIF which is not assigned to any track input. This is a corner case that leads to the buffer overflow.  Why is this patch point being used if its not assigned?
I added a new track and assigned its input to Aux S/PDIF and the problem goes away.

I'll see if there is a way to catch this case and handle it better.

I have an AUX track in my template, but in this particular song since I didn't need it I deleted this track along with many other tracks. Sometimes I change the output of the vocal track to S/PDIF, so that's why I didn't delete it. I always use only 1 template and just delete tracks I don't need depending on the song.

Edited by gmp

Share this post


Link to post
Share on other sites

You should remove references to the dead patch point then. Why keep patchpoints that are no longer in use. You had buses that still output to those patchpoints. These are corner cases that cause issues like this.

Edit: @gmp I've identified and fixed the underlying issue that could lead to this dropout happening for next release. It will work ok with patchpoints that are partially connected.

 

Share this post


Link to post
Share on other sites
23 hours ago, Noel Borthwick said:

You should remove references to the dead patch point then. Why keep patchpoints that are no longer in use. You had buses that still output to those patchpoints. These are corner cases that cause issues like this.

Edit: @gmp I've identified and fixed the underlying issue that could lead to this dropout happening for next release. It will work ok with patchpoints that are partially connected.

 

Thanks, Noel, I appreciate your advice and explaining why it was happening.

Share this post


Link to post
Share on other sites
Posted (edited)
On 3/10/2022 at 2:23 PM, Noel Borthwick said:

You should remove references to the dead patch point then. Why keep patchpoints that are no longer in use. You had buses that still output to those patchpoints. These are corner cases that cause issues like this.

Edit: @gmp I've identified and fixed the underlying issue that could lead to this dropout happening for next release. It will work ok with patchpoints that are partially connected.

 

Noel, this was actually super helpful for me in working around a different issue! I was super excited to get Task Queues for exporting bounces, as I have an entire record in one session file and so being able to set up a variety of time ranges + export settings is really ideal.

I was finding that certain songs would write a small placeholder file at the beginning of the task, and would appear to export the audio, but then would never write the final file. The issue was reproducible to an extent but would occasionally not happen when I exported those tracks subsequent times.

After reading your comments about null busses, I remembered that I have four additional channels which are not assigned to any output bus because they're just holding lanes for editing purposes. The four songs which exhibited the issue consistently were the ones which had wave data in these channels.

Cakewalk complains about these channels every time I open the session - I can't say I wasn't warned! - but until I started using the Task Queue it had never been a problem to leave their outputs assigned to nothing.  I have those channels muted anyway so I just assigned them to the main buss and it totally resolved the export issue; all the files are being reliably written every time now. Thanks for your insight, Noel!

Edited by Sean MacGillivray
correct terminology (busses v channels)

Share this post


Link to post
Share on other sites
58 minutes ago, Sean MacGillivray said:

Noel, this was actually super helpful for me in working around a different issue! I was super excited to get Task Queues for exporting bounces, as I have an entire record in one session file and so being able to set up a variety of time ranges + export settings is really ideal.

I was finding that certain songs would write a small placeholder file at the beginning of the task, and would appear to export the audio, but then would never write the final file. The issue was reproducible to an extent but would occasionally not happen when I exported those tracks subsequent times.

After reading your comments about null busses, I remembered that I have four additional channels which are not assigned to any output bus because they're just holding lanes for editing purposes. The four songs which exhibited the issue consistently were the ones which had wave data in these channels.

Cakewalk complains about these channels every time I open the session - I can't say I wasn't warned! - but until I started using the Task Queue it had never been a problem to leave their outputs assigned to nothing.  I have those channels muted anyway so I just assigned them to the main buss and it totally resolved the export issue; all the files are being reliably written every time now. Thanks for your insight, Noel!

That's a different issue. Are you referring to tracks assigned to "none"? Depending on your export settings they may have been getting skipped since they are not audible.

The OPs situation was that that he had buses assigned to patch points, but the patch points were not assigned to a track so it was leading to a boundary case.

Share this post


Link to post
Share on other sites
2 hours ago, Noel Borthwick said:

That's a different issue. Are you referring to tracks assigned to "none"? Depending on your export settings they may have been getting skipped since they are not audible.

The OPs situation was that that he had buses assigned to patch points, but the patch points were not assigned to a track so it was leading to a boundary case.

Hi Noel,

Yeah that's it, I had four tracks in the session which had wave data I didn't want included in the bounces, so I had them assigned to "none".  Assigning them to the main buss solved my issue where the songs that had wave data on those tracks would not export properly from a Task in the Task Queue.

Share this post


Link to post
Share on other sites
On 3/10/2022 at 11:23 AM, Noel Borthwick said:

Why keep patchpoints that are no longer in use...  ....I've identified and fixed the underlying issue that could lead to this dropout happening for next release. It will work ok with patchpoints that are partially connected.

@Noel Borthwick Maybe a prompt is needed when removing the last send/receive end of a patchpoint, asking the user if the patchpoint should be removed, similar to removal of a synth prompting to remove related tracks. I recently discovered I had a "send to nowhere" from the Metronome bus because I had deleted the click track it was feeding and forgot about the patchpoint.

  • Like 1

Share this post


Link to post
Share on other sites

After installing Update 1, I've had the following problem. An audio track that is routed to the Master is detected as assigned to an unused hardware output, on project load. Of course the track is not silent, and it plays alright, because it's not routed to any hardware output, but that's how it's recognized.

And I've started having audio dropouts - I believe the code is 19.

Share this post


Link to post
Share on other sites

Pay attention to the meter in track 1.

Not an issue at all, its just distracting. Is anyone perhaps experiencing this too -  since last Update (1.)  

 

Share this post


Link to post
Share on other sites
On 3/13/2022 at 11:08 AM, David Baay said:

@Noel Borthwick Maybe a prompt is needed when removing the last send/receive end of a patchpoint, asking the user if the patchpoint should be removed, similar to removal of a synth prompting to remove related tracks. I recently discovered I had a "send to nowhere" from the Metronome bus because I had deleted the click track it was feeding and forgot about the patchpoint.

I've fixed the underlying issue that would leak buffers so it should be no longer a problem. A warning isn't appropriate since the user could be in this state while manually creating patch points and routing them.

Share this post


Link to post
Share on other sites
21 hours ago, Olaf said:

After installing Update 1, I've had the following problem. An audio track that is routed to the Master is detected as assigned to an unused hardware output, on project load. Of course the track is not silent, and it plays alright, because it's not routed to any hardware output, but that's how it's recognized.

And I've started having audio dropouts - I believe the code is 19.

Check if the track has sends that have been assigned to "none". That can also cause this issue. If you can't find out why send the cwp file and we can take a look.

 

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Glenn Stanton said:

is that a stock theme?

Yes, and it's weird and this is on the main system. It seems to be fine now. That was the third time since UPDATE 1. I haven't done a reinstall or anything yet. Like I've said it is not an issue that prevents me from making music - it's just distracting and only seem to happen in the CV and not TV. I'll do some troubleshooting later. Maybe do a rollback and reinstall. 

Share this post


Link to post
Share on other sites
2 hours ago, Noel Borthwick said:

A warning isn't appropriate since the user could be in this state while manually creating patch points and routing them.

Yes, that occurred to me, but I was thinking it could be based on the action of a deleting a connected object, specifically.

Share this post


Link to post
Share on other sites
2 hours ago, Noel Borthwick said:

Check if the track has sends that have been assigned to "none". That can also cause this issue. If you can't find out why send the cwp file and we can take a look.

That's exactly what it was. I removed it last night, and now the problem's gone away.

Share this post


Link to post
Share on other sites
4 hours ago, Olaf said:

That's exactly what it was. I removed it last night, and now the problem's gone away.

Great. That error message is primarily for diagnostics in cases where some tracks are inadvertently set to output silence.
You can disable it by setting the "WarnSilentBuses" flag to 1 in the Initialization File section in preferences.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...