2021.04 Feedback

[TimAllenMusic]

I've had an issue with the new Tempo Track. I've loaded an existing project, and it has overwritten my existing tempo data. In many cases, the overwritten version is an accurate simplification of the old data (for example, if the old data was a lot of tempo changes that amounted to a straight-line transition from one tempo to a new tempo, the new data takes the first tempo and creates a single linear transition to the new tempo). However, in some cases, the overwritten tempos are completely inaccurate. As far as I can tell, this is happening when I'd previously drawn in manual tempo changes - these have been removed and replaced with "fast" or "slow" curves, which don't match the original data. In some cases, these curves are now running until the following tempo change, which is completely inaccurate. Is this a known issue, and if so, is there a timeframe for resolution? I suspect I'm going to have to roll back to the previous version to complete the project I'm working on (and thank goodness I have a recent backup of the file!). I love the idea of the new Tempo Track - just want to be certain that the implementation isn't going to overwrite my handcrafted data before I try updating again...

[TimAllenMusic]

17 minutes ago, TimAllenMusic said:

I've had an issue with the new Tempo Track. I've loaded an existing project, and it has overwritten my existing tempo data. In many cases, the overwritten version is an accurate simplification of the old data (for example, if the old data was a lot of tempo changes that amounted to a straight-line transition from one tempo to a new tempo, the new data takes the first tempo and creates a single linear transition to the new tempo). However, in some cases, the overwritten tempos are completely inaccurate. As far as I can tell, this is happening when I'd previously drawn in manual tempo changes - these have been removed and replaced with "fast" or "slow" curves, which don't match the original data. In some cases, these curves are now running until the following tempo change, which is completely inaccurate. Is this a known issue, and if so, is there a timeframe for resolution? I suspect I'm going to have to roll back to the previous version to complete the project I'm working on (and thank goodness I have a recent backup of the file!). I love the idea of the new Tempo Track - just want to be certain that the implementation isn't going to overwrite my handcrafted data before I try updating again...

I've just seen a post in a different thread that fixes this issue.

"If you set the following within Preferences->File->Initialization File:

TempoImportErrorThreshold=0

... the tempo will be imported exactly as it was in the old project and won't try to fit an envelope shape to the map."

 

Might be worth flagging this more prominently - currently, the new update "breaks" existing projects with non-trivial tempo data unless this flag is set. Might even be worth setting the flag as a default?

[timboalogo]

!

Edited May 1, 2021 by timboalogo

[Colin Nicholls]

3 hours ago, Herbert Zio said:

As I mentioned in the other topic, this is a bug for me when comparing with Sonar Platinum. And when you open the Bus Pane and lift it to the top, when you collect it by the button, that separation disappears on Cakewalk.

Sonar Platinum

Cakewalk By Bandlab 

That's a Bug FIX for me

[Herbert Zio]

20 minutes ago, Colin Nicholls said:

Isso é um Bug FIX para mim

Is this a bug fix? ?

[Colin Nicholls]

@Herbert Zio, huh, you're right. If you pull the Bus Pane separator all the way up so that it fills the space (hiding the Track Pane) and then press the Show/Hide Bus Pane button, the separator line is not re-drawn.

The reason I called it a bug fix is because I don't recall the separator line being shown at all in earlier versions of SONAR/Cakewalk.

Thanks for taking the time to prepare the visual.

[John]

1 hour ago, Herbert Zio said:

Is this a bug fix? ?

You see the gray line at the bottom just below where the speaker icon is? That may be the separation between the bus pane and the track pane. See if you can raise it up to expose your master out. 

[DeeringAmps]

See my thread here We have a timing issue 2021.04 is dropping clips late when recording.

@Noel Borthwick Both my machines were (now are) on 2021.01 Build 98, and working properly.
I have not done a "Loop Back" test as yet, but I will and report back if I have any more issues.

"The Law of Unintended Consequences"
I see below you mentioned no changes were made to "Recording" in the .04 release, but evidently the above quoted "Law" has reached out and bite you in the proverbial; well you know what I mean.
I always blame Rockus n Rollus (The Gods of Rock Music) when things like this happen...

