Rick Lang

Thanks for your replies. It really was not a matter of any workarounds or using Audiosnap following project tempo since I have tried that a good while ago. I have no intention of detecting transients and marking 50 tracks with heavy distorted guitars playing progressive rock in 15/16. They will be off before the first bar. And it should as noted only be a temporary non-destructive thing for recording, then changing back (in this case anyway). I think it's safe to say that CW does not have anything similar as of yet, which is why I posted this in the feedback loop section.

Used SONAR/Cakewalk for 20 years. Recording SD3 (and every other drum sampler) via my e-kit on commercial releases. At times the tempos are unbearable though, so just as REAPER has it's "Varispeed rate" function, to use if I need to record some (too) fast passages in 190 BPM, I was hoping that Cakewalk would consider developing something similar. Meaning that I can slow down or speed up the playback/recording playback of the project seamlessly in it's entirety (all audio and MIDI tracks equally of course) with the twist of a button.

Just for the fun of it, I am thinking of mirroring my mix in CW in Reaper. It will take a while with all the plug in parameters, routing and gain staging. Not the mention the automation ... Just to see if the rendering itself will be clean. Currently 166 plugins in this project. 8 of them are guitar/bass amps. 6 of them are reverbs/delays. The rest various EQ:s, saturation plugs and FET/Vari-MU/VCA compressors on track and buss level. I might get back later.

Yes, I have already been on Reaper since 4.00, but SONAR has been my main DAW sine -99. Merely since Reaper has not implemented proper drum notation as per 2022. Again, this is not an issue with playback buffers and recording. The files are always stellar. This is bounce related with completely random placement. Feel free to glance through my reply to Jeremy above.

Hello Jeremy. This is not an issue during mixing/mastering. This is only during export, when AI is not in the equation. And always completely random in one or two spots. I have however fiddled with the export buffer size from 40 to 500 ms, w/o any particular difference. It could however be related to reverb tails from one of the many Altiverb or Bricasti emulations I have on my buses in this particular project, that the aud.ini file could possibly remedy. The Neural DSP amps are fine. A few years ago someone suggested ghost automation lanes still read by active tracks, which also seems feasible.

I have the exact same issue as you Colin, and have had for quite some time. I also saw the same thing happening Terry in this thread from early 2021. As stated, completely dumbfounded why this is happening during export, listening back to the WAV (44/24). I have a fairly well built i7 computer with 32 GB RAM, all SSD equipped, RME UCX interface with the latest drivers, no internet, AV or any other processes disturbing things. Now trying to export a finished, mixed and mastered progrock-tune only containing roughly 75 tracks, and the computer/RAM or HD isn't sweating. Chirps still random on the export. I will probably go REAPER from now on I'm afraid. After 20 years.

No, but I figured they might possibly need to be unlocked before changing track visibility in Track Manager. But that does not help either I'm afraid.

Agreed. I always click OK. Regardless if I open Track Manager via shortcut H or via submenu under different views. No difference.

Annoying bug #2: I have addressed this a long while ago, but seemingly it hasn't changed. When working on projects with a fairly reasonable track count (50-80) and I have a bunch of tracks archived I need to get them out of sight. In mixer/console mode this NEVER works. Opening Track Manager and unchecking said tracks they disappear, only to reappear when I change view and go back again. Same thing regardless if opening from shortcut or under Track>Track Manager. 1) No, I don't have any workspaces assigned. 2) No, my screensets are not locked so track (in)visibility should stick. It doesn't however.

I have had (actually have) the exact same issue as you Terry. Which is annoying since it has evolved recently and sporcadically during the past two years. Powerful computer. RME UCX interface with the latest drivers. CPU only sweats around 20% for 70-80 tracks, 10 buses with some 30-40 plugins, and NOT a buffer issue (never has been). The exported (!) file tends to have one or two chirp regardless of dither settings, exporting in realtime, having largest possible bounce buffer size and so on. I mostly think it's could be due to some plugin, but all are green lighted. Suggestions from others tells me it could also be ghost automation lanes (or active ones) with lots of movement. Very annoying since not an issue with, for example, REAPER.

Of course there are. I have a bunch of them. There are also plenty of third party VSTs that act as a gain knob, but I would not suggest CW to remove that feature.

Another Cakewalk feature suggestion: Similar to Logic functionality, it would be nice if the fade out curve could be adjusted (right clicked) to also include a tape stop. As illustrated: https://www.youtube.com/watch?v=_MJ_0tXpns0

As I wrote to Wookie, end client's/songwriters request. But to elaborate: the vocals are three pieces. Verse is run through a bus with an amplifier, since it should sound crushed and "quasi-radio-like" (or buried if you like). Prechorus is supposed to be clean. Chorus is the third pieces, also run via the same bitcrusher/amp, but less so than verse.

