Hi,
I've been trying to read SysEx files using [text], and I noticed that the loaded file end up being corrupted in a way with bits and bops missing. Also trying to manually copy and paste part of the file (from Atom text editor) I'm not able to copy the entire file, there's always something missing (ie select all the file in Atom, copy and paste in [text]). When loading the file I've got no error, but then when I open the [text] window, this is returned on the console:
(Tcl) UNHANDLED ERROR: extra characters after close-brace
while executing
"pdtk_textwindow_append .x100617310 {d 0 iM @?, f h I R kQ, [ ÷ð ), Y Q Y1
-" ( , XFN 8 ) 6{ ) ) ;
}
pdtk_textwindow_append .x1006173..."
("uplevel" body line 39)
invoked from within
"uplevel #0 $docmds
I know, it's a kind of a weird thing trying to read SysEx files in this way and probably it's just me trying to do something with the wrong tool. But weirdly enough the sequences of characters I cannot copy and paste from Atom, can then be directly typed in the [text] window. I suspect this has to do with the character encoding. Does anyone know why [text] behave this way?
Cheers, Mario
The trouble is probably the presence of a '{' character in the file. But there will be other problems - ASCII NULL characters will simply terminate the string early, and semicolons, spaces, and commas will confuse things.
Somewhere on my long do-list is an idea to make an addition to soundfiler to read binary chanracters into an array.
cheers Miller
On Fri, Jan 18, 2019 at 04:39:04PM +0000, Mario Buoninfante wrote:
Hi,
I've been trying to read SysEx files using [text], and I noticed that the loaded file end up being corrupted in a way with bits and bops missing. Also trying to manually copy and paste part of the file (from Atom text editor) I'm not able to copy the entire file, there's always something missing (ie select all the file in Atom, copy and paste in [text]). When loading the file I've got no error, but then when I open the [text] window, this is returned on the console:
(Tcl) UNHANDLED ERROR: extra characters after close-brace while executing "pdtk_textwindow_append .x100617310 {d 0 iM @?, f h I R kQ, [ ???? ), Y Q Y1 -" ( , XFN
8 ) 6{) ) ; } pdtk_textwindow_append .x1006173..." ("uplevel" body line 39) invoked from within "uplevel #0 $docmdsI know, it's a kind of a weird thing trying to read SysEx files in this way and probably it's just me trying to do something with the wrong tool. But weirdly enough the sequences of characters I cannot copy and paste from Atom, can then be directly typed in the [text] window. I suspect this has to do with the character encoding. Does anyone know why [text] behave this way?
Cheers, Mario
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Somewhere on my long do-list is an idea to make an addition to soundfiler to read binary chanracters into an array.
+1
@Mario: in the meantime you can use [mrpeach/binfile] to read arbitrary binary data.
Gesendet: Montag, 21. Januar 2019 um 00:34 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Mario Buoninfante" mario.buoninfante@gmail.com Cc: pd-list pd-list@lists.iem.at Betreff: Re: [PD] [text] issue reading SysEx files
The trouble is probably the presence of a '{' character in the file. But there will be other problems - ASCII NULL characters will simply terminate the string early, and semicolons, spaces, and commas will confuse things.
Somewhere on my long do-list is an idea to make an addition to soundfiler to read binary chanracters into an array.
cheers Miller
On Fri, Jan 18, 2019 at 04:39:04PM +0000, Mario Buoninfante wrote:
Hi,
I've been trying to read SysEx files using [text], and I noticed that the loaded file end up being corrupted in a way with bits and bops missing. Also trying to manually copy and paste part of the file (from Atom text editor) I'm not able to copy the entire file, there's always something missing (ie select all the file in Atom, copy and paste in [text]). When loading the file I've got no error, but then when I open the [text] window, this is returned on the console:
(Tcl) UNHANDLED ERROR: extra characters after close-brace while executing "pdtk_textwindow_append .x100617310 {d 0 iM @?, f h I R kQ, [ ???? ), Y Q Y1 -" ( , XFN
8 ) 6{) ) ; } pdtk_textwindow_append .x1006173..." ("uplevel" body line 39) invoked from within "uplevel #0 $docmdsI know, it's a kind of a weird thing trying to read SysEx files in this way and probably it's just me trying to do something with the wrong tool. But weirdly enough the sequences of characters I cannot copy and paste from Atom, can then be directly typed in the [text] window. I suspect this has to do with the character encoding. Does anyone know why [text] behave this way?
Cheers, Mario
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
make an addition to soundfiler to read binary characters into an array.
wouldn't "read -raw 0 1 1 n" work?
Le lun. 21 janv. 2019 à 00:55, Christof Ressi christof.ressi@gmx.at a écrit :
Somewhere on my long do-list is an idea to make an addition to soundfiler to read binary chanracters into an array.
+1
@Mario: in the meantime you can use [mrpeach/binfile] to read arbitrary binary data.
Gesendet: Montag, 21. Januar 2019 um 00:34 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Mario Buoninfante" mario.buoninfante@gmail.com Cc: pd-list pd-list@lists.iem.at Betreff: Re: [PD] [text] issue reading SysEx files
The trouble is probably the presence of a '{' character in the file. But there will be other problems - ASCII NULL characters will simply terminate the string early, and semicolons, spaces, and commas will confuse things.
Somewhere on my long do-list is an idea to make an addition to soundfiler to read binary chanracters into an array.
cheers Miller
On Fri, Jan 18, 2019 at 04:39:04PM +0000, Mario Buoninfante wrote:
Hi,
I've been trying to read SysEx files using [text], and I noticed that
the
loaded file end up being corrupted in a way with bits and bops missing. Also trying to manually copy and paste part of the file (from Atom text editor) I'm not able to copy the entire file, there's always something missing (ie select all the file in Atom, copy and paste in [text]). When loading the file I've got no error, but then when I open the
[text]
window, this is returned on the console:
(Tcl) UNHANDLED ERROR: extra characters after close-brace while executing "pdtk_textwindow_append .x100617310 {d 0 iM @?, f h I R kQ, [ ???? ),
Y Q Y1
-" ( , XFN
8 ) 6{) ) ; } pdtk_textwindow_append .x1006173..." ("uplevel" body line 39) invoked from within "uplevel #0 $docmdsI know, it's a kind of a weird thing trying to read SysEx files in
this way
and probably it's just me trying to do something with the wrong tool. But weirdly enough the sequences of characters I cannot copy and paste
from
Atom, can then be directly typed in the [text] window. I suspect this has to do with the character encoding. Does anyone know why [text] behave this way?
Cheers, Mario
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mon, 2019-01-21 at 10:03 +0100, Antoine Rousseau wrote:
make an addition to soundfiler to read binary characters into an array.
wouldn't "read -raw 0 1 1 n" work?
It would be cool if -raw would allow 1 byte per sample. But even if it worked this way, the result would be scaled to the range of -1 to 1, which is not so handy. A way to read bytes represented in the array as numbers in the range of 0 to 255 would make [soundfiler] really useful for dealing with binary files.
Roman
On 21.01.19 12:48, Roman Haefeli wrote:
On Mon, 2019-01-21 at 10:03 +0100, Antoine Rousseau wrote:
make an addition to soundfiler to read binary characters into an array.
wouldn't "read -raw 0 1 1 n" work?
It would be cool if -raw would allow 1 byte per sample. But even if it worked this way, the result would be scaled to the range of -1 to 1, which is not so handy. A way to read bytes represented in the array as numbers in the range of 0 to 255 would make [soundfiler] really useful for dealing with binary files.
attached is a vanilla abstraction to read binary files like [mrpeach/binfile].
it allows both [read <filename>( and [read <filename> <maxsize>(.
caveats:
- if the file-size is not a multiple of 2, the last byte is omitted!
- when using the <maxsize> feature, you get an ugly error-like warning
on the Pd-console.
- it's not super-efficient. especially it reads the entire (up to
<maxsize> bytes) file into memory twice. so it's probably not a good idea to use this with large files. it also outputs the entire file as a list of bytes (as opposed to [mrpeach/binfile] which just gives you have to bang to get the next byte).
gasdmr IOhannes
On Mon, 2019-01-21 at 13:34 +0100, IOhannes m zmoelnig wrote:
On 21.01.19 12:48, Roman Haefeli wrote:
On Mon, 2019-01-21 at 10:03 +0100, Antoine Rousseau wrote:
make an addition to soundfiler to read binary characters into an array.
wouldn't "read -raw 0 1 1 n" work?
It would be cool if -raw would allow 1 byte per sample. But even if it worked this way, the result would be scaled to the range of -1 to 1, which is not so handy. A way to read bytes represented in the array as numbers in the range of 0 to 255 would make [soundfiler] really useful for dealing with binary files.
attached is a vanilla abstraction to read binary files like [mrpeach/binfile].
Sweet! Thanks for sharing.
Roman
-
Antoine Rousseau -
Christof Ressi -
IOhannes m zmoelnig -
Mario Buoninfante -
Miller Puckette -
Roman Haefeli