tom

Edited May 2, 2021 by DeeringAmps
added content

[Colin Nicholls]

12 hours ago, Noel Borthwick said:

It was only done this week so it's after the EA.

I run at 2K (1440p) at 100% scaling and didn't notice a difference until I changed the scale to 150%. Since it's new we didn't enable this by default so any feedback is useful.

@Noel Borthwick,

Pros: The text is definitely crisper

Con 1: The text is rendered smaller than when the config setting is 0. It maybe just goes under the threshold of comfort, for me personally. At my normal scaling of 125% I find I prefer to turn off this feature.

Con 2: There is some kerning issues with bold text. Probably nothing you have control over, font scaling is tricky. See below, specifically "gr" "it", "at" etc.

 

[Noel Borthwick]

3 hours ago, DeeringAmps said:

See my thread here We have a timing issue 2021.04 is dropping clips late when recording.

 

tom

@DeeringAmps We'll investigate this. There were no changes made to recording this release. Which version were you running before you updated? Have you tried rolling back to verify if this is a new issue?

[Noel Borthwick]

3 hours ago, Colin Nicholls said:

@Noel Borthwick,

Pros: The text is definitely crisper

Con 1: The text is rendered smaller than when the config setting is 0. It maybe just goes under the threshold of comfort, for me personally. At my normal scaling of 125% I find I prefer to turn off this feature.

Con 2: There is some kerning issues with bold text. Probably nothing you have control over, font scaling is tricky. See below, specifically "gr" "it", "at" etc.

 

Thanks, we have no control over this - its all handled by Windows.

[giovannibuchelli]

I'm having a problem with ASIO reported latency and with manual offset (not working at all).

[Štefan Gorej]

@Noel Borthwick, the dump file, that I sent in my previous post, was from my "experiment" with .FXC chain loading to already opened Cakewalk project.
I'm sending the dump that came from crash during Cakewalk project load. Exact steps were as follows:

1. I created a new, completely empty project, added one bus track
2. Added an instance of Presswerk VST3 to FX slot of this bus, switched the FX chain and the plugin itself
3. Opened the plugin window to ensure that it's successfully loaded and initialized
4. Saved the project as a new .CWP
5. Exited Cakewalk and started it again
6. Loaded .CWP project saved in step 4

=> Crash on Presswek VST3, dump file from this cras is attached.

So, as I experimented, plugin crashes in this two scenarios:

a) When loading .CWP project that already contains Presswerk or Satin VST3
b) When loading FX Chain that contains Presswerk or Satin VST3 into already opened Cakewalk project

I also tried following scenario:

1. Created empty .CWP project
2. Added Presswerk VST3 plugin instance
3. Loaded existing preset into it using CAKEWALK PRESET functionality (.vstpreset file)

This scenario was successfull, without crash, all parameters values from VST preset loaded successfully into existing plugin.

See my attachments.

Hope this may help to better understand my specific problem.

Thank you,
Stefan

_05022021_093720.zipPresswerk.vstpreset

EDIT: Btw. How to roll back to previous Cakewalk build to be able to load my projects and manually note Presswerk and Satin values to be able to manualy set them the same way in VST2 plugin instances (until solved in software)?

_05022021_093720.zip

Edited May 2, 2021 by Štefan Gorej
Added question

[Mark Morgon-Shaw]

Icons do not match !!!...Please cure for my OCD  ?

( Great Update BTW..awesome ) 

[Jan]

5 hours ago, Noel Borthwick said:

Thanks, we have no control over this - its all handled by Windows.

This seems to be a font that is a combination of bitmap (smaller sizes) and vector (larger sizes) - I believe it's the plain old MS Sans Serif. Changing the font on those labels would probably solve that.

While I'm here - kudos on the new look of the envelopes, I was just thinking a couple of days ago "I wonder if Cakewalk finally got rid of this outdated 3D look for nodes" Maybe this will convince me to upgrade (still on 2019.09 here...)

[User 905133]

