2022.02 Feedback

[gmp]

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

[Noel Borthwick]

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.

[gmp]

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 March 10, 2022 by gmp

[Noel Borthwick]

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.

 

[gmp]

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.

[Sean MacGillivray]

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 March 12, 2022 by Sean MacGillivray
correct terminology (busses v channels)

[Noel Borthwick]

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.

[Sean MacGillivray]

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.

[David Baay]

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.

[Olaf]

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.

[Will.]

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.)  

 

[Glenn Stanton]

is that a stock theme?

[Noel Borthwick]

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.

[Noel Borthwick]

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.

 

[Will.]

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. 

[David Baay]

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.

[Olaf]

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.

[Noel Borthwick]

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.

[Milton Sica]

Error encountered when trying to delete tracks from the
BBC Symphony Orchestra 1 64-bit version.

Follow Dump.

MM_Pelos caminhos_03142022_201528.txt

[Milton Sica]

On 3/14/2022 at 8:30 PM, Milton Sica said:

Error encountered when trying to delete tracks from the
BBC Symphony Orchestra 1 64-bit version.

Follow Dump.

MM_Pelos caminhos_03142022_201528.txt 1.03 kB · 3 downloads

I need help about this. Please !