Freeze/export causes envelopes to lag - bug?

Hi all-

I've searched the forums and KB and can't find any mention of this issue, so posting new thread.

I have 2 tracks, a MIDI track and an audio track.  The MIDI track has a very active envelope on CC1, and is controlling a Pentagon I soft synth.  The Pentagon output is going to the audio track.  I'm using Pentagon Bank A, Patch 94 "Energy Source", which has a filter controlled by the mod wheel.

On normal playback, the sound is modified correctly by the envelope.  However, if I export the project audio or even just freeze the track, the resulting rendering does not have the correct enveloping.  In general, the envelope processing seems to lag behind the audio.  Only on a freeze or export.  Again, normal playback is fine.

I've tried changing my ASIO latency to ridiculously high settings.  I set BounceBufSizeMsec to its max 350 value.  No effect.  I cut my project down to just a few measures in the two tracks which exhibit this problem... still there.  Tried changing the synth to a Dimension Pro patch ("Haunter")... exactly the same problem!

I have a CWB file with the frozen synth, which demonstrates the problem.  Really seems like a bug, but maybe I'm doing something wrong???

This is preventing me from exporting a good/correct rendering of my music.  I'll probably call support Monday on this.

Hi Wavez,

are you running 64 or 32 bit Sonar ?.
What are your system specs ?.

If it plays back normally, try a real time bounce to audio and see if it's the same.

It's interesting that DimPro you get the same results.
I haven't experienced any envelope lags like you're describing, so it wouldn't appear to be a universal bug.

Try the real time bounce and let us know how you go.

Cheers - Cliff

Windows XP Pro SP3, 32-bit, Intel Core 2 Duo (dual core), 1.86 GHz, 2Gb RAM, lotsa disk space.  Yes, it's kinda an old computer (4 years).  Also have a Midisport 2x2, Korg padKontrol, and Roland Fantom Xa attached.  E-MU 1212 PCI sound card.  I've had Sonar X1 installed for about 3 weeks, and just started seeing this problem a few days ago... but it's also the first time I tried to export this project with these envelopes.

And I'm using X1c Producer.

Kallie - sorry, not sure what you mean by "normal bouncing".  I see this problem when freezing the track, and when exporting.  In my second post, I "bounce" the signal through my sound card which has the capability to route signals through various ASIO inputs/outputs.  So the Master bus in SONAR runs out to the sound card, and I re-route the signal back to an ASIO input which I have another track in SONAR record from.  There is no lag when I do this.
Cliffr-  Now this is weird.  When I export real-time (non fast bounce), whether audible or not, the file renders without ANY controller automation applied!  For both Dimension Pro and Pentagon!

What is going on???

Thanks,
-David-

Wavez


Kallie - sorry, not sure what you mean by "normal bouncing".  I see this problem when freezing the track, and when exporting.  In my second post, I "bounce" the signal through my sound card which has the capability to route signals through various ASIO inputs/outputs.  What is going on???

Thanks,
-David-

Bouncing to track is the normal way to permanently convert MIDI to audio inside the project. Freezing is what you use when you think it might be temporary and you intend to change the MIDI later (you can use it for permanent, too, of course).

For MIDI rendering issues increasing audio latency is unlikely to help. Try reducing your audio latency to about 5-10 msec and increasing the MIDI buffer size to about 1024 and see if that changes the result.

Another wild idea - has Fast Mixdown(or what ever it's called) anything to do with it?

In export you can try and uncheck the Fast option.

I don't know if freeze used that-but it might and then make sense.

What you use in project may not work well with Fast setting.

I remember some fragments of help file explanations whether to wait a certain time for plugins or not - something like that.

I checked this out, and cannot reproduce a problem, either, I used Pentagon in SONAR x1c x64 with the same patch (after lowering the oscillator levels - ouch!). After freezing the track with modulation automaten, and confirming it sounded with, I replicated the track using controller messages instead of automation, and confirmed that it produce identical ouput (the two tracks null when bounced separately. I also tried it with a PDC plug inserted on one of the tracks, and they still bounced in sync.

As for the question about DXis in x64, they just have to be ported, and many have, including Pentagon.

So it's not a general bug, and it's not a Pentagon problem per se. The question is what's going on in the OP's environment or the project that's that causing a problem.

David, how big is the lag? I've experienced a problem in that past where having a 1-measure count-in enabled would cause MIDI automation to start a measure late on playback. I don't remembrer seeing that it was formally fixed, but I can't reproduce it now.

Also, there is a problem with MIDI automation in X1c (and maybe earlier?) that it just has no effect at all when first created, and you have to right-click the envelope and re-assign it to the controller (I had to do it in this case). I'm wondering if maybe your modulation envelope has just stopped working altogether when freezing, and you're interpreting it as a lag...?

 

 

Brundlefly has previously reported that setting this to a nonzero value can cause audio from certain 32-bit bitbridged synths to become shifted.

Yes, but this shouldn't affect ported DXis which don't use Bitbridge. In fact, I have my BounceBufSizeMsec set at 20, now, and use Jbridge to avoid the Bitbridge issue. But it would be next to impossible to hear such a small error in envelope timing, unless maybe there's a big jump in the envelope getting misplaced.


The OP reported trying values as high as 350, and not hearing a difference one way or the other, so that's apparently not an issue, though Noel did recommend trying a smaller buffer.


I thought he had also tried increasing the MIDI Prepare Using buffer, but on re-reading, apparently not. Noel also recommended trying that.

Just tried it with a single sustained note - same problem... but noticed that the amount of lag increases over time.  The first jumps in the envelope seem to happen pretty close to the correct time, but the rest are delayed by successively larger amounts.  It's as if the code which computes the actual time to apply the shape data is incorrectly accumulating an amount during a fast bounce that it isn't during normal playback.  (Sorry, my day job as a software architect makes me talk like that!)

Sounds like you've been everywhere but the sweet spot for MIDI Prepare Using which is about 300-700ms. If you started at 64, that's almost certainly the issue. X1 defaults to 250 which is too low for some systems. Earlier versions defaulted to 500 which works well for most. I usually recommend starting there, working up in increments of 100, and stopping at 1000 if that doesn't resolve the issue (most commonly dropped MIDI notes)

So you have tried bouncing with "fast bounce" OFF, have you? You seem to totally ignore the "bounce" function, which at least gives you some chances to adjust the settings.
My guess is that "freeze" function always uses fast bounce, as "lfm" suggested, but I'm not 100% sure.
There are lots of cases when fast bounce does not work but normal bounce does.

I'm having to bounce the song through my sound card and record it back to a new audio track in order to get a mixdown audio file.  Sucks, and cludgey, but workable... for now.

Don't forget to take a couple milliseconds out of your latency compensation to account for the loopback not going through D/A/D conversion. In my 1820m setup, the normal manual offset for sample-accurate compensation of an analog loopback is +4 (at 48kHz), but for digital loopback, it needs to be -84.


Wish I had more suggestions for you on how to resolve this, but it's pretty strange. I'm thinking it must be due to some unusual combination of system and project configuration settings. The only other possibility that occurs to me is that there have been some issues with Sandybridge CPUs, that were presumably addressed in X1c, but might persist in other areas. If you're running a  processor from the Sandybridge family, you might want to have Cakewalk Support look into that possibility.




Incidentally, the MIDI-automation-not-processed-during-realtime-bounce is a longstanding bug.

brundlefly

Don't forget to take a couple milliseconds out of your latency compensation to account for the loopback not going through D/A/D conversion. In my 1820m setup, the normal manual offset for sample-accurate compensation of an analog loopback is +4 (at 48kHz), but for digital loopback, it needs to be -84.

Not sure I get what you're saying, but in case I am ... I'm routing the Master bus to a strip on the 1212, in which I have a send back to another ASIO input.  I have another audio track in Sonar recording from that input.  Sure, the recorded audio is off from the source material, but that doesn't matter since all I'm using this for is to record the output of the Master track anyway - basically a hacked mixdown.  I don't need to line the bounced signal up with anything, so I don't think I have to adjust for this latency.

I don't know why that would matter, but these are DX synths we're talking about and the problem is almost certainly within the synths themselves (as opposed to SONAR automation).

OP said he sees the same problem with Dim Pro. I presume he's using the VSTi version of Dim Pro, but maybe not.

I'm using whatever version of DP comes OOTB with Sonar X1.

Definitely VSTi, then.