On 4/30/2021 at 5:04 PM, Herbert Zio said:

Is there a way to change the background color of the bus pane . . . through the theme editor

@Herbert Zio  Would something like this or this be helpful? 

PS: This question is not really 2021.04 Feedback. If there is additional discussion, I'd suggest using a different thread maybe under Q & A or the UI Themes Sub Forum?

Clarification of my intent: Anything I have to say WRT colorization and the theme editor is not specific to 2021.04; therefore, I do not plan to address the question with additional posts in the current thread. Sorry for the misunderstanding.

Edited May 2, 2021 by User 905133
to clarify the intent of my response

[Herbert Zio]

2 hours ago, User 905133 said:

@Herbert Zio  Algo como isso seria útil? 

PS: Esta questão não é realmente um Feedback 2021.04. Se houver discussão adicional, sugiro usar um tópico diferente, talvez em  P&R ou no Sub-fórum de temas de interface do usuário .

 

For me, it's feedback about 2021.04. After all, the Tempo Inpector function corresponds to 2021.04, and the background color of Tempo Inspector does not correspond to the rest of the DAW and is not harmonious.

It is better to fix the problem before the official release, than to accumulate unresolved bugs like the other colors I mentioned, whether from the bus pane or from others inspectors or browser.

[Ronny.G]

 

Quote

UI

MIDI Ports from synths should not be exposed to their own inputs

You could introduce an option to disable this behavior introduced with the last update and return, if desired, as it was before?

There are cases where for speed or convenience it's easier to act for example on modulation and pitch wheels or even other particular controls of the VST synth that are exposed as midi out directly acting on the wheels, buttons or other within this and record them as midi events, without necessarily having them assigned to an external MIDI controller or create an additional MIDI track (useless) in CbB just to get around the limitation of not being able to activate the VST midi output on their own inputs and record these, as it was possible before the change.

Many thanks you for your support

Edited May 2, 2021 by Ronny.G

[Base 57]

I accidently posted this in another thread. It belongs here.

 

Record Latency Adjustment in Preferences has no effect at all. In a loopback test I have an offset of 374 regardless of the setting.

If I change the Manuel Offset, it changes where the clip boundary starts but the wave is off by 374. Whether checking the Use Reported ASIO Latency box or not the wave is  offset by 374.

edit.

Instead of rolling back I have set a nudge to 374. That lines up the Wave accurately. So I will use this as a workaround until there is a fix.

Edited May 2, 2021 by Base 57
Added a couple lines.

[Fred's Gratis Scores]

I use Cakewalk with BandLab and was excited to see the feature where you can open from and publish to BandLab directly. I've spent a little time playing with it this morning and noticed a few things:

• Muted tracks in my Cakewalk project are not muted when uploaded to BandLab. My use case is that I want to upload the MIDI tracks with audio stems so that when the project is forked, others can use the stems and have the MIDI to figure out the chord progressions or just start fresh with their own versions. Unmuting tracks that I set to muted renders them on the revision when they are not supposed to be there.
  To work around this I need to manually open the project on BandLab, mute the tracks, and save which creates another revision.
• After fighting this for a while, I found out that an instrument track counts as 2 tracks toward the publish limit of 16 tracks. I had to manually spit the instrument track and select only the MIDI or audio that I wanted included to publish. Perhaps you could only count an instrument as 1 track, and automatically publish the MIDI if the instrument is not frozen, or the audio if the track is frozen.
  If we really do want to publish both the MIDI and audio, then the user can split the track and select both (or ideally not have to select both if the track count is still below the maximum).
• I understand the track limits as each audio track takes up space on your servers. However, this makes collaborating using the publish feature difficult for those that compose in the "Classical" category (all the woodwinds, brass, and strings alone are already much higher than the limits). If I ask a collaborator to add a solo violin that I don't have, they would have to render the audio, and increase the audio track count. 
  I'm not sure what the solution is that respects BandLab's servers and allows higher track count composers to collaborate using this feature.

 

Edited May 2, 2021 by Fred's Gratis Scores