Synchronize multiple N-Track systems

Anybody ever tried this?

The song I’m working on right now is not even playable by my computer, and it’s barely mix-downable. My track count is somewhere in the mid-twenties.

All this got me thinking … would it be possible to have more than one system running n-track, and have them synced together, so that if you press play on one … both start. Or if you press record on the other, the other one plays or records as needed.

Of course, you would have to run the physical audio outs to say a third system or hardware solution for mixing down … and you couldn’t mix down offline.

Anyways, I was just wondering if anybody has ever tried this and if it worked.

It should work via MIDI sync, as well as syncing external MIDI sequencers that is. One machine is the master and the other is the slave.

Offline mixdown could still work, but you’d end up the a mix from each machine. As long as there was some sort of wave tick at the beginning it would be trivial to bring them into a new song and mix them to a final mix, just as mixing submixes.

Have you explored using frozen groups to take the heat off the CPU? It works pretty well, but there are a few things to keep in mind when doing it.

I havent had much luck with freezing stuff.

I have lots of vsti’s that are not just killing, but slaughtering my cpu. In that case, is it better to freeze the midi track? or the vsti channel?

I’m all ears! :D

Eyup!

I remember quite a while ago on the forum someone experimenting with an application which linked two pc’s via ethernet. The idea being that one computer would run NTrack as normal, whilst the other would take care of the vst processing. The idea did work as I recall, but with the rapid advances in cpu speed it didn’t catch on. It might still be out there…

Steve

There are a few Midi over IP applications available such as Midi Via Net, ipMIDI. I’ve not used any, but if you decide to, let us know how you get on.

Ta
John

Quote (Beefy Steve @ Sep. 21 2005,04:05)
Eyup!

I remember quite a while ago on the forum someone experimenting with an application which linked two pc's via ethernet. The idea being that one computer would run NTrack as normal, whilst the other would take care of the vst processing. The idea did work as I recall, but with the rapid advances in cpu speed it didn't catch on. It might still be out there...

Steve

I think BeefySteve is referring to FX Teleport. I have not tried it myself, but I understand it does work.

TG

What you want to do is freeze MIDI tracks.

If the built-in feature isn’t working for you, just do it manually (as I do using V3).

Solo the MIDI track (and no other tracks).
Turn off any FX on the master channel and set the master fader to zero.
Offline mixdown, to 32-bit format. (This way, the track fader setting won’t matter.)
I usually type in a meaningful name for the track (rather than mixdown_01 or whatever).
Import the resulting track.
Un-SOLO and MUTE the MIDI track. Minimize it to get it out of mind for now.

HTH. Cheers

Quote (cmw @ Sep. 20 2005,20:59)
I havent had much luck with freezing stuff.

I have lots of vsti’s that are not just killing, but slaughtering my cpu. In that case, is it better to freeze the midi track? or the vsti channel?

I’m all ears! :D

Out of curiousity, Which ones are the culprits? Or is it just that you are using a lot of them? ???

I have and use FXTeleport. It works a treat as long as you keep your plugins tidy. Worth every penny. Sure saves on cpu usage.

Tom

You have to look at what “Freeze” does. It makes a temporary rendering of JUST the selected track,Aux or Group. Rendering a VSTi to audio is accomplished whether you “freeze” or solo and render. No difference really. With freeze, you are saved the trouble of juggling different versions of a track in and out of your song arrangement. Wanna change the patch sound on the VSTi? Click “Unfreeze”, make your change and “Re-freeze”.

You say you are having trouble with Freeze. What kind of trouble?

TG

PS Remember also that in Preferences you can set the Freeze file bit depth. Temporarily freezing your VSTi tracks to 16 bit files might be a little easier on your PC. Once they are perfect. Render them at 24 bits and do your mixdown.

Hey CMW, if you happen to have $400(for both) and can still find them, the steinberg VSL2020 ADAT cards were specifically designed to do what you’re asking. you send the MIDI from the 1st computer, run the vsti’s on the 2nd, and send the audio back into the 1st for mixing. you could easily do the same thing with other ADAT cards, but these came with a program that let you do some other stuff with it as well.

The problems I had with freeze were that it takes a long time and didn’t make things any better for me. I was still getting stuttering, crackling, and massive CPU spikes.

Well … it turns out my problem wasn’t with freeze.

On a whim I tried switching form ASIO drivers to WDM drivers. Suddenly, CPU usage dropped from 103% to like 40%.

Of course after I re-enabled all my tracks it was back up to the mid 80’s, but at least I’m able to mix now. :)

It still takes several (3-5) minutes to freeze a track though.

You could still have problems with Freeze, depending on what you are freezing.

Freezing groups will not cause the CPU usage to go down unless Read data from tracks even if muted is turned off (it’s on by default), and you have muted the tracks going to the frozen group after freezing the group. This is by design since tracks may still need to send to AUX channels, even when the group is frozen — those tracks will contiue to be played unless muted so sending to AUX still works. I think there is some new functionality in the last few builds to address some of this.

Tracks may use more CPU after freezing, depending on the format of the frozen tracks. Freezing a mono 16 bit track may result in the frozen track being stereo 24 or 32 bits. Playing back the frozen track 24/32 bit stereo wave file will use more CPU than playing the original 16 bit mono wave file.

Freezing is a great way to avoid plug-in CPU usage, but isn’t the end-all for CPU usage problems. It can help greatly with a little though about what the result of freezing is though. Some of these things aren’t that obvious, though once you see what’s happening they make total sense.

Yes, freezing does take a while.

Another feature that helps lower CPU usage, depending on what’s in the tracks, is Bounce to a single wavefile. If there are many edits or clips from different waves in a single track this can really help cut down on playback CPU usage. It’s smart enough to save out a new wave that is the same format as the ones in the track (mono waves in a track produces a mono flattened track). I don’t know how it handles bit depth, but I think it uses the same bit depth as freezing…could be wrong.

Well … I tried the bounce feature last night.

The resulting bounced tracks were horribly out of synch with the rest of the song.

Could this be caused by having SIR running on AUX1?

At least I was able to undo the bouncing. I was really freaked out for a second there. :p

It’s possible.

I ran into an interesting sync problem a couple of nights ago, and meant to post about it but forgot. Oh well.

I put SIR in a AUX return and cranked a send to it. All of a sudden there was reverb coming out before the dry signal from the send. The reason what that the AUX return was set to be Post Master Volume and Post Master Effects. Changing that to Pre-Master Volume and Pre-Master Effect fixed it.

Yes, Freaked Out is a great way to describe my initial response. :)

I have not seen bounced tracks be out of sync, but it does sound possible.

I do consider these kinds of issues to be bugs in n-Tracks. If you can find a 100% repro, and a way to work around it, then maybe Flavio can get them fixed eventually. Finding a workaround is more than avoiding the problem on our end. It helps Flavio figure out why some things are happening in the first place.

Right – that should be reported to Flavio.

When I was using V4, whenever I tried Freeze, … freeze it would – whole computer would lock up. For a number of reasons I backtracked to V3, but I hope to try again with V4 when I get a new computer in a month or two (running XP rather than W2K, and hopefully fixing a number of problems).