You would need to save the [capture~] contents as a .txt file and then find some way of [peek~]-ing those sample values into a buffer. Using [coll] would be one way, but you'd need to format the raw .txt file correctly to get that to work. I think the Lobjects contain a list-to-coll object which might do what you need. Think it's called [ltocoll].
Thank you very much! Is there any data size limitation with the [capture~] object? Because I was trying to catch very large number of samples writing it at the object's argument but it seems like it has some limit...
capture~ stores as much as your computer will allow, but its window won't show all the data. You'd need to open the saved contents in a text editor to see it all. If you are using coll for this then you will have to think of a smart way to do - seperating the data into chunks and so on - otherwise you'll find your computer hangs for about half an hour.
The CNMAT sdif objects might be of some use to you, since they are designed to work with large amounts of data.
The capture~ object get amplitude values for each sample of a signal? Of what depends my computer capacity for storing capture~ data? I was trying to catch 1 minute of signal at 96 kHz sampling rate, then I opened the file into a text editor, but there was like 88000 values, I hoped to be at least 5.7 million, It's what I'm saying possible to capture all that information with this object? Or better with CNMAT objects that you recommend?
capture~ claims only to be limited by computer memory and the initialization argument. So, if [capture~ 5760000] isn't writing all your samples to a file, it's arguably a bug and you can file a bug report.
However, why not just record your audio with a buffer~ and write it to a file, or use sfrecord~. These objects are built for saving audio to disk. Capture~'s raison d'être is more for a quick look at a an audio stream for patch debugging purposes.
If you can determine where capture~'s limits are, you could probably build a chain of them and use something like selector~ to fill each one up in turn. But that seems very Rube Goldbergish/Heath Robinsonish compared to sfrecord~.
Thanks Peter Castine and goodparleyandorfing, what I'm trying to do is to reduce an audio signal to numbers and analyze some data, large amounts of data and manage them in smaller size than WAV and AIFF formats, but then can re-build the signal from these numbers and have if it's possible the lossless signal.