This time a modded Steve Vai combo from THU (Overloud). Dubbed multiple times of course. Previous releases were ENGL Fireball from Amplitube: https://open.spotify.com/track/4cse0HyUUq6dBWVBPF4b7l?si=vZQYjAW7SkiefWUQgALqAw

Yep. The client (or songwriter) is always right (or not). I wanted the lead vox a bit higher actually, but had to keep them here due to artistic reasons. LUFS around -12 btw. Thanks for input.

As per title. Latest release. Drums, recording and mixing in CWbBL by yours truly. You might recognize the guitarist from the old Japan tours with Majestic and Time Requiem (with Wildoer (James La Brie) and Lövgren (Meshuggah)). This is a different constellation though.

Hi Blades, Thanks for input. Basically I agree with everything you say. I created a ticket earlier over at Presonus, linking to my posts on their own forum and in the Presonus Faderport group on FB. Merely to make them aware of it (if they weren't already), and to take it into consideration. But as you say, this is more of a SONAR/CW problem, since they don't have the same fader resolution as the FP, or standard. If CWbBL would address this in a future update the problem would probably go away. Worth noting is that this wasn't that much of an issue in Reaper – probably due to the fact that they move all the way up to +12dB.

I believe I have solved it. I did a new factory reset to firmware 3.21 from June 2019 and tried. Seemingly no twitching. I then uninstalled everything. Including Universal Control software (which really wasn't necessary). Went through the process anew and updated to firmware 3.44. Calibrated, rebooted etc. and so on. Tried in Cakewalk/SONAR and Reaper. The twitching was back. Did a new factory reset to 3.21. Recalibrated. Rebooted. Twitching gone. So the solution is to NOT update to firmware v. 3.44, and if you have: do a factory reset. So to elaborate: this firmware most likely addresses the "need" to have virtual faders match the fader resolution on the Faderport. The thing is that Cakewalk/SONAR does not have the same fader resolution (nor can you change it). That one is from infinity to +6dB, while FP is from infinity to +10 dB. So if you are somewhere in the middle with the faders running the newest firmware, you might be ok. But way down below -25 or so on the FP the virtual fader hasn't reached that far due to resolution – which is why it jumps back up. Same thing if you go above 0 dB. So basically you will use 3.44 and see that FP faders match the virtual faders, but accept twitching. Or revert back to old firmware, get rid of twitching, but then realize that the difference in fader resolution means that -20 in your DAW might be -24 on your FP fader. And so on. Thanks all for input!

Update: Here's a video explaining what I mean - >

I see. It might as well be that this unit behaves this way, so would not like to think it's defective in any way.

Thanks for swift input. You replaced your FP? So it was an issue before? Surely should not be with the new FP v2 and latest firmware of 3.44? Asked the same question over at Presonus. Waiting for feedback.

Resurrecting an old thread. Long time SONAR/Cakewalk user here (+20 years). Recently got my hands on a Faderport 8 (Presonus) and quite happy with it. Read the manual. Obviously understand I cannot map everything, but to a reasonable amount at least. The main issue (which seemingly is what other Presonus users also have noticed overall) is the fader calibration. Moving a fader on the Faderport it moves on respective channel in CW, but upon releasing the physical fader it twitches and changes it's position up or down to match the resolution on the virtual fader. So technically they are both correct, but the problem is obviously that the resolutions don't match on the FP vs CW. The itch is merely the small adjustment the fader has to do when letting go of it, hopping up to the correct corresponding number on the FP scale to be aligned with what CW:s fader is reporting. Now question: You can change the audio meter resolution under console view for example. But I don't see an option for changing the actual dB resolution next to the faders. In my case I would like it to be from infinity > +10 dB. Right now we are at standard infinity > +6 dB. Supposedly there never were such an option? Anyone else experiencing/experienced this fader twitching? To be expected when using FP8 with CW and regular MCU protocol?

I think I have solved it. This must definitely be a bug. I have to open Track Manager in Console view via the "Strips" menu. Opening the very same Track Manager via the regular shortcut "H" shows the track as being invisible (when it is not), while opening Track Manager via Console > Menu > Strips displays the same track as being visible.

Thanks for input. I believe my second and third sentence was clear on this topic. I always have them unlocked, then make changes, then lock them. Going back to track view where everything is good, and then back to console/mixer view then still has this issue of displaying a previously hidden track – which is also hidden in track manager, meaning I have to open TM, verify it is hidden (i.e. not changing anything) and then close it. The track disappears.: It always is. No change.

Hi Rick, Thanks for asking. I believe this is an issue you should escalate in order for it to be fixed in the next update.