It's probably very obvious, but I can't figure out how to read and write files containing arbitrary binary data. I know there are objects for reading and writing sound files, and there's [textfile] for reading text files, but I want to read and write binary files, and interpret each byte as a 16-bit integer. Does anyone have an example I can look at? Since they will be small files, I just need to read them sequentially, I don't need to jump around in the file randomly.
Try using the -raw flag for [soundfiler]. Setting the <bytespersample> parameter to 2 will treat it as a 16-bit file.
.mmb
On Fri, Feb 25, 2011 at 7:07 PM, David dfkettle@gmail.com wrote:
It's probably very obvious, but I can't figure out how to read and write files containing arbitrary binary data. I know there are objects for reading and writing sound files, and there's [textfile] for reading text files, but I want to read and write binary files, and interpret each byte as a 16-bit integer. Does anyone have an example I can look at? Since they will be small files, I just need to read them sequentially, I don't need to jump around in the file randomly.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
mrpeach/binfile is probably what you want.
.hc
On Feb 25, 2011, at 7:07 PM, David wrote:
It's probably very obvious, but I can't figure out how to read and write files containing arbitrary binary data. I know there are objects for reading and writing sound files, and there's [textfile] for reading text files, but I want to read and write binary files, and interpret each byte as a 16-bit integer. Does anyone have an example I can look at? Since they will be small files, I just need to read them sequentially, I don't need to jump around in the file randomly.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
On Fri, 25 Feb 2011, David wrote:
It's probably very obvious, but I can't figure out how to read and write files containing arbitrary binary data. I know there are objects for reading and writing sound files, and there's [textfile] for reading text files, but I want to read and write binary files, and interpret each byte as a 16-bit integer. Does anyone have an example I can look at? Since they will be small files, I just need to read them sequentially, I don't need to jump around in the file randomly.
use [#in grid myfilename.zzz, headerless, type s]
see http://gridflow.ca/help/%23io.grid-help.html and http://gridflow.ca/help/%23in-help.html and http://gridflow.ca/help/%23out-help.html
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Hi! I tried to install gridflow (v9.12), but I encountered some missing dependencies:
dpkg: dependency problems prevent configuration of gridflow: gridflow depends on libcv2.1; however: Package libcv2.1 is not installed. gridflow depends on libglew1.5 (>= 1.5.2); however: Package libglew1.5 is not installed.
The second one, libglew1.5, I was able to install from one of my registered depositories. But the other one, libcv2.1, isn't listed in any of my depositories. There is a package called 'libcv4', but it didn't help. Where can I find a copy of libcv2.1?
I'm running EasyPeasy (a Linux distro for netbooks), so I wasn't sure which version of the 'deb' file to use. Would that make any difference?
Thanks.
On Fri, Feb 25, 2011 at 7:56 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Fri, 25 Feb 2011, David wrote:
It's probably very obvious, but I can't figure out how to read and write files containing arbitrary binary data. I know there are objects for reading and writing sound files, and there's [textfile] for reading text files, but I want to read and write binary files, and interpret each byte as a 16-bit integer. Does anyone have an example I can look at? Since they will be small files, I just need to read them sequentially, I don't need to jump around in the file randomly.
use [#in grid myfilename.zzz, headerless, type s]
see http://gridflow.ca/help/%23io.grid-help.html and http://gridflow.ca/help/%23in-help.html and http://gridflow.ca/help/%23out-help.html
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sat, 26 Feb 2011, David wrote:
The second one, libglew1.5, I was able to install from one of my registered depositories. But the other one, libcv2.1, isn't listed in any of my depositories. There is a package called 'libcv4', but it didn't help. Where can I find a copy of libcv2.1?
I don't know that stuff... although I develop it all on Ubuntu, I don't do the packaging on Ubuntu. The libcv package version numbering is confusing. Libcv4 is OpenCV 2. If you find libcv2.1, I wouldn't be sure what that means. It could be the same as libcv4 and I wouldn't know... and the package manager wouldn't either.
I'm running EasyPeasy (a Linux distro for netbooks), so I wasn't sure which version of the 'deb' file to use. Would that make any difference?
Any that works. The whole concept of having distinct packages for OS releases that are just 6 months apart, it's just beyond me.
GridFlow is quite easy to build from source, though : If you've installed anything from source before, it can be a matter of minutes.
Otherwise, I hope you can get some help about the deb files.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Thanks. I think I'll try using the MrPeach external. I didn't realize that it was already installed (I'm using pd-extended). It seems to do what I want, and I don't have to install any other libraries.
I have a question about [binfile] though, for either of you (or anybody else). Is there only one buffer that has global scope, or is there one buffer for each patch that uses [binfile]? I tried to create one sub-patch to read the file, and another to write it out, assuming that the buffer was global. But the file that was created was empty, so I guess I need to extract the data from the buffer and pass it around in a list. Is there an object to get/put all the values in the buffer and convert them to/from a list? Or do I have to write a loop to do it "manually"?
Thanks again.
On Sat, Feb 26, 2011 at 3:16 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Sat, 26 Feb 2011, David wrote:
The second one, libglew1.5, I was able to install from one of my registered depositories. But the other one, libcv2.1, isn't listed in any of my depositories. There is a package called 'libcv4', but it didn't help. Where can I find a copy of libcv2.1?
I don't know that stuff... although I develop it all on Ubuntu, I don't do the packaging on Ubuntu. The libcv package version numbering is confusing. Libcv4 is OpenCV 2. If you find libcv2.1, I wouldn't be sure what that means. It could be the same as libcv4 and I wouldn't know... and the package manager wouldn't either.
I'm running EasyPeasy (a Linux distro for netbooks), so I wasn't sure which version of the 'deb' file to use. Would that make any difference?
Any that works. The whole concept of having distinct packages for OS releases that are just 6 months apart, it's just beyond me.
GridFlow is quite easy to build from source, though : If you've installed anything from source before, it can be a matter of minutes.
Otherwise, I hope you can get some help about the deb files.
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 2011-02-26 17:57, David wrote:
Thanks. I think I'll try using the MrPeach external. I didn't realize that it was already installed (I'm using pd-extended). It seems to do what I want, and I don't have to install any other libraries.
I have a question about [binfile] though, for either of you (or anybody else). Is there only one buffer that has global scope, or is there one buffer for each patch that uses [binfile]? I tried to create one sub-patch to read the file, and another to write it out, assuming that the buffer was global. But the file that was created was empty, so I guess I need to extract the data from the buffer and pass it around in a list. Is there an object to get/put all the values in the buffer and convert them to/from a list? Or do I have to write a loop to do it "manually"?
Actually each [binfile] has its own buffer, which can only be accessed via the inlet of that [binfile]. You could use [send] and [receive] objects to communicate across patches, and [tabwrite] to dump the buffer into a table and work on it there. Or use [list append] to build a list.
[bang] | [trigger b b b] | | | |* | | [until] [rewind( [0( |________| / | / [binfile] / | |* / The * connects back to the [until] to stop it. | / [trigger f b]/ | |/ | [f]X[+1] | | [tabwrite x]
Martin
Thanks for your help. It took me a while to figure out how 'list append' works, but I finally managed to get it working. I've attached the patch (intended to be used as an abstraction, invoked from another patch, which returns the data read from the file in a list).
I have another question, though. How do the files get closed? When you exit PureData? Does that mean that every time you open a file, another system file handle is used and not released until you exit PureData? Or is there some way to explicitly close the file and release the file handle, buffers, etc.?
David.
On Sun, 27 Feb 2011, David wrote:
I have another question, though. How do the files get closed? When you exit PureData? Does that mean that every time you open a file, another system file handle is used and not released until you exit PureData? Or is there some way to explicitly close the file and release the file handle, buffers, etc.?
This depends on every object class.
In the case of [binfile] [textfile] [qlist] [soundfiler], the 'read' method copies the whole file to RAM and closes immediately the filehandle.
In the case of [#io.grid] ([#in grid]) and video readers, there is 'open' and there is 'close'.
In [readsf~] it's slightly different, as 'stop' or '0' implies closing, but it's not documented as such in Miller's manual. The structure of 'open' followed by 'start'/'1' and then 'stop'/'0' would suggest that there is a separate 'close', and thus that after a stop you'd be able to resume without reopening, but this is not the case. (!!!)
GridFlow's 'load' in image readers is just a shortcut for an 'open' 'bang' 'close' sequence.
I think I remember that someone has found a filehandle leak bug somewhere in Pd, but I don't recall what that was. Anyone remembers ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Mon, 2/28/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Reading and writing binary files To: "David" dfkettle@gmail.com Cc: "pd-list" pd-list@iem.at, "Martin Peach" martin.peach@sympatico.ca Date: Monday, February 28, 2011, 3:31 AM On Sun, 27 Feb 2011, David wrote:
I have another question, though. How do the files get
closed? When you exit PureData? Does that mean that every time you open a file, another system file handle is used and not released until you exit PureData? Or is there some way to explicitly close the file and release the file handle, buffers, etc.?
This depends on every object class.
In the case of [binfile] [textfile] [qlist] [soundfiler], the 'read' method copies the whole file to RAM and closes immediately the filehandle.
In the case of [#io.grid] ([#in grid]) and video readers, there is 'open' and there is 'close'.
In [readsf~] it's slightly different, as 'stop' or '0' implies closing, but it's not documented as such in Miller's manual. The structure of 'open' followed by 'start'/'1' and then 'stop'/'0' would suggest that there is a separate 'close', and thus that after a stop you'd be able to resume without reopening, but this is not the case. (!!!)
GridFlow's 'load' in image readers is just a shortcut for an 'open' 'bang' 'close' sequence.
I think I remember that someone has found a filehandle leak bug somewhere in Pd, but I don't recall what that was. Anyone remembers ?
Well, I know if I read a ca. 15mb file with [textfile], it takes about 10 seconds to load, then if I try to iterate through the file with [until] Pd will freeze.
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2011-02-27 20:51, David wrote:
Thanks for your help. It took me a while to figure out how 'list append' works, but I finally managed to get it working. I've attached the patch (intended to be used as an abstraction, invoked from another patch, which returns the data read from the file in a list).
I have another question, though. How do the files get closed? When you exit PureData? Does that mean that every time you open a file, another system file handle is used and not released until you exit PureData? Or is there some way to explicitly close the file and release the file handle, buffers, etc.?
Actually read or write messages close the file right away, the buffer remains at least big enough to fit the largest file read or constructed in the buffer. If you want to clear the space you could read a zero-length file into the buffer, or delete the [binfile], or close the patch, or exit Pd, or switch off the machine...
Martin
Switching off the machine seems a little extreme to me! :)
On Mon, Feb 28, 2011 at 12:36 AM, Martin Peach martin.peach@sympatico.ca wrote:
On 2011-02-27 20:51, David wrote:
Thanks for your help. It took me a while to figure out how 'list append' works, but I finally managed to get it working. I've attached the patch (intended to be used as an abstraction, invoked from another patch, which returns the data read from the file in a list).
I have another question, though. How do the files get closed? When you exit PureData? Does that mean that every time you open a file, another system file handle is used and not released until you exit PureData? Or is there some way to explicitly close the file and release the file handle, buffers, etc.?
Actually read or write messages close the file right away, the buffer remains at least big enough to fit the largest file read or constructed in the buffer. If you want to clear the space you could read a zero-length file into the buffer, or delete the [binfile], or close the patch, or exit Pd, or switch off the machine...
Martin
-
David -
Hans-Christoph Steiner -
Jonathan Wilkes -
Martin Peach -
Mathieu Bouchard -
Mike Moser-Booth