Re: [Csnd] fout

I tried the csd with Richard's modification and now it seems to work fine.
How can I remove the zeroes after the comma in the digit that is inside the text file state.txt?


Csound mailing list
Send bugs reports to
        Issues · csound/csound · GitHub
Discussions of bugs and features can be posted here


I don't think that's possible in the way I modified it, as the fouti opcode writes a number, and it is always as floating point, so has decimal places. However, it would be fine when read back into Csound and used to form the next filename with sprintf.

If you do really need the state.txt file to have the number without decimal places, then the fprints opcode would be ideal but as Joachim discovered, it appends rather than overwriting - so you would need to use the approach in his example using the system_i opcode, but then that is operating system dependent (the example doesn't work under windows)

I think changing
   Scmd sprintf "printf %d > state.txt", giFilNum
   Scmd sprintf "echo %d > state.txt", giFilNum
might be more cross-platform friendly though.

just to note that i used echo first, but then there is a new line by default, and this caused an error in readfi, and to get rid of the newline i am not sure about the different versions of shells and operating sytems ...

we should definitely bring fprint(k)s to overwriting ... but how to do it without breaking older code? perhaps an option as last argument?

Good point, didn't think about newline.

I did wonder about that (make it so fprint(k)s could overwrite). As they have an indeterminate number of value arguments, I think the best convention would be to create new opcodes, eg fprints2 and fprintks2 which would overwrite instead of append.

yes makes sense. i'd say: let fprint(k)s2 have an optional argument which decides whether to overwrite or to append.

Sounds good. So maybe the last fixed argument eg:
   fprints2 "filename", "string", ioverwrite, [, ival1] [, ival2] [...]

(where ioverwrite is 0=append (current behaviour) or 1=overwrite)

I will have a look at the source over the next week or so and see if I can come up with something working to propose, unless you/someone else beats me to it...

great --- a pull request would certainly be a wonderful result of this discussion. i like your arguments; i personally would prefer this order:
  fprints2 "filename", ioverwrite, "string", [, ival1] [, ival2] [...]

Wouldn't it be nice to have an fout2 opcode that named the files based on time and date?

Dr. Richard Boulanger
Electronic Production and Design
Berklee College of Music

OK, I'm convinced! I would prefer this order too.

That would be useful but the exact date format might be contentious - I suppose the obvious date format would be the same as the "dates" opcode.

"dates" uses the underlying C function ctime and always returns in the format
Www Mmm dd hh:mm:ss yyyy
(eg Wed Oct 13 15:34:37 2021)

The main issue with that is that colon isn't valid in files on all platforms (definitely not valid in Windows).
John's example to reformat it could be used but then also I suppose there are quite a few taste/locale differences in date formatting. My personal inclination would be to use ISO dates (ie YYYY-MM-DD hh:mm:ss) but then without colons I think it becomes a personal preference what the separator is.
However just highlights taste/locale specifics so might be hard to reach a consensus on the 'correct' date format but if we could that would be great.

Also/instead, I'd propose an additional modification to "dates" that could be used to format a timestamp from the "date" opcode in an arbitrary format using the strftime convention. Eg then that could be used in a one-liner for fout:

   fout dates(date(), "%Y%m%d_%H%M%S.wav"), 14, aout

then that would write a file in my personal preferred timestamp, and one would not need to use the current output of "dates" and then do various strsubs on it to extract the format desired.

(I don't think strings can be optional arguments so my proposed tweak to "dates" would need to be dates2 or just strftime for backwards compatability)