Windows Xp Professional 64-bit And Renoise

Yeah, I know I can optimize things a bit in the Play config. In fact, I have, but in a different direction than what you suggest. My current PC is getting a bit old in the tooth, which is why I’m considering a serious upgrade this year. It can only assign about 1.3 GB to the sequencer (and its samples), so I run out pretty fast, and have to rely a lot on HD streaming. Doesn’t help that VSTs like Omnisphere seem to demand about 300-400 MB just for the engine itself before I even load any samples. Play has been a mostly pleasant experience. In fact, I’ve had more problems with Kontakt and Kompakt.

So, I finally got around to building a completely new PC with 12 GB of RAM running Windows 7 x64. At the moment I’m using Cubase 5 because of the 64-bit compatibility, and will use Renoise for simpler songs. My VSTs work flawlessly, including PLAY and Kontakt 3.5. VSTs that aren’t yet 64-bit compatible (such as Omnisphere) seem to work fine using jBridge.

Has there been any progress towards making a 64-bit version of Renoise lately?

Can I ask what kind of audio hardware you’re running?

I’m particularly interested in audio and midi interfaces.

My midi interface dropped support as of Vista 64. =(

It’s nothing special. I’m using an M-Audio ProFire 610 audio interface. M-Audio is very good at supporting their interfaces in Windows 7, and while they haven’t got a public, final driver available yet (it’ll arrive in less than two weeks I think), they’ve got public beta drivers that work very well.

Keep in mind that I also have a Texas Instruments firewire PCI card. If I were using the inbuilt firewire ports in my computer, the audio interface would probably be next to useless due to popping and crackling. As of now I get between 5 and 7 ms latency, though I haven’t tested it with complex arrangements.

M-Audio actually has a good description of the problem and its solutions:…875e546ab813516

I think it boils down to most firewire devices not requiring perfect timing. A hard-drive can operate perfectly even if a write operation is delayed by 10 ms, but an audio application might not. It probably costs a lot more to produce a firewire chipset with perfect asynchronous bandwidth, so they figure they’ll just go with the cheaper option that will work fine for most users.