Getting new computer, M-Audio says they will have 64 bit drivers for thier Delta cards out by Sept 1. Wondering if it will be time to bump up from 32 bit everything to 64. So…
Anyone running 64 bit “N” under Vista 64 bit? Likes, dislikes, problems, kudos? Any performance gains? I use Sound Forge Home Studio as my editor. Sony says it will run under Vista
64 bit but will not take full advantage of the 64 bit path. What external editor are you using with 64 bits?
Please share your experiences and thoughts…
Thanks,
Duff
Hi Duff, running Vista 64 bit machine here. I love it. The only draw back with n is the plug ins, not many 64 bit native VST’s out there. N doesn’t reconize most of my VST’s.
I’m running a HP machine with Intel Pentium Dual CPU E 2200@2.20GHz, 4 gigs of ram, 500 gig harddrive, GeForce 7100 graphics card, E-Mu 0404 soundcard.
Most recording proggies run in the x86 files smoothly including N 32bit. I’ve yet to bog this machine down with anything including excessive VST’s and VSTi’s.
It’s not on line so it’s been Optimized for DAW work. Firewall, defender, etc turned off.
Yaz
Yaz,
Thanks for the info…I gave up on plugins about a year ago and went back to hardware compression and effects on the front end, so that (right now) is not a concern.
My wifes new computer came with Vista 64 bit installed. She uses it for video & photo editing. After playing around on that thing for a while and running a couple of bench mark programs I was amazed a the performance under 64 bits.
Just wonder if I will see any gains in audio creation/editing by moving to 64 bit.
Thanks,
Duff
Quote: (duffman @ Jul. 23 2008, 7:38 AM)
Just wonder if I will see any gains in audio creation/editing by moving to 64 bit.
Oh YES!
I have Vista 64 at work (2.2ghz dual-core, 4g memory). I’m WAY MORE THAN HAPPY with it’s speed. It takes 10 minutes to do a particular task that it takes 40 minutes to do on a 3ghz 32 bit WinXp machine that has 2g memory. IT was not easy to get it up and running with all the tools I need for work, but I’m there finally.
As for audio? I haven’t done hardly anything on it yet, except edit some files and make sue it works as stereo using the REALLY
REALLLY REALLLLLYY CRAPPY onboard audio. At this point I want/need something/anything 5.1 and haven’t had much luck finding anything that will work under native 64 Vista. (I’ve seen some, but haven’t figured out what’s semi-OK and what’s crap).
All that said, I wonder about what we should expect when running a native 64 bit OS.
Here’s what I’d like: The 32 bit and 64 bit versions of n-Tracks will both install and can be used independently of each other.
The 64 bit version will run faster and should allow more tracks, etc. There will be much less overhead, making it better for recording new tracks.
On the other hand, there are few native 64 bit plug-ins. Mixing would be handled better in the 32 bit version of n-Tracks for this one reason alone. The down side is that because it will be running under WOW64 it will be a bit slower and won’t be able to handle as many tracks. Of course, handling a lot of tracks when recording is a bigger strain than handling just playback tracks.
(don’t get me started on the windows system naming conventions when running 32 bit apps on a 64 bit machine)
One more thought-feature request:
It may be impossible, but it sure would be nice if native 64 bit n-Tracks could host 32 bit plug-ins, without too much of a perf hit.
Quote:
Of course, handling a lot of tracks when recording is a bigger strain than handling just playback tracks.
Say what? If there are no FX plugins involved, how can there be any difference? Sure some hard disk subsystems are a bit slower at writing versus reading but that's about it right? Maybe I misunderstood...?
My experience has been (with n-Track Pre .NET V4 BTW) I could track 24 channels of 24/44.1 audio for hours on a crappy AthlonXP 2500+ system with nary a hiccup. Conversely, I could play them all back... UNTIL I started adding FX. DOINK! Old CPU couldn't cut the mustard. I had to shuttle the files home on a USB drive to mix. Which BTW, is USB2.0 and would allow me to mix them straight off the external drive. I was pleasantly surprised at that. I didn't think USB would handle the throughput.
D
Quote:
Say what? If there are no FX plugins involved, how can there be any difference? Sure some hard disk subsystems are a bit slower at writing versus reading but that's about it right? Maybe I misunderstood...?
I think you misunderstood. Think overdubbing.
When playing back there will be a fixed number of tracks being read from the hard disk....zero to whatever.
When recording there will be the same number of tracks being played (even if that number is 0 when recording new tracs), but there will be new tracks being written to the hard disk at the same time. Always add whatever is being recorded TO whatever it takes to playback, unless there is some way to record while not playing back.
This is totally unrelated to plug-ins. They just all more overhead to playback.
Ah… right. I was just thinking straight IN or OUT. Yeah, overdubs DO throw a strain on the whole schamozzle. Especially the guys who want to playback 30 tracks with plugins, track monitoring on and record a VSTi in real-time. A whole lot of crunchin’ going on!
D
USB 2 has a greater bandwith than FIREWIRE -
M.R.
Well I’m here to tell ya , running both 64bit and 32 bit on the same 64bit machine with nTrack is a YES.
But the 64 bit installer is giving me a headache right now, Flavio is gonna check it when he gets back to home, (he’s outta town with only a 32 bit lap top.)
But I had both 32 and 64 apps of v6 running at the same time. Even the 32 bit app runs a heck of lot faster and smoother on the 64 bit machine. It may have some doing with the 4 gigs of memory too.
I WILL NOT BE GOING BACK TO A 32 BIT MACHINE FOR DAW WORK! 
nuff said!
But that’s just my opinion, I could be wrong about the whole shootin’ match!
I put the latest beta native 64 bit version on my machine at work just now.
I hit the “cannot register …eq.dll” error. Everything seems ok after continuing past the setup error, but I haven’t tried much (since I’m at work, and since I have no songs on this
machine, and since it’s unregistered beta, and since I’m at work)
This is a totally clean install on Vista 64. No version of n-Track Studio has ever been installed or attempted to be installed on this machine. It’s completely fresh installation of Vista 24 SP1.
Any feedback from Flavio on the “can’t register” issue?
No, I haven’t filed a report or searched the forum …
(because others have already hit this many times and…I’m at work
)
It was fixed, the 32 bit version anyway, came back, re-fixed, cameback.
Try to do a user EQ preset and save it. See if it does or not.
Can’t Vista 64 run stuff in a 32 bit more so your VSTs work? I have stayed away from Vista like the plague, so I really don’t know how runtime modes work on Vista 64.
This is native 64 bit version of n-Tracks I’m working with. The 32 bit version should be able to be installed as well (Bubba, you are correct), but they SHOULD be able to work side by side. That’s irrelevent since this is a clean install of the native 64 bit version on a clean OS.
User EQ Presets seems to work fine…limited simple testing though. I created a new song with one wave. Changed the existing Flat EQ preset to be High Pass (lower band 1 only) and saved it as High Pass. I saved the song, exited restarted n-Tracks and, before doing anything, was able to select High Pass as a preset in the existing Mastering channel EQ.
The bug that hits the “can’t register error during install” is still there in the latest native 64 bit setup, but saving presets seems fine.
The question is, what effect does the missing fa4bdeq.dll pertain to? My machine defaulted to installing into C:\Program Files\FASoft
-Track Studio 6 x64. The dll is in that folder and is registered in that folder (according to regedit).
I suspect the error message is a bogus error. Vista and 64 bit machines do some really strange things to tell when something is to be WOW64 or native 64. Redirection can make things difficult. The setup might be running under WOW64, which would cause it to see the system folder, and many other registry entries, as any 32 bit app should see it or them. Since it’s verifying a dll for proper registration, maybe it’s not finding the 32 bit version of the dll, but the 64 bit version is right where it should be. Redirection will cause c:\windows\system32 and some other paths to be different depending on whether or not the current app is 32 bit or 64 bit. In this case the setup, maybe being 32 bit (32 bit install exe, installing the 64 bit version of n-Tracks…this is normal), is able to see only the 32 bit version of the dll, which doesn’t exist.
(sorry for the wordiness)
That error was my first post on the beta version - I think it may be a bogus error too - none the less it should not happen.
Check to see if .NET Framework 3.5 is installed phoo, if not you’ll have to get it at Microsoft, do a google.
Then do a virgin re-install of n.
This was the only fix for me here, and I’m running both the 32bit and 64bit versions of n, 32 bit registers in (x86) program files and 64 bit installs in the program files.
All the files are exactly where they should be. I don’t think this is related to .NET in any way. n-Tracks required .NET 2.0 and Installer 3.0 to be installed, according to the download page. .NET isn’t required to register a dll anyway, and that was the only error.
Anway, I found an error in the dll, and a few others. They require MSVCR90.DLL, which isn’t on the machine. Missing that dependedncy could cause them to not be registered properly.
What we need to do is to see whick included effecs will actually work. The built in EQ does indeed work, but which dll is that EQ?
Found it… I think.
MSVCR90.DLL comes with Visual Studio 2008 and will be installed as part of .NET 3.5.
We shouldn’t have to install VS 2008 or .NET 3.5 just to get this dll. What the means is n-Tracks will require .NET 3.5 even if it’s not using .NET just to get a system dll that really has nothing to do with .NET.
From: http://codertutorials.blogspot.com/
"
Distributing Visual C++ Applications
In recent years (and recent Visual Studio versions) Microsoft has unintentionally made it much harder to distribute C++ applications.
The reason for all the grief is a new dependency file MSVCR80.dll (Visual Studio 8.0/2005) or MSVCR90.dll (Visual Studio 9.0/2008). The DLL file handles initialization and cleanup of The C++ Standard Libraries among other things. If your swapping applications with another developer then you probably won’t have a problem, but if you try to send your app to someone without the latest Visual Studio they’re going to run into a nasty error message.
The solution Microsoft suggests for solving the problem they created is to wrap the Visual Studio redistributable in an installer. This is okay, but what if your program is too small to warrant an installer? Running a tutorials site, it doesn’t make sense for users to have to install each demo application. My solution was to just compile under Visual C++ 6.0, which is arguably the best in the VC product line anyway.
References:
Deployment (C++)
http://msdn2.microsoft.com/en-us/library/zebw5zk9(VS.80).aspx
"
I don’t understand programming that much, but I think this may
be the reason for some of the errors.
Look here if you want to see the kind of greif Flav has to go through.
Mind Boggling
The n-Track setup should install MSVCR90.DLL along with two other DLLs that make up the Visual C++ runtime (somewhere inside the Windows\WinSXS) so I’m not sure if that’s the cause of the problem.
All of the n-Track files depend on the C++ runtime dlls so nothing should work if those are not installed correctly.
I wasn’t able so far to reproduce the problem, but I’ll continue testing.
It could be perhaps something like a 32 bit version of the EQ is being installed by the 64 bit setup and since only the 64 bit version of the runtime is installed the EQ module wouldn’t load and register correctly, or perhaps the minor version number of the Crt dlls (there are at least two versions of VC 2008 that I know of) doesn’t match, but it would be strange that that only happens with the EQ.
Flavio.