Thoughts on doing a live recording

Well, you call yourself a programmer. I figure you can crunch this stuff out on your own. :p Now what does it say that I have nothing better to do than to figure it out for you? That’s another matter.

There are 24 bits per sample and 44100 samples per second, so each second is 1058400 bits/8 = 132,300 bytes.
This assumes that .wav files don't pad each 24 bits to a long (32-bits). I don't know the format of .wav files? Are they these sequential bits or what?

You are confusing processing with storage medium. A 24 bit file is called a 24 bit file because it stores things in 24 bits. If it stored it in 32 bits, it would be called a 32 bit file. Now, n-track when it processes a file adds bits to the 24 bits and processes things in 32 bit float which is a 24 bit mantissa with an 8 bit exponent. It then truncates this to the output of your sound card (either 24 bit or 16 bit depending on what you have) thus the need for dither. Wav files are very very simple beasts. They are just a sequencial list of samples. I would suggest you do some reading on how digital audio actually works. It will answer a whole lot of questions and help answer things like should one use 192khz sampling or 64 bit float files or what makes a good and bad convertor or how does jitter effect things etc.

You are confusing processing with storage medium. A 24 bit file is called a 24 bit file because it stores things in 24 bits. If it stored it in 32 bits, it would be called a 32 bit file.
No. I could store 24 bits of data & still pad it to a DWORD when I write it to disk. My question was valid & you've answered it, i.e., .wav files don't pad.

I did some research on .wav files & since I use 24-bit left-justified, it may indeed use a full DWORD. The 24-bit packed version with use 3 bytes: 2 unsigned & 1 signed (if I have the right).

The justified deal has only to do with the transport to/from the soundcard to the host. Once in storage all 24 bit wav files are identical and are 24 bit packed so far as I remember. Learjeff, you’re usually handy with this stuff. Am I way off?
Read this.

I ran my test for 1 minute last night & I was getting ~7MB/track. That comes out to 3360 MB for 60 minutes, which is close to you calculation. Thanks Bubba!

I had some flakiness with the MOTU 896 interface but it seems to be working now. I can’t wait to try it!

One other question. When/why do you need to keep the device open? Should I turn this function off when doing the live recording?

With it on, all the input and output devices are opened and ready to go when the app is run, and stay open the whole time the app is running. With it off the are opened when play/record is initiated and closed when stop happens. It takes time to do this. There are advantages/disadvantages to both, and seems there are some machines that have issues with one or the other.

Right. Wasn’t it this function (or some other one) that Flavio added in the 3.x cycle which he later said to turn off (if you were having certain problems)?

Yeah. It solved a few problems for me.

Did the recording last night. It worked well except for some engineering problems we had due to the fact that no-one was running the computer/audio interface. nTrack worked like a charm, although I wished Flavio would put up the hourglass or status bar while it was writing the .wav files to disk, as a visual clue that it was working.

although I wished Flavio would put up the hourglass or status bar while it was writing the .wav files to disk, as a visual clue that it was working.


Isn't the flashing red RECORDING indicator enough?
Isn't the flashing red RECORDING indicator enough?
No - this is after I've stopped recording so no flashing red light. Generally speaking when a program is not allowing user input, i.e., it is working, you put up the hourglass. Programming 101.

The wav files were already on the disk. n-Track was calculating the “.npk” files to display the waveforms. A visual status indicator would be nice. Hourglass, progress bar, something like that. Running very long times like that, it must take n-Track a fair amount of time to read the npk’s and display the waveforms. As a side note, I wonder if it would help performance any to uncheck “Generate peak files while recording” in the Preferences dialog? Gotta take a few CPU cycles to do that on the fly.

TG

Having “Generate peak files” off will help CPU usage during recording. As soon as you stop recording they get created which can cause that delay in getting the machine back. Maybe having the tracks display closed as well will prevent that from happening right then and there? They should still get created the next time that window is opened. I haven’t tried, thus the question, will this work?

I got ya now. When you said “writing wavs” to disk you meant creating the NPK files. In my version it gives a status bar while it does it because I set it to create the NPKs after the fact.

When you said "writing wavs" to disk you meant creating the NPK files.
What I mean is from the time you stop recording till where the tracks show up in nTrack. Whatever it's doing, making npk files or whatever.

Yeah, if the files are long, it takes awhile - so much so that you will think it’s crashed, or you could miss the start of the next set.

Quote (CosmicCharlie @ Oct. 11 2004,21:32)
What I mean is from the time you stop recording till where the tracks show up in nTrack. Whatever it's doing, making npk files or whatever.

Right. Hrm. For me I always get a status bar as N is creating the NPK files. I am surprised it is not showing up for you and I think a status bar would tell you what you want to know.