norfolkmastering

23 hours ago, norfolkmastering said:

 

Thanks Mark.  Would you mind please checking if it is related to a possible issue with the API which seems to be reporting only the stereo port friendly name when a track send is routed to a mono port.  Many thanks.

22 hours ago, msmcleod said:

They're totally unrelated.

Thanks Mark.

Would you be okay to log the issue that the surface API is reporting only the stereo port friendly name when a track send is routed to a mono output, for fixing in Sonar please?

I want to derive a pre FX track send, so clean audio to send out to an analogue effects bus.

Is there any way to do this without having to start duplicating tracks?

I thought I could use an external insert with just the send allocated to a port but it doesn't work.

All suggestions welcomed!

6 hours ago, norfolkmastering said:

Just found a bug on the latest early release relating to duplicate track function.

If I duplicate a track which has a send routed to a mono output, then the duplicated track's send is routed to the stereo pair not to the mono send.

So e.g. if I have an audio output pair with the friendly names;

DAW1 : L

DAW2 : R

So the stereo output would show as DAW1 + DAW2 : S

Let's say that track 1 has a send with destination DAW1 : L

When I duplicate track 1 (to track 2), then track 2's send is to DAW1 + DAW2 : S

I don't remember this error in previous releases.

6 hours ago, msmcleod said:

This is not a new bug - it happens in 2022.11 as well.  I'll get it logged.

Thanks Mark.  Would you mind please checking if it is related to a possible issue with the API which seems to be reporting only the stereo port friendly name when a track send is routed to a mono port.  Many thanks.

Just found a bug on the latest early release relating to duplicate track function.

If I duplicate a track which has a send routed to a mono output, then the duplicated track's send is routed to the stereo pair not to the mono send.

So e.g. if I have an audio output pair with the friendly names;

DAW1 : L

DAW2 : R

So the stereo output would show as DAW1 + DAW2 : S

Let's say that track 1 has a send with destination DAW1 : L

When I duplicate track 1 (to track 2), then track 2's send is to DAW1 + DAW2 : S

I don't remember this error in previous releases.

Can I make another appeal for a second early access release together with an updated bug fix list so we have a final chance to check through all fixes before the final public version is released.

And some idea of how long we would have to check out that second early release version before it gets frozen ready for public release.

On 9/4/2023 at 3:08 PM, azslow3 said:

Originally reported Bus names related problem is fixed.

Unfortunately (I guess almost the same, so some cache...) problem exists (for me) with Sends. MIX_PARAM_SEND_OUTPUT returns the same value even after the send destination is changed. At some point the values is updated (f.e. when a send for another strip is added), but it seems like cached over destination changes.

It seems like I get topology update notification after changing the destination, but I can't get updated value...

On 9/4/2023 at 4:15 PM, msmcleod said:

This has now been fixed.

Hi Mark

Could we get an interim release to check the API fixes please?

Can I urge that another interim release is done before the public version, with an updated list of bug fixes, taking into account any work which has been done since the first early access release.  Especially important if this is going to be the final release of Cakewalk by Bandlab.

And maybe give us a deadline for final testing of that interim release so we don't get caught on the hop!

Thanks

22 hours ago, msmcleod said:

I think this has just been missed from the release notes.  The fix was done in the Sonar code in Feb, and applied to the CbB code back in April.

Thanks Mark.  I'll ask Alexey to check the AZ Controller end now.

I was hoping to see an issue reported back in February dealt with in the latest update.  It concerns lack of updating of the track output name in the API when a bus is renamed.  Mark said he had a fix and it would be included in the next release.  If you read the first three posts in the topic below, the issue and solution are discussed.  Can you let me know if this is an omission will be picked up before the final release please.

Okay I found the mechanism which is triggering the change in default rec source.  Please give this a try on your own system and let me know if you get the same result.

The first audio input pair on my list (and so the default rec source) has the friendly name 'DEFAULT : S'

For the track under test;

