[bug?] File() object writefloat32()

    MIB's icon
    MIB
    Oct 13 2014 | 6:17 am
    I am trying to write some data to a textile and am looking at the new File() object. If I run the following code I get some behaviour I can not explain:
    function writefile(s)
{
	var patcherDir = this.patcher.filepath.replace(patcher.name+".maxpat", "");
	
	post(patcherDir, "\n")
	
	var f = new File(patcherDir + "testFile.txt","write","TEXT"); 
	var s2 = "dataName.54";
	var s3 = "size " + 74;
	var s4 = [0.0, 1.1, 2.2, 3.3, 4.4, 5.5];

	if (f.isopen) {

		f.writeline(s2); 
		f.writeline(s3);
		f.writefloat32(s4);

		f.close();
	} 
	else {
		post("could not create file: " + s + "\n");
	}
}
    here is what the resulting textile looks like:
    dataName.54
size 74
ÕÃå?ÕÃ@33S@ÕÃå@∞@
    Am I misunderstanding how the writefloat32() function is supposed to be used or is this a bug?
    I am trying to encode a mix of int and float data in the end. Would it be better to stringify it all?
    Thanks
    • Oct 13 2014 | 7:14 am
      MIB's icon
      MIB
      For now I am testing using the f.writeline(myArray.toString()); and when I need to read it I use newA = a.split(',').map(parseFloat);
      I would be really interested in knowing if that's the best approach though.
      Share
    • Oct 13 2014 | 2:12 pm
      Jan's icon
      Jan
      Hi MIB,
      it's not a bug, its a feature :)
      writefloat32() does not write the string/char representation of the float array but the values itself. Therefore they are not in a human readable form in your text file. If you want to read the values back use readfloat32()
      here is an example:
      function writefile(s)
{
	var patcherDir = this.patcher.filepath.replace(patcher.name+".maxpat", "");
	
	post(patcherDir, "\n")
	
	var f = new File(patcherDir + "testFile.txt","write","TEXT"); 
	var s4 = [1.12345, 2.93];

	if (f.isopen) {
		f.writefloat32(s4);

		f.close();
	} 
	else {
		post("could not create file: " + s + "\n");
	}
}

function readfile() {
	var patcherDir = this.patcher.filepath.replace(patcher.name+".maxpat", "");
	post(patcherDir, "\n")
	var f = new File(patcherDir + "testFile.txt","read","TEXT"); 
	
	f.open();
	var floats = f.readfloat32(2); // in parenthesis: length of array to be returned
								   // floats now is an actual array of floats, not a string!!
	post(floats);post();
	outlet(0, floats);
	
	f.close();
}
      Share
    • Oct 13 2014 | 11:58 pm
      MIB's icon
      MIB
      Thanks for the information. Did I miss something in the documentation about this?? Since I want my .txt to be human readable, I will stick with my "workaround" for now.
      Share
    • Oct 14 2014 | 10:23 am
      Jan's icon
      Jan
      It's just what the ref page says. I admit it doesn't give more explanations to clarify further. Within a plain text file (with no programming or scripting language defined) there is no human readable representation of an array of data. It takes char values and writes them down as bytes in the text file. When correctly interpreted i.e. by a text editor (or the File object - meaning the right byte order and character encoding style is assumed) these bytes are translated back to human readable characters. That is assumed to be known by a reader. The second sentence gives a hint though:
      The byteorder property is taken into account when writing these values.
      The byteorder property refers to the so-called endianness usually written as BOM (Byte Order Mark) in a text file. The BOM defines how the characters/char values are translated into numeric values for storing: http://en.wikipedia.org/wiki/Byte_order_mark.
      But agreed, this can be confusing when new to this subject ...
      cheers,
      Jan
      Share