sreams

On 10/5/2023 at 10:08 AM, Mark Morgon-Shaw said:

Because I rarely use them and they waste space in the console buss view ...so it ends up like this

Instead of this

I just make sure those two busses are always last. Then they never really interfere.

On 9/11/2023 at 8:40 AM, Noel Borthwick said:

@sreams no changes in this area and it's working fine here. There are two things to check.

1. Only waveforms for unique clip wave files are rendered in parallel. i.e. if you have 100 clips that all come from the same wave file then they will only display when the full wave file has been rendered. IOW parallel rendering is per file not per clip.

2. Parallel rendering is controlled by the aud.ini variable "EnablePicCacheThreads" not the multiprocessing setting. Check if somehow that variable got set to 0.

Try importing a bunch of wave files into a new project and then select all and choose "recompute waveforms" from the clip properties. They should render in parallel.

Thanks Noel. The aud.ini entry is set to 1. Importing and recomputing works fine.

The time I saw it only doing one waveform at a time, I had just used AudioSnap to time correct about 8 tracks of drums. After Bouncing to Clips, the resulting waveform redraw happened one track at a time. I'll try and see if I can reproduce it.

I'm not sure if this is particular this version or not... but I just noticed that Cakewalk is only computing waveforms for one clip at a time. It used to be that, if you had the multiprocessing engine enabled, it would compute waveforms for as many clips at once as you had cores. No longer seeing this... so waveform drawing takes a lot longer than it used to.

13 hours ago, EnglandBross said:

is it possible to insert a control to move all automation point from FADER ?

Offset mode should handle this. Press "O" on your keyboard, and now you have a separate control that is not tied to the envelope.

I haven't found a way to reproduce this consistently... but after installing the EA build today (was on the latest release build before that), I have had three crashes to desktop during playback. Two times just pressing play, and once a crash just in the middle of playback... with Cakewalk just disappearing.

1 hour ago, scook said:

Try the 2022.02 EA release

From the EA post

If the copy still fails, post in the EA thread.

Just installed the EA build and it appears to be fixed. Thanks!

Try this:

1) Open Cakewalk and start a new project

2) Insert two MIDI tracks

3) Record some MIDI notes onto the first track

4) Double click on the resulting clip to open Piano Roll View

5) Draw a box around some (not all) of the notes to select them

6) In the Track View, drag the selection down to the second track

I get a crash to desktop every time. If I select all of the notes... no crash.

10 hours ago, Steve Patrick said:

On the voiceover suite DAW I'm getting these bright red pop-ups when opening Cake that I have "12 days to sign in and activate"  And even when I try to sign in I get the "invalid name or password" thingy.  I've never had this...and don't have it now...on my music production DAW.  

What gives??

(I even tried updating Cake using the BL Assistant...no love)

Try choosing "forgot password" and reset it. No problems logging in here.

An Aux Track is really just a bus that sits in the tracks pane. In a perfect world, they would simply load as busses when opened in older versions... but I doubt that happens.

17 hours ago, Herky Acuff said:

 

This is good stuff... but a bit unnerving that almost every tempo change does not occur right on a beat.

14 hours ago, Hieu Nguyen said:

Yes, creating a tempo map that matches an existing audio is exactly what I wanted to do. I'm going to try your solution but I'm wondering why it is so complicated: in Pro Tools First, you just have to identify the first measure, the last measure, the middle measure, the middle of the middle, etc. and you are done after 3 to 5 identifications.

And regarding audio snap, I just don't understand how it works, even after having learned hours and hours from tutos on youtube.

It's not complicated at all. One pass and you are done. I guess I could see it not going so smoothly for those who have no MIDI input device.  You mentioned lag. What is your ASIO latency in Preferences? Did you try using a smaller buffer size?

7 minutes ago, John Vere said:

There are lots of good tutorials on using Audio snap. Mike of Creative Sauce has a real good one. 

Did you try dragging one of the drum tracks like the hi hat to the time line. This is a Melodyn feature that works when it works. I found hi hat the best. 

I don't think he is looking to alter the audio at all. Looks more like he wants to create a tempo map that matches the existing audio.

