Strange track-related anomolies

[Dono Lee]

Hello folks,

Long time Sonar user, infrequent poster here. I am experiencing several strange issues that I have yet to find an answer for. First of all, I must say that overall my experience is that Cakewalk By Bandlab is pretty stable, despite the issues I am posting about.

(1) I am wondering what "setting" controls the the volume of a Loop as it being auditioned in the Media Browser? When auditioning Drums on Demand loops, the loops sound great, but the volume is VERY loud and does not appear to be controlled by the MOTU 1248. However, when importing the drum loop into a track, the overall loop volume decreases dramatically, but at least at this point the loop's volume can be controlled. And, I must say, the "fidelity" (for lack of better word) of the loop suffers as well. BTW, I believe I confirmed that there were no FX anywhere that would affect the volume of fidelity of the drum loop. There is just a big difference in how the drum loop "sounds" in the Media Browser vs. after being imported into a session.

Any thoughts?

(2) Over the past few years I have experienced that a Track, be it regular track, AUX track, or BUSS, will work correctly for a period of time before going "bad", meaning that the track ceases to process whatever signal is sent to it. All tracks around it work, all routing is confirmed as correct, the track just ceases to work. So far, the remedy is just to create another track, configure as needed, move the .wav if necessary, and it works again. Takes all of 15 seconds to fix, but the mystery intrigues me - why would this happen?

Has anyone else seen this behavior? Any ideas? I appreciate any response.

Thanks!

Dono

[msmcleod]

2 hours ago, Dono Lee said:

(1) I am wondering what "setting" controls the the volume of a Loop as it being auditioned in the Media Browser? When auditioning Drums on Demand loops, the loops sound great, but the volume is VERY loud and does not appear to be controlled by the MOTU 1248. However, when importing the drum loop into a track, the overall loop volume decreases dramatically, but at least at this point the loop's volume can be controlled. And, I must say, the "fidelity" (for lack of better word) of the loop suffers as well. BTW, I believe I confirmed that there were no FX anywhere that would affect the volume of fidelity of the drum loop. There is just a big difference in how the drum loop "sounds" in the Media Browser vs. after being imported into a session.

Any thoughts?

Any media auditioned via the media browser is routed directly through the master bus. When you import it, it's on a track who's fader is likely less than full.

As far as fidelity is concerned, it's likely the sample rate of the media file is different from your project. When the loop is imported, it's converted "quickly" to the sample rate of your project. If you bounce to clip(s), it should render it high quality.

2 hours ago, Dono Lee said:

(2) Over the past few years I have experienced that a Track, be it regular track, AUX track, or BUSS, will work correctly for a period of time before going "bad", meaning that the track ceases to process whatever signal is sent to it. All tracks around it work, all routing is confirmed as correct, the track just ceases to work. So far, the remedy is just to create another track, configure as needed, move the .wav if necessary, and it works again. Takes all of 15 seconds to fix, but the mystery intrigues me - why would this happen?

After you edit an audio clip, you should always "bounce to clip(s)", other wise the edits are rendered in a "quick" manner. The quick method allows you to work quickly, but the quality is still at preview quality. Bounce to clip(s) will render it properly, but takes a few seconds to complete.

Note: you can adjust the quality of the "online" (quick) render and "offline" (bounce to clip(s)) in preferences:

Edited April 15, 2019 by msmcleod

[scook]

22 minutes ago, msmcleod said:

Any media auditioned via the media browser is routed directly through the master bus.

Not necessarily., I know at least some of the project templates bundled with CbB route audio preview to a Preview bus.

Audio and MIDI preview assignments are made using the browser menu on the media browser tab, B on the image below

[Grem]

Yep, most of my browser loops go through the Preview buss.

 

With midi clips, there is also an option to route them to whatever synth you have in the project.

 

I have had a trk quit responding to commands. I have reported it, but I can never get steps to reproduce it, which makes it difficult to fix. If you ever get some reproducible steps, report it!! They will fix it if we could figure it out. : )

 

And the workaround you use is what I found works best. Just give it up and move on!!

[John Vere]

Just a note about the sound quality issue. It is a well know fact that everything will be precieved as sounding better if the volume is turned up.  To a point.  

[Craig Anderton]

Sound quality also depends on whether you're monitoring the loop at the host tempo, compared to the acidized sound that conforms to tempo.

[Dono Lee]

Thanks for the replies! IDK, the MOTU 1248 is new, I just tweaked a bit and the #1 issue was gone. I think I chalk this up to "DOH!"

I am ecstatic that at least SOMEONE has seen the #2 issue before ? Thanks for sharing, Grem!

Thanks everyone.

Dono

[reginaldStjohn]

2 hours ago, Dono Lee said:

Thanks for the replies! IDK, the MOTU 1248 is new, I just tweaked a bit and the #1 issue was gone. I think I chalk this up to "DOH!"

I am ecstatic that at least SOMEONE has seen the #2 issue before ? Thanks for sharing, Grem!

Thanks everyone.

Dono

I have had times where a track appears to stop working.  In my particular case it always had to do with a pro channel module. If I turned off the pro-channel my track would sound again.  If I started deleting modules until it sounded again it would usually come down to the console emulation modules or once it was the concrete limiter.  Just a thought.

[Starship Krupa]

I haven't seen the "track done gone bad" issue in a while, but I do know that I find it necessary to occasionally "sacrifice a chicken" to a MIDI track to get it to work again. I won't go into it in full detail, but it's a set of seemingly random flailing steps that I take that make the track start working again. If all else fails, I do what you do and just duplicate the data.

One chicken sacrifice is to close the project and reload it, another is to exit Cakewalk, start it again, and reload the project, etc. It might be to assign a MIDI channel where none was previously necessary. Or to set it to "Omni."

My only explanation/theory is that Baron Samedi demands a tribute in order to deliver my softsynths from the land of the dead back to the land of the living.

[Grem]

On 4/16/2019 at 2:15 PM, reginaldStjohn said:

it always had to do with a pro channel module. If I turned off the pro-channel my track would sound again.  If I started deleting modules until it sounded again it would usually come down to the console emulation modules or once it was the concrete limiter.  Just a thought.

 

Never thought of this. Next time I will give this a try. Thanks for suggestion.

[John Vere]

On ‎4‎/‎16‎/‎2019 at 12:15 PM, reginaldStjohn said:

I have had times where a track appears to stop working.  In my particular case it always had to do with a pro channel module. If I turned off the pro-channel my track would sound again.  If I started deleting modules until it sounded again it would usually come down to the console emulation modules or once it was the concrete limiter.  Just a thought.

I have had many projects that hung up on opening right when the scan said Console Emulation. It was only present as a default in some old template I had used and it was turned off.  I make sure it is not present in any of my projects and since have never had a stalled scan.

I tried messing with it a few times and it seems to do nothing other than make things distorted if you turn it up, seems counter productive to good sound quality.