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].

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.

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~.