ORIGINAL: pianodano
So what you're saying is there could be minute timing inaccuracies in the samples themslves ??

Well sure there could be, but that would equally be a bug in RealGuitar as anything else. But I actually doubt that is the problem. Presumably they would have made sure that the samples would all have their attack transients lined up so that they sound correct. If that were not the case, then when you play back your sequence before freezing it would not sound right either...the random sample selection would be causing time problems then too, if that were the case.

I am much more suspicious that the plugin is not handling midi timestamps correctly during freeze. Did you try both fast and slow freezing by the way? Do they also ship a VST version or only DX version? If so, did you try the VST version? You're the one that said that if you make the audio buffer smaller before doing a freeze it sounds better, right?

what if you do a real time bounce, will the result sound correct that way?

ORIGINAL: dstrenz
dewdman, thanks, and I like the new avatar. The old one looked kindof like a shady character. I'm still an old geezer.

This avatar is 10 years old. I'm getting to be an old geezer too.

The original version I have (1.5) was DXI only. IT required around 190 meg to laod up the stereo sample( I think). 2L runs as a VSTi and somehow only partially load the sample (again I think). Worked all weekend so I haven't had time to startup the stuff to even see which freeze method is being used. It would be the default I am sure, since I only installed 6.2 about a month ago and never had a reason to change anything in 3,4,5 or 6.

ORIGINAL: pianodano
I guess what I was trying to say is I can spend several hours tweaking a part to sound so good (to my ears). Freeze it and it can play ok for a few measures and suddenly for no apparent reason, start stuttering ever so slightly. After working on the part for so long, you would have heard the part so many times you know every nuance and easily recognize when something is amiss. It never seems to regain the timing again once the rendered tracked gets fouled up. As I said yesterday, I quit trying here and just put it on tape now. It's one of those time is of the essence things if you know what I mean.

Yea, a frozen track is "frozen". It will never change after that. The question is why the "stuttering" you mention is getting frozen in. When you say "stuttering" can you describe that a little better..you mean that it sounds like a guitarist with bad sense of rhythm? I'm really most suspicious that RealGuitar has bugs in how its handling midi timestamps, but there might be a way to work around it, try the fast and real time bounces. According to Noel, there are some issues with multi-processor machines sometimes. He says the work around is to do a real time bounce instead of fast bounce. I would try without even using "freeze" per say. Just hit record on the audio track and let it play until the end, capturing the audio performance on a track from your midi track...just like you would be doing if you were sending it to tape, but send it to an audio track instead. See if that works. I think that is more or less Noel's suggested work around for these kinds of plugin bugs.

Are you saying the 1.5 version is giving you the timing problems, the 2L version, or both?

Disk streaming is another area where its possible that if it can't keep up with the streaming there might be some timing glitches potentially I guess. If there is a way to turn off disk streaming, try to do so to see if that helps.

I am pretty convinced at this point that there is nothing wrong with Sonar, but apparently there are plenty of ways for plugin developers to screw things up.

Someone else reported issues with TTS, so its not unique to only RealGuitar..but perhaps some common traps that some plugin devs might fall into. On KVR they pointed out that the original SDK for DXi had a flawed example project that did not correctly check timestamps and its possible that some plugins out there were based on that flawed example. And guess what, the nature of that particular flaw is/was that if the audio buffer size is increased the jitter gets worse. Sound familiar? TTS is a prime candidate for this possibility since its a darn old DXi based synth from way back when DXi's first came out. It was probably created in japan by Roland and nobody's looked at it since, but I could be wrong.

However how many synths do you konw that would garantee that each time the produced audio output would ge exactly the same? Probably none.

Actually, I would expect most sample-based "synths" to play back the same thing every time. Likewise, most DSPs will run the same numbers the same way under the same conditions, so it's probbly more often the case than not that you get identical output form identical input. If a synth uses a heavy dose of modeling technology, maybe not, but I think the randomizing ones are the exception. That may be changing, though. I have to confess that my perspective is based more on older equipment.

Anyway, I just wanted to clarify that timing issues will usually be revealed by a cancellation test.

ORIGINAL: brundlefly
Actually, I would expect most sample-based "synths" to play back the same thing every time.

Unless its Real Guitar, which uses randomized sample alternation. ;) but yea, the cancelation test is an interesting one. I intend to run it on every single soft instrument I own. But if I don't get a perfect cancelation I can't jump to the conclusion immediately that the timing is off. MAYBE that's what it is...or maybe its just a really good synth that attempts to make every note sound a little different, which is not such a bad thing.

ORIGINAL: dewdman42

ORIGINAL: brundlefly
Actually, I would expect most sample-based "synths" to play back the same thing every time.

Unless its Real Guitar, which uses randomized sample alternation. ;) but yea, the cancelation test is an interesting one. I intend to run it on every single soft instrument I own. But if I don't get a perfect cancelation I can't jump to the conclusion immediately that the timing is off. MAYBE that's what it is...or maybe its just a really good synth that attempts to make every note sound a little different, which is not such a bad thing.

Yep, that is what's amazing to me and have I have understood this for several years. As far as I can see there is no way to really EVER nail down just what the heck the cause is or to even get 2 people to definitively agree what the problem is.

Danny,

I did a very quick retest with the audio metronome enabled. I don't have time tonight (or tomorrow) to try with audio tracks; sorry.

The audio metronome was set to play wave files (not MIDI note ons), on each beat (downbeat uses a different sound).

Here are the basic results, organized a bit differently.

1st column identifies the note (1st, 2nd, 4rd played...)
2nd column is the delta between note onset for Axiom track v. note onset for EMU track
3rd column is the delta between note onset for UM550 track v. note onset for EMU track

    Axiom   UM550
 
 1   0       0
 2   0       0
 3   0       2
 4   2       2
 5   2       0
 6   0       0
 7   2       0
 8   1       1
 9   2       2
 10  4       4
 11  0       2
 12  0       0
 13  4       4
 14  0       0
 15  2       2
 16  2       2
 17  0       0
 18  0       1
 

This time round, results were a bit different. The two USB interfaces did not always respond the same - sometimes the Axiom had jitter; sometime the UM550; sometimes both (and sometimes neither, of course). Also - sometimes the jitter was only 1 tick (0.5 milliseconds) - which surprises me; see earlier comment about 1 millisecond USB quantizing effect.

Max jitter was still about 2 milliseconds (4 ticks), relative to the EMU. And again, this is not a scientific test, and I wouldn't claim the results are terribly valid, or repeatable.

BTW - that seems like a pretty large MIDI setup to me. You have five different USB MIDI Interfaces! Plus a Firewire interface.
And the USB interfaces are made by several different companies (so, different drivers may be involved).
Could you remind me again of what problems you're running into, with that setup?

One thing you might try, is to plug four of the USB interfaces into a Belkin 'Tetrahub'. The Tetrahub is a USB 2.0 port -- that provides four completely independent, full-bandwidth USB 1.1 ports. That might get you more bandwidth per MIDI interface (because, if you have two USB interfaces plugged into a single 'root hub controller', they will normally share a single USB 1.1 channel. There are two USB ports per 'root hub controller', so it seems likely you're sharing bandwidth.) Anyway, the Tetrahub was about $40 when I bought one originally-- more recently, I got a travel version at a Bed, Bath and Beyond store for only about $20 - I think that was a GE unit, but it was also called a 'Tetrahub' - maybe a trademark ?

Good luck,

Jim

But if I don't get a perfect cancelation I can't jump to the conclusion immediately that the timing is off.

No, but it's a good starting point for eliminating synths that don't have an issue. If you do get a cancellation failure, you just zoom in and look at the waveform. It didn't take long to see what RealGuitar was doing.

ORIGINAL: brundlefly
No, but it's a good starting point for eliminating synths that don't have an issue. If you do get a cancellation failure, you just zoom in and look at the waveform. It didn't take long to see what RealGuitar was doing.

Definitely