SETTINGS - WAVEFORM - UNTICK draw waveforms while recording - see if that helps -
Dr J
Version and % and version 6 do not work well when installed on the same computer.
Just got the word from Flavio.
Geez… there’s a nasty echo in here or sumthin’… 
D
Some things are worth repeating I reckon.
I reckon…
D
PS Probably one of then interweb “thangs”? I occasionally have weird double postings show up. Which is a bad thing since nobody wanted to read it the first time anyway! 
AND I am having some problems posting correctly. Actually the whole thing is giving me a head ache. anyhow, you got the message about the versions?
Yep
Yep
Yep
Yep
Yep
Yep
Yep
Yep
Yep
Yep
now THAT is a nice echo.
Can v5 and v6 co-exist on the same DAW? 
Quote: (phoo @ Jul. 14 2008, 2:31 PM)
Yep
Yep
Yep
Yep
Yep
Yep
Yep
Yep
Yep
Yep
ROFL...
It's a good thing I like hanging out wif kwazy peeples... I fit right in!
Quote:
Can v5 and v6 co-exist on the same DAW?
I dunno Yaz - I never look back when I download.
n-Track Studio version 6.0 Beta 1 Build 2336 Released - Monday, July 14, 2008 4:53:00 PM EDT, 10 minutes ago
Fixed sporadic crashes moving volume sliders during playback
Fixed crash enabling and disabling the Live button during playback
uhhhh… 
I did untick the draw waveform settings to no avail…if you read my post you would have picked that up…all of these bugs I listed I tried various work arounds…the late and early .wavs (regardless of any setting, buffering, driver changes…and there were about 100, plus reinstalls) and horrible crashing in record mode make it unusable on my machine…it was a brand new machine that I installed v.6 on so there was no version 5…after v. 6 became unusable I rolled back to version 3.3, loaded my packed song files and started comparing…on my machine 3.3 is kicking v6 a$$ in terms of speed, stability, cpu usage and recording files that are in synch with the project…I am not giving up on 6…I know this is just a beta but if things do not improve as we roll along I will stick with 3.3…the only real feature I have been holding out for was the ability to build separate monitor mixes and assign them to hardware outputs independent of the main out (like a real console)…I would pay double for a program that let me simply record, mix, use dx and vst’s, assign/route sounds like a nice console, cut and paste and use automation with a nice, clean interface like v.3…all the rest of the stuff is just cpu eating/Windows crashing crapola to me anyway…Like Tom S. I point mics at instruments and people, record and then mix…I guess that makes me…a grouchy old semi- Luddite man
Cheers,
Ray
Flavio has finally fixed the envelope node pick up when at -inf. in Build 2336. Man they move so nice now - no more hunt peck and miss!
Thanx Flavio - that’s been a major gripe for some for a while. Nice! Along with the movable draw downs - primo track node editing!
Build 2336 is working for me! So far no issues and the improvements are great! 
Good news! I likes good news.
Well I have news as well. Mixed news though…
I loaded up 2336 on my “Audio Only” setup this evening to do some testing. Since I’ve had to “jump ship” I wanted to test V6 against ‘R’ V2.4. (the latest version)
To make sure I had an apples to apples thing going on, I used the same plugins with identical settings in both DAW’s, the Kaerjhaus (sp?) Classic series.
The good news is, V6 WILL play my torture project so there is a definite improvement over post .NET V4 and V5! The downside is I have to run at 50ms latency or I get clicks, pops and farts. I spent a good ten minutes futzing around with preload and disk buffers to no avail. I don’t think this is a throughput issue anyway. (Read on…) CPU use according to n’s meter set to absolute CPU ran ~50-55% while Windows Task Manager indicated 60-62%.
The same project ran in ‘R’ at 10ms latency which is really good. The CPU use was actually a fuzz HIGHER in ‘R’ but playback was flawless and GUI responsiveness was smooth and slick.
So here’s my theory, (groan… yeah I hear you) there is something amiss in n-Tracks FX processing. I believe this for the above reasons AND the following as well. I’d like for some of you chaps to try this experiment too if you would be so kind?
1) Load up a .wav file recorded at say 24/44.1. (or whatever… mine are 24/44.1)
2) Now drop an effect or two on the track effect insert.
3) First, render the entire track putting a _1 at the end of the filename.
4) Render it AGAIN with a _2 appended. (eg Mywave_2.wav)
5) Examine the properties of each file by right-clicking and choosing “Properties” in Windows Explorer.
6) Are the file lengths identical? Can you load both in n-Track, flip the phase of one and they NULL against each other?
Do the same experiment only this time, type in a value in the render dialog for the START and END of the file to be rendered.
I tried this a BUNCHA times. Sometimes they are perfect. Most times though, they are way out of whack. Thus my theory that somewhere in the FX processing, something is a bit screwy. I know offline render and real-time playback are not exactly the same thing but I still feel something is amiss. Disk I/O doesn’t seem to be a problem, I can disable the FX and run V6 down to 10ms no problem. Turn the FX back on and it’s glitch city.
Now… the above may not be at all important to you! If you can record, effect, edit and mix your songs at higher latencies then you shouldn’t be at all concerned with this unless the weird, differing render lengths thing throws you a curve ball… it did me! I imported a rendered file back into n-Track hit PLAY and went “WHOA! Waa-waa-what happened?” That’s when I put the detectives hat on… Anyway, if it doesn’t affect the way you work, don’t think another second about it. Still, I hope Flavio reads this and can duplicate the problem, track it down and fix it. Even if it is writing me back and saying "Hey Doofus! Ya’ got yer cap on backerds… flip it around an n will work!"
All in all my evening of DAW testing was pretty good. V6 is looking better. If we can just get a few of them darned old feature requests slipped in there… (that reminds me… I was supposed to post the consolidated list today as a subtle hint) Maybe I’ll remember tomorrow…
Have a good 'un gents. I’m as tired as a mule after a hard day pulling stumps… OFF to bed…
D
Excellent (and very interesting) analysis D. I’ve always suspected there was something not right with the underlying processing engine. Pops and snorts have always been an issue for an project over 25 tracks. I just figured that my dual core machine just didn’t have what it took to process anything else - until this last weekend marathon recording session. One of the songs we did has 43 tracks - with fx. But it was done with Reaper. No hickups, pops, snorts or any latency that we could hear. It just blew me away. Nothing has changed with my DAW. So I am comparing apples to apples.
Another thing I realized after this weekend is that the input channel assignment in n-Track seems to be “bass ackwards”, when compared to Reaper. When you have 16 inputs n-Track seems far more error-proned in assigning inputs to tracks. It sure would be nice if n-Track would adopt the Reaper style of this necessary feature of any DAW.
If I can find some spare time, I’m going to try your experiment to see what shakes down.
Paul
Another thing I meant to try but ran out time, was trying playback of the “heavy” project with the WDM driver for my EMU1820M rather than the ASIO driver. I can’t imagine it being any different as ASIO is more optimized but hey… I recall doing that with V4/5 and having to use rather large buffers for smooth playback. Maybe V6 improves here? Still that doesn’t solve the problem of recording additional material while running FX/VSTi’s during playback. The high latency is a killer.
Just curious, Paul… what interface are you using?
D
I noticed the track rendering thing for years…I think a rendered track would be a little longer due to verb or delay decay etc…BUT, Shouldn’t they start in the same spot? When I reinsert a rendered file I end up cutting the begining and realigning the track…rendered without effects yields better results. I think it may have to do with the compensation for effect latency not being very good…I have noticed when tracks are off it is usually by the same amount as the effect latency…so I stopped using rendered tracks long ago…
Cheers,
Ray