Put the track's PAN control fully LEFT.

Make sure that no source is selected to that track.

Select that track's REC ARM button and the default source is selected as "DEFAULT : L"

Deselect the source (back to "None") and the REC ARM button will be deselected.

Now turn that track's PAN control to ANY position apart from fully LEFT.

Select that track's REC ARM button and the default source is selected as "DEFAULT : S"

This was 100% repeatable on any track off any project.

I've reported this odd behaviour to the Bandlab guys.

I'm using four MOTU UltraLitemk3 interfaces which have been working reliably for many years.

To explain that when I'm doing song composition, I just hit the REC ARM button on the track I want to record to and it should connect to the default record source.  That's a standard Cakewalk feature.

I tried changing the track interleave but it makes no difference to the issue of inconsistent default source selection I explained in my earlier post.

So it's a bit of a mystery!

I'm having a problem that when I press the Record button on a track (which is currently selected to no source) then I am not getting the same default record source.  The first source in my Input Driver list is called 'DEFAULT REC'

On some tracks, when I press REC ARM, Cakewalk is selecting 'DEFAULT REC :S'

And on some other tracks, when I press REC ARM,  it is selecting 'DEFAULT REC:L'

Can anyone explain why this might be happening?

Thanks

Thanks for the advice.  Can I just check a point?

Were you able to download a complete copy of Cakewalk without having to start the install?

I'm not worried about the activation time out as I can't imagine that Bandlab would leave users of Cakewalk by Bandlab without the means to use the software. 

Now that the days of Cakewalk by Bandlab are coming to an end, can someone tell me if it's possible to download a complete version of Cakewalk by Bandlab as a safety copy should I have to reinstall (maybe when I buy a new PC).

I mean a complete copy which doesn't then rely on having to access further download files on the Cakewalk by Bandlab server (which may no longer be there in the future)

Thanks

I'm syncing a Fostex G24S to Cakewalk.

Cakewalk outputs MTC which (using a PC app) is converted to LTC which is input to the G24S external sync input (The G24S supplies the 'slave' LTC from track 24).

It all works really well and sync is tight but every so often Cakewalk changes its sync source from Audio to SMPTE/MTC, almost as if its decided to slave to the G24S (which is not what I want!)

3 hours ago, 57Gregy said:

Is there any audio in the project when this happens?
 

Yes there is audio on multiple tracks.

My Cakewalk set up includes an analogue tape machine which is slave locked to Cakewalk.

Cakewalk is set to Clock\Source\Audio.

Occasionally during operation, Cakewalk will change its clock source to SMPTE/MTC for no obvious reason.

Any idea why this is happening?

You solved it!  The second track was selected but for some reason its clip had not highlighted.

Working okay now, thanks!

I have two tracks which comprise part one and part 2 of a performance.  I want to bounce these down to a single track.  So I first select both tracks.

When I open the Bounce to Tracks menu, I can see both source tracks ticked in the Source table (and they are also ticked in the Tracks/Buss in Project table)

I select a blank track as the destination.

When I click 'Okay', the first track (first part of performance) is rendered correctly but the second track (second part of the performance) is rendered as silence.

I can't see what I'm doing wrong!  Help!

Understood.

2 minutes ago, msmcleod said:

That would make sense.

Cakewalk only tells you things it's changed.  If you know you've changed via the API, why do you need Cakewalk to tell you what you've changed?

In the tests I have done, I am changing the send destination in Cakewalk by mouse, but I get no output from AZ Controller unless I change somethings else to invoke a refresh (e.g. a track destination).

I am changing the send destination but it's possible the flag is not being read by AZ Controller.  Alexey will check this once the next Cakewalk release is available.  Any idea when that might be?

Mark

Just a note to say that in my tests, changing a send destination does not seem to be triggering a topology graph change.  Would you mind checking this as part of the update work for the next release?

Thanks for explaining this.  I'm now putting my pattern variations on to a second MIDI track and this works okay for me.