"Fit Improvisation" in the Process menu is what you'd want if that is your goal. Create a MIDI track, use a MIDI controller to tap out the tempo as you listen to the audio. Then use "Fit Improvisation" and the Tempo Map will be created matching your input. *Way* easier than doing it all by hand.

6 hours ago, msmcleod said:

The exported MIDI file does have the program changes.

What is happening, is when you load the MIDI file (which is effectively an import), the first program change is automatically assigned to the track:


 

Ah... thanks. That makes sense.

I did try moving the patch change to a later time (1:01:003), but it still does this in that case. Wouldn't that be a situation where the .mid file is no longer consistent with the .cwp file? The patch change would not be sent at the same time in both files... and I would want it sent at the specific time I set it to.

I'm noticing this consistent behavior today. I have multiple projects that have a MIDI track setup with patch changes only. If I export this track to a Standard MIDI file (or drag the clip onto the desktop), the first patch change is not included. If I duplicate the first patch change first (so that there are two of the same patch changes at the exact same time), the export includes only one of them (this is my sort-of workaround for the moment).

I've attached the .cwp file as well as the .mid file that is generated by an export.

OFAWtest.cwp OFAWtest.mid

On 4/3/2021 at 4:22 PM, Noel Borthwick said:

@sreams please report this to the Video card vendor and also to Microsoft via the feedback channel. @Pete Brown may be able to follow up after you log a feedback report on Microsoft. This is likely on the driver vendor to fix it however.

Update on this... I contacted AMD support and they have been of little help. I've received two responses from them which suggest they aren't really reading what I've written them - directing me to use manufacturer supplied drivers when I've been very clear (twice) that I have been, and that the issue is the same using drivers from both ASUS and AMD.

ASUS, on the other hand, has been more responsive. They've requested a video showing the problem. Thought I'd post it here as well so you guys can see what is happening:

On 4/11/2021 at 6:04 AM, Noel Borthwick said:

In any discussion about usability you have to look at different user personas. Power users or experienced DAW users are always going to want more visible and newcomers who don’t necessarily have a lot of experience will get overwhelmed with showing all controls.

As someone who sets up systems for users of varying experience levels... I can't say that I agree. Hiding the mix controls in the Track View means new users are now hunting for the faders that go with the clips they are working with. When the Fader/Pan/Mute/Solo/RecordEnable are right there on the screen next to the data (and not buried in lower control rows so that they disappear when tracks are minimized), it is a lot easier for me to get new users started. With the Track Inspector, I need to teach them to click on a track first in order to make its fader visible. Hiding controls encourages users to open multiple views at once to do basic things like mixing and editing. This can become cumbersome, especially on systems with 1080p displays, and especially when users start getting into things that actually require other views to be opened.

As for me personally... I find that the only time I actually need the Console View (because the Track View is so capable and intuitive once its functionality is enabled) is when I need to copy a track EQ from one track to another. I think that may be the only thing that can't be done without the Console View. Otherwise, I keep it closed so that I have a lot more screen-space for views I really need.

3 hours ago, msmcleod said:

This used to annoy me when I first moved from SONAR 8.5 to X1... I was always wondering where half the controls were.

I'm so used to using the track inspector nowadays (which shows all of the controls), I just go with the default layout in the Track View.

It does depend on your workflow though. I use a control surface, so it doesn't bother me that I can't access those controls within the Track View. For those that don't have a control surface, and want to quickly adjust volume/pan though... I can definitely see that having the volume/pan widgets there makes sense.

Yeah... for me, the issue with the Track Inspector is that I can only see one track's fader at a time. No relative fader positions are shown. I will often select three or four tracks at a time and use Ctrl to move their faders together. Not having visual feedback on all of the faders that are being moved is not good.  The Inspector also requires an extra click while mixing (must select the track before moving its fader). When adjusting the mix for a drum kit with 10-12 tracks, this is a big slowdown. Select track... move fader... select track... move fader... etc.

I think the Track Inspector and Console View are invaluable tools, but not at the expense of what I find to be the most fluid and intuitive way to edit/mix: the Track View.

One thing I've always thought makes Cakewalk more difficult to use out of the box for some is the default preference where the Track View shows only some controls. The first thing I do with any system I setup is save the normal template with Track Controls set to "All". I then move the MSR/Volume/Pan controls to the top of each type of track so that they are all accessible even when tracks are minimized.

Once you do that, almost everything is right there in front of you to edit and mix, even with the Track Inspector and Console View closed. I also prefer it because it means the fader/pan/mute/etc for a given set of clips is always directly to the left of those clips. No need to hunt for the faders for tracks you've been editing or automating. They are always visually in-line with the data.

I like using the Input Gain control on the Master bus. This allows for the output of any mastering dynamics plugin to still deliver the same output level. As an example... using Waves L2 and setting the Out Ceiling to -1db... your peaks will still be limited to -1db.

5 hours ago, GreenLight said:

I just lost a couple of hours to this weird +3 dB mono file issue when bouncing mono tracks... 😒

In the Cakewalk documentation quoted above, they mention "data interleave".  What is that? Is it something else than the track interleave?

My files are mono, my track interleaves are mono and my bounce to track channel format is set to mono... and still I get an unwanted +3dB boost... 🙄 I think Cakewalk doesn't really like working with mono files?

Yes... but if your mono tracks with mono interleave are routed to a bus, that bus is stereo (unless you also changed the bus interleave). So the routing is from mono to stereo... and then the L/R from the bus output is merged/summed to mono again for the export.

On 4/3/2021 at 4:22 PM, Noel Borthwick said:

@sreams please report this to the Video card vendor and also to Microsoft via the feedback channel. @Pete Brown may be able to follow up after you log a feedback report on Microsoft. This is likely on the driver vendor to fix it however.

Update: Haven't seen any responses to my bug reports, but I did gather a bit more info on the issue.

I am seeing the same DPC latency spikes when moving the mouse cursor into the text entry field in Notepad.

Also... the problem goes away completely after switching from the Radeon driver to the Microsoft Basic Display Adapter driver. It has it's own issues, however (consistently high DPC execution time in wdf01000.sys)... but the problem with text fields is gone. So this really seems to be an issue with the AMD Radeon driver.

I really want to use this notebook for live performance, so hoping I can make some headway with AMD.

6 hours ago, dantarbill said:

BounceBufSizeMsec is already maxed at 250.

I don't know that there's a particular "bad actor" in the plugin chain.  The only thing was a 32 bit version of Voxengo's legacy Marquis compressor through jBridge...which gave me about 30% better speed.  Pulling everything gave me a lot better speed, but then...what's the point?

What kind of core usage percentage should I accept and be happy with?

 

I'd suggest doing as Noel suggested and disabling that plugin to see if it solves the issue. Maybe also try another non-legacy compressor just as a test to see if the problem persists. If it turns out to be caused by a legacy plugin, you likely just have to be happy with however it is acting.

3 hours ago, Noel Borthwick said:

@sreams please report this to the Video card vendor and also to Microsoft via the feedback channel. @Pete Brown may be able to follow up after you log a feedback report on Microsoft. This is likely on the driver vendor to fix it however.

Okay. Bug report sent to AMD (using the bug report tool in the Radeon software) and to the Microsoft feedback channel.

On 3/26/2021 at 11:14 AM, reginaldStjohn said:

It could be a video driver issue. I had one with an NVidia card I could never get sorted out and had to replace the video card. If you run the program LatencyMon it should give you some hits ant what is causing the glitches.

https://www.resplendence.com/latencymon

Good call. After moving the mouse over track name fields, LatencyMon immediately shows a nearly 1000 microsecond spike in dxgkrnl.sys.

Otherwise, I'm seeing maximum DPC routine execution times of about 100 microseconds.

Update: Also seeing the same spike when moving the mouse over the numerical text-entry fields above the faders in my Behringer X Air Edit software (with Cakewalk closed). Anybody have a modern Radeon graphics card or integrated Radeon graphics and willing to test for similar DPC latency behavior?

On 3/27/2021 at 8:16 AM, JonD said:

Have you tried switching to the other graphics option to see if you get the same behavior?

Yes, I've tried this. Switching graphics makes no difference. That said... this laptop uses Nvidia Optimus, which means all graphics are routed through the integrated CPU graphics chip.