I know everyone is busy, but thought this might be worth mentioning just so
it's kicking around in the idea pool while all the restructuring is going on
. . .

For things like my realtime live rig project I think it would be extremely
useful to have general C style file i/o support in csound, ( well and
console too I guess! ) and also the ability to call system commands. I know
Gab added the system stuff and there was some talk about how this could be
abused to malicious ends, but could we not add a flag or even a compilation
option on csound itself so that only those who know what they are doing and
want these functions are exposed to the risks? So perhaps one would have to
compile csound from source with a special option on, caveats in the docs
etc.

I would love to be able to do file i/o however I want by controlling the
exectution looping myself. So for example having say fopen, fclose, fputs,
fgets, fprintf and fscanf, all with as close to C syntax and functionality
as possible. I assume this would be not too difficult as csound would just
be wrapping C calls right? Would it maybe be easy to have plugin C wrapper
opcodes? It might be cool too to be able to use this to transform say table
data with custom Python scripts on the fly by using some form of save-call
script-load sequence.

So, as with printk, there could be variable determining how often this
executes, and by setting this to zero, one has to control the flow oneself,
but this is not too difficult and often preferable to figuring out how to do
it with constantly executing code. In my project I have much code that only
gets executed on one single kpass, either controlled by a krate counter or
by a midi message from the midiin opcode ( which makes the midi message only
exist for one kpass. )

Just some thoughts, I'm more than happy to wait for developments. But I
gotta say right now I find Csound file i/o really frustrating compared to PD
( though I wouldn't dream of rewritting this with boxes and wires . . . ) ,
and the hackerish solutions Glyn and I have employed to save song files
using the current opcodes are really quite ugly! Well, maybe pretty if you
admire weaselish kluges. ; )

> exectution looping myself. So for example having say fopen, fclose, fputs,
> fgets, fprintf and fscanf, all with as close to C syntax and functionality

whats wrong with fprints/fprintks opcodes? they do full
printf-style formatting... if you want to print not every k-pass you have
to wrap an 'if' around it and increment a counter variable, but not a big
deal, right?  [ i know i have posted to the list before a demo orc/sco
that generates csound scores by using fprintks opcode ]

and fin/fout seem to work for all other purposes.  guess the
only thing missing is fscanf opcode, but then its a question of what you
*do* with the text after you read it form the file?


-m

> whats wrong with fprints/fprintks opcodes? they do full
> printf-style formatting... if you want to print not every k-pass you have
> to wrap an 'if' around it and increment a counter variable, but not a big
> deal, right?  [ i know i have posted to the list before a demo orc/sco
> that generates csound scores by using fprintks opcode ]

Nothings wrong with them, they just don't let me do as much as I would like. 
Or rather it's difficult. Certainly fscanf would be be good, and I'd be pretty 
happy if I had those two combined with some way to use a file pointer to walk 
through the file to where I want to read and write.

fink and outk allow me to skip frames, but only in multiples of the number of 
channels. So I think scanning through a file to find the right place would be 
a bit of a pain. Some combination of fink/foutk behaviour with fprintf/fcanf 
functionality and a location pointer or equivalent would do the job.
 
> and fin/fout seem to work for all other purposes.  guess the
> only thing missing is fscanf opcode, but then its a question of what you
> *do* with the text after you read it form the file?

Well, for my sequencer project I'd like to be able to read and write data 
files for all kinds of purposes. 

Thanks
Iain

> Nothings wrong with them, they just don't let me do as much as I would like.
 > Or rather it's difficult. Certainly fscanf would be be good, and I'd be

i can look into adding a fscan/fscank opcode..  what syntax do you
think is best?  something like:

kval fscank "filename", "formatcode"

allowing for only one value at at time, making assumption that all blanks
and tabs are skipped over?  and what about when you get to
the end of file?

> happy if I had those two combined with some way to use a file pointer to walk
> through the file to where I want to read and write.

so, something like an fseek opcode?

fseek ifilename, iformat, koffset

  iformat [0 = offset in floats, 1 = offset in bytes]


fprints uses gab's table open files for fin/fout opcodes so i think just
one implementation of 'fseek' should work for everything.

-m

The problem is that fscanf can easily fail, for all sorts of reasons 
(format mismatch, non-existent file being two of them), so the opcode 
output really has to be an error flag, as fscanf itself has. fseek is 
virtually meaningless when applied to a text file, as meaningful data 
may be anywhere in  the file, and counting bytes is not much help. 
Parsing a text file almost invariably requires either reading in all the 
data into structured storage, where random access can be employed, or 
streaming line by line. And placed in an opcode, this code may be called 
by multiple instances of the same instrument, forcing the host (via C 
and the OS) to open multiple pointers into the one file, so that each 
instrument can read the data independently of others. The file may have 
to stay open until the end of performance, so that once opened, an 
instrument can't close it again and scupper other running instruments 
using the file.

One way or another I fear lots of wailing and gnashing of teeth in 
getting this working safely and predictably! I really question the 
reasonableness of trying to import C procedural idioms such as this into 
Csound. I suspect the tasks this is intended to solve may be better 
solved using a different more idiomatic approach.

So what specifically are the tasks?


Richard Dobson


Matt J. Ingalls wrote:

>>Nothings wrong with them, they just don't let me do as much as I would like.
> 
>  > Or rather it's difficult. Certainly fscanf would be be good, and I'd be
> 
> i can look into adding a fscan/fscank opcode..  what syntax do you
> think is best?  something like:
> 
> kval fscank "filename", "formatcode"
> 
> allowing for only one value at at time, making assumption that all blanks
> and tabs are skipped over?  and what about when you get to
> the end of file?
> 
> 
>>happy if I had those two combined with some way to use a file pointer to walk
>>through the file to where I want to read and write.
> 
> 
> so, something like an fseek opcode?
> 
> fseek ifilename, iformat, koffset
> 
>   iformat [0 = offset in floats, 1 = offset in bytes]
> 
> 
> fprints uses gab's table open files for fin/fout opcodes so i think just
> one implementation of 'fseek' should work for everything.
> 
> -m
> 
> 

> i can look into adding a fscan/fscank opcode..  what syntax do you
> think is best?  something like:
> 
> kval fscank "filename", "formatcode"
> 
> allowing for only one value at at time, making assumption that all blanks
> and tabs are skipped over?  and what about when you get to
> the end of file?

That would be great Matt. I'd personally guess that sticking to C like syntax 
would be best with no assumptions made about how we might want to use it, so 
that we can optionally specify seperators and chars to be skipped/read, etc.
 
> so, something like an fseek opcode?
>
> 
> fseek ifilename, iformat, koffset
> 
>   iformat [0 = offset in floats, 1 = offset in bytes]

Yeah that looks good. I guess being able to actually use a file handle pointer 
will be too much of a linguistic stretch? At any rate, I'd be happy to test 
them when done 'cause I have code that needs them already! We have the ability 
in our sequencer to save and load sequence patterns while running, but it 
currently involves ftable gymastics and scripts running outside of C sound to 
make the output more usable.

Which brings me to another point, don't know if this is relevant to other 
builds than Istvan's but it might be worth looking into. I obviously can't 
test this on Mac but I could send someone the ( rather large ) code. We have 
event lists made in spreadsheet apps, these get scripted to rejuggled into 
ftables where horizontal on the ftables is time in steps, and 16 sequential 
ftables represent the 16 paramaters for a note in a sequence. So if the 
sequence length is 128 bars, then the tables need to be 2048 points long. I 
discovered that I can load big text files into these tables using gen 23, but 
this is a pain because I then have to generate a seperate file for each table, 
at 32 tracks * 16 ptracks * however many seq banks I want for a set ( say 
16? ) I have a whole lot of include files. I had been making one giant score 
file that was generated by the script and just use gen 2 to explicitly state 
the table data in very long lines. This is nice cause I can always check that 
file manually in vim and edit quick changes there. But it appears I can not 
have more than 128 points explicitly stated with gen 2. I can if desired make 
a seperate test of this problem alone for other builds. 

For that matter, when Csound 5 is beta ready, I will be happy to provide our 
code to anyone who wants to really push the build. So far Istvan's runs it but 
not winsound or CsoundAV. CsoundAv used to work and then just started crashing 
after the number of tables or ftgens or something. Anyway we have in there:

- full duplex midi i/o
- full duplex multichannel audio i/o ( does not work properly on ANY build, 
causes timing problems which is too bad )
- a whole lot of tables ( ie thousands ) and a whole lot of table read writes 

Thanks
Iain
  

> One way or another I fear lots of wailing and gnashing of teeth in 
> getting this working safely and predictably! I really question the 
> reasonableness of trying to import C procedural idioms such as this into 
> Csound. I suspect the tasks this is intended to solve may be better 
> solved using a different more idiomatic approach.
> 
> So what specifically are the tasks?

Ok ideally I want to be able to elegantly and straightforwardly:
- read in from data files and write to data files character by character or 
number by number at a krate controlled point in the file 
- save and load table data to files where the file format is totally under my 
control, including header data or lack thereof
- save and load up multiple ftables to/from one data file with a dynamically 
chosen file name, where the data may not be in the order or format that will 
be going into the ftable. This will allow us to make some form of giant "save 
session" "load session" thing in addition to saving individual sequences or 
patches or whatever.
- save and load audio data on the fly. Maybe this works already, I haven't got 
to the stage where we're trying that yet. Something to allow us essentially to 
load samples up on the fly choosing the name would be awesome.  
- some way to enter strings from the console so that I can choose file names 
to load/save to. This is lower priority for me, but would be nice. Maybe this 
is also already possible?

Like I said, I have no idea how practical all that is. But it would be really 
useful for what I'm doing if it is!

Thanks for listening,
Iain