Most of PD's mechanisms for saving floats to a file use a decimal text encoding which causes their value to change by small amounts when they are saved and reloaded. This includes floats specified in messages as well as floats stored in arrays where "save contents" or "-k" is specified. As far as I can tell, the only way around this in vanilla is to store the float in an array and then save the array as a 4 byte floating point sound file. Are there other options? Are there any binary file I/O externals?
Saving floats to a file as a 32 bit floats
@seb-harmonik.ar Oh, that's interesting, thanks, that would save me from having to calculate pi and 2*pi when some of my patches first load. But in my case I need to save randomly generated floats to a file and reload them later on. I have a misbehaving patch that sometimes sounds great, so I'd like to be able to capture its state.
This should do the same as float24 as a vanilla abstraction (I hope)........ float_24.pd
and save the value within the patch like this.....float_24.pd
@whale-av I've used save.param2.0 before, so I adapted it to use a NextStep 4 byte float .snd file instead of txt. It only stores floats, but at least they're an exact snapshot.
Seems like a hack to me, that's why I'm asking if there are other ways. I guess I could save your 4 part decomposition of a float as text, but that seems excessive when there's this standard thing we use in normal programming languages called a binary file
@whale-av Hey David, did you mean to upload a different patch in that second link? I wanna see how you're saving the value.
@jameslo The parts are saved in the nbox's below [div 1] when the patch is saved.
It's the same patch, but with a [loadbang] added to restore the value when the patch is reopened.
You have to remember to save the patch though.
You could use the "perf" message to pd to remind yourself to save like this........ float_24.pd
Sending perf 1 to pd forces it to check that you really want to close a window (including the terminal).