Of course, in the real code the string Sname is generated dynamically. The output is only one control character (<ASCII 32). Strange, because Sfilename is properly created, so Sname should be valid and assigned when the fprints opcode runs.
A quick verification... If I cut&paste your code below, I get:
"error: Unable to find opcode entry for 'fprints' with matching argument types:
Found: (null) fprints SSS"
OTOH, the "%s" in fprints is essentially superfluous here. If I just use
" fprints(Sfilename, Sname)" It works fine! A definite bug, I'd say!
OTOH, the "%s" in fprints is essentially superfluous here. If I just use
" fprintsSfilename, Sname" It works fine!
...
Hm, I could use strcat for a simple case then, but my real string format
would be:
fprintsSfilename, "path/%s\-%d\-%d\-%d\.wav", Sname, iNote, iVelocity, iRobin
For that the %s is definitely useful. Again, this could be worked around
using a prior sprintf, if that works.
Do you have an example of what is not working as expected? With an example I would have something to test but at the moment I am struggling to get a n angle on this.
Do you have an example of what is not working as expected?
I have attached a small zipfile, containing both a CSD and the output text on my system, using ArchLinux's version of Csound:
Csound version 6.15 double samples Sep 7 2020
If the zip is blocked by the list, let me know and I'll upload it somewhere.
Thanks and best wishes,
Jeanette
With an example
I would have something to test but at the moment I am struggling to get a n angle on this.
As far as I can tell your examle runs correctly. Output is
~/csound6> more fprints_bug.txt
Hello world.
~/csound6> od -cx fprints_bug.txt
0000000 H e l l o w o r l d .
6548 6c6c 206f 6f77 6c72 2e64
0000014
This is with latest gitub code (with some unllated exeriments in action).
OTOH I a not aware of any change here, but whatever it was seems fixed
--Csound version 6.15 beta (double samples) Mar 28 2021
[commit: 1ee0bda4d893ac292946b59ca5a210ef7929c046]
This is with latest gitub code with some unllated exeriments in action.
OTOH I a not aware of any change here, but whatever it was seems fixed
...
Thank you for the verification, so I'll just have to compile from source
or wait till the changes get downstream to our packages. I can work
with that.
Hah! Turns out that I'm still running 6.14 from a year ago, which
I didn't realize, and was getting the same bug as Jeanette. I just
switched to the partition which actually *does* have 6.15 from last
September, and it gives the correct output! So I guess we're good...
Sorry about that. (:-/)