I know it is a newbie question, but i ask it: I want to record audio signal from microphones continuously into tables during a performance. I don't know prior to the performance how many tables are needed and how many times i am going to record (it will be decided by other parameters). Is tabwrite~ the right object for this? I suppose writesf~ writes to the disk which is not fast for a realtime situation?
Recording input signal continously
[tabwrite~] writes to ram
[writesf~] writes to disk.
It depends on what you want to do with the recorded sound in realtime? How fast should it be?
Generally spoken if you want to record audio over a long period of time it's common to use [writesf~] as memory space of ram is much smaller than diskspace (on PCs).
You should be able to use writesf~ to write continuously to disk during performance.
In the main Pd thread (which is the one in which your patch is running) writesf~ will just write samples to a buffer every block, plus some other bookkeeping stuff. Reading an array of samples and writing it to another array is about the simplest thing a tilde object can do in Pd, so it should be realtime safe.
There's a secondary (i.e., child) thread that actually writes the data to the disk. For simplicity, the code in the child thread will write data using a blocking system call. But even when writing to the disk takes longer than the time it takes to compute a block of samples in Pd, that's ok. Pd will just add more samples to the buffer, and the child thread will eventually catch up and write everything to disk. Your patch should continue computing audio in realtime with no dropouts.
Using the current settings in Purr Data, it looks like you will start approaching a catastrophe if the child thread falls behind schedule by about 6 seconds. Operating systems don't technically make any guarantee about the maximum time a write to the disk. However, in practice if it takes that long for your computer to write some bytes to disk you've probably got bigger problems with your system. So in practice, you should be able to continuously record to disk without a problem.
Also worth noting-- if Pd itself happens to take too long to compute audio (e.g., your patch uses too much CPU and you hear dropouts) then writesf~ will actually continue to work deterministically (i.e., you'll get the proper audio signal written to disk). This is because the child thread will wait until it has sufficient number of samples to write to the file. (Unlike your soundcard which has to deliver something on a clock, which is just zeros if there was a problem and Pd missed the deadline to deliver audio.)
Edit: another set of clarifications