Currently says
      Notice that fout and foutk can use
      either a string containing a file pathname, or a handle-number
      generated by fiopen.

f the part about fiopen is removed then there is no way of creating a
handle and so fout.i opcode can never happen.  Or we need to add
options to fiopen to create _W files

Neither fout nor foutk can take a handle from fiopen currently, so we just
remove that notice.


> On 11 Oct 2016, at 15:56, jpff  wrote:
> 
> Currently says
>      Notice that fout and       linkend="foutk">foutk can use
>      either a string containing a file pathname, or a handle-number
>      generated by       linkend="fiopen">fiopen.
> 
> f the part about fiopen is removed then there is no way of creating a
> handle and so fout.i opcode can never happen.  Or we need to add
> options to fiopen to create _W files
> 

And the code -- fout.i can never work asit takesa andle and there is no 
way  of creating a CSFILE_SND_W file outside fout.

On Tue, 11 Oct 2016, Victor Lazzarini wrote:

> Neither fout nor foutk can take a handle from fiopen currently, so we just
> remove that notice.
>
>
>> On 11 Oct 2016, at 15:56, jpff  wrote:
>>
>> Currently says
>>      Notice that fout and >      linkend="foutk">foutk can use
>>      either a string containing a file pathname, or a handle-number
>>      generated by >      linkend="fiopen">fiopen.
>>
>> f the part about fiopen is removed then there is no way of creating a
>> handle and so fout.i opcode can never happen.  Or we need to add
>> options to fiopen to create _W files
>>
>> ==John ffitch

Just for reference, the code from Csound 5 can be viewed here:

https://github.com/csound/csound/blob/csound5_17_3/Opcodes/fout.c

in case that's useful to compare.

I tried to spend a little time with gdb. If I put in a break at
fout_open_file, then bt, I get:

#0  fout_open_file (csound=csound@entry=0xd40080, p=p@entry=0x0,
    fp=fp@entry=0x66fc68, fileType=fileType@entry=3, iFile=0x3df2558,
    isString=isString@entry=1, fileParams=0x6c7d63df ,
    forceSync=forceSync@entry=1)
    at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:75
#1  0x000000006c611337 in fiopen_ (csound=0xd40080, p=0x3dffe28, istring=1)
    at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:620
#2  0x000000006c511079 in init0 (csound=csound@entry=0xd40080)

The error occurs before outfile_set is even called.  It's somewhat
bizarre, if I comment out fout in the CSD, the fiopen call works.  If
I put it back in, fiopen fails.

On Tue, Oct 11, 2016 at 12:01 PM, jpff  wrote:
> And the code -- fout.i can never work asit takesa andle and there is no way
> of creating a CSFILE_SND_W file outside fout.
>
>
> On Tue, 11 Oct 2016, Victor Lazzarini wrote:
>
>> Neither fout nor foutk can take a handle from fiopen currently, so we just
>> remove that notice.
>>
>>
>>> On 11 Oct 2016, at 15:56, jpff  wrote:
>>>
>>> Currently says
>>>      Notice that fout and >>      linkend="foutk">foutk can use
>>>      either a string containing a file pathname, or a handle-number
>>>      generated by >>      linkend="fiopen">fiopen.
>>>
>>> f the part about fiopen is removed then there is no way of creating a
>>> handle and so fout.i opcode can never happen.  Or we need to add
>>> options to fiopen to create _W files
>>>
>>> ==John ffitch
>>
>>

Sorry, I realize now the error has to do with textXXXX.aiff already
existing after the previous run. When I delete that and restart I do
get into outfile_set.

On Tue, Oct 11, 2016 at 12:43 PM, Steven Yi  wrote:
> Just for reference, the code from Csound 5 can be viewed here:
>
> https://github.com/csound/csound/blob/csound5_17_3/Opcodes/fout.c
>
> in case that's useful to compare.
>
> I tried to spend a little time with gdb. If I put in a break at
> fout_open_file, then bt, I get:
>
> #0  fout_open_file (csound=csound@entry=0xd40080, p=p@entry=0x0,
>     fp=fp@entry=0x66fc68, fileType=fileType@entry=3, iFile=0x3df2558,
>     isString=isString@entry=1, fileParams=0x6c7d63df ,
>     forceSync=forceSync@entry=1)
>     at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:75
> #1  0x000000006c611337 in fiopen_ (csound=0xd40080, p=0x3dffe28, istring=1)
>     at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:620
> #2  0x000000006c511079 in init0 (csound=csound@entry=0xd40080)
>
> The error occurs before outfile_set is even called.  It's somewhat
> bizarre, if I comment out fout in the CSD, the fiopen call works.  If
> I put it back in, fiopen fails.
>
> On Tue, Oct 11, 2016 at 12:01 PM, jpff  wrote:
>> And the code -- fout.i can never work asit takesa andle and there is no way
>> of creating a CSFILE_SND_W file outside fout.
>>
>>
>> On Tue, 11 Oct 2016, Victor Lazzarini wrote:
>>
>>> Neither fout nor foutk can take a handle from fiopen currently, so we just
>>> remove that notice.
>>>
>>>
>>>> On 11 Oct 2016, at 15:56, jpff  wrote:
>>>>
>>>> Currently says
>>>>      Notice that fout and >>>      linkend="foutk">foutk can use
>>>>      either a string containing a file pathname, or a handle-number
>>>>      generated by >>>      linkend="fiopen">fiopen.
>>>>
>>>> f the part about fiopen is removed then there is no way of creating a
>>>> handle and so fout.i opcode can never happen.  Or we need to add
>>>> options to fiopen to create _W files
>>>>
>>>> ==John ffitch
>>>
>>>

I went back a bit further and fout from csound 5.00:

https://github.com/csound/csound/blob/csound-5.00.0/Opcodes/fout.c

Did not call fout_open_file when a filehandle was given. Perhaps that
changed somewhere and that's causing the issues now?

On Tue, Oct 11, 2016 at 12:54 PM, Steven Yi  wrote:
> Sorry, I realize now the error has to do with textXXXX.aiff already
> existing after the previous run. When I delete that and restart I do
> get into outfile_set.
>
> On Tue, Oct 11, 2016 at 12:43 PM, Steven Yi  wrote:
>> Just for reference, the code from Csound 5 can be viewed here:
>>
>> https://github.com/csound/csound/blob/csound5_17_3/Opcodes/fout.c
>>
>> in case that's useful to compare.
>>
>> I tried to spend a little time with gdb. If I put in a break at
>> fout_open_file, then bt, I get:
>>
>> #0  fout_open_file (csound=csound@entry=0xd40080, p=p@entry=0x0,
>>     fp=fp@entry=0x66fc68, fileType=fileType@entry=3, iFile=0x3df2558,
>>     isString=isString@entry=1, fileParams=0x6c7d63df ,
>>     forceSync=forceSync@entry=1)
>>     at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:75
>> #1  0x000000006c611337 in fiopen_ (csound=0xd40080, p=0x3dffe28, istring=1)
>>     at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:620
>> #2  0x000000006c511079 in init0 (csound=csound@entry=0xd40080)
>>
>> The error occurs before outfile_set is even called.  It's somewhat
>> bizarre, if I comment out fout in the CSD, the fiopen call works.  If
>> I put it back in, fiopen fails.
>>
>> On Tue, Oct 11, 2016 at 12:01 PM, jpff  wrote:
>>> And the code -- fout.i can never work asit takesa andle and there is no way
>>> of creating a CSFILE_SND_W file outside fout.
>>>
>>>
>>> On Tue, 11 Oct 2016, Victor Lazzarini wrote:
>>>
>>>> Neither fout nor foutk can take a handle from fiopen currently, so we just
>>>> remove that notice.
>>>>
>>>>
>>>>> On 11 Oct 2016, at 15:56, jpff  wrote:
>>>>>
>>>>> Currently says
>>>>>      Notice that fout and >>>>      linkend="foutk">foutk can use
>>>>>      either a string containing a file pathname, or a handle-number
>>>>>      generated by >>>>      linkend="fiopen">fiopen.
>>>>>
>>>>> f the part about fiopen is removed then there is no way of creating a
>>>>> handle and so fout.i opcode can never happen.  Or we need to add
>>>>> options to fiopen to create _W files
>>>>>
>>>>> ==John ffitch
>>>>
>>>>

This code will behave exactly as the current
in this respect. So no changes from 5 to 6
prompted the behaviour.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 11 Oct 2016, at 17:44, Steven Yi  wrote:
> 
> Just for reference, the code from Csound 5 can be viewed here:
> 
> https://github.com/csound/csound/blob/csound5_17_3/Opcodes/fout.c
> 
> in case that's useful to compare.
> 
> I tried to spend a little time with gdb. If I put in a break at
> fout_open_file, then bt, I get:
> 
> #0  fout_open_file (csound=csound@entry=0xd40080, p=p@entry=0x0,
>    fp=fp@entry=0x66fc68, fileType=fileType@entry=3, iFile=0x3df2558,
>    isString=isString@entry=1, fileParams=0x6c7d63df ,
>    forceSync=forceSync@entry=1)
>    at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:75
> #1  0x000000006c611337 in fiopen_ (csound=0xd40080, p=0x3dffe28, istring=1)
>    at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:620
> #2  0x000000006c511079 in init0 (csound=csound@entry=0xd40080)
> 
> The error occurs before outfile_set is even called.  It's somewhat
> bizarre, if I comment out fout in the CSD, the fiopen call works.  If
> I put it back in, fiopen fails.
> 
>> On Tue, Oct 11, 2016 at 12:01 PM, jpff  wrote:
>> And the code -- fout.i can never work asit takesa andle and there is no way
>> of creating a CSFILE_SND_W file outside fout.
>> 
>> 
>>> On Tue, 11 Oct 2016, Victor Lazzarini wrote:
>>> 
>>> Neither fout nor foutk can take a handle from fiopen currently, so we just
>>> remove that notice.
>>> 
>>> 
>>>> On 11 Oct 2016, at 15:56, jpff  wrote:
>>>> 
>>>> Currently says
>>>>     Notice that fout and >>>     linkend="foutk">foutk can use
>>>>     either a string containing a file pathname, or a handle-number
>>>>     generated by >>>     linkend="fiopen">fiopen.
>>>> 
>>>> f the part about fiopen is removed then there is no way of creating a
>>>> handle and so fout.i opcode can never happen.  Or we need to add
>>>> options to fiopen to create _W files
>>>> 
>>>> ==John ffitch
>>> 
>>> 

Yes, the 5.17 code is not different, but the 5.00 code does appear to
have different behavior.

On Tue, Oct 11, 2016 at 2:06 PM, Victor Lazzarini
 wrote:
> This code will behave exactly as the current
> in this respect. So no changes from 5 to 6
> prompted the behaviour.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 11 Oct 2016, at 17:44, Steven Yi  wrote:
>>
>> Just for reference, the code from Csound 5 can be viewed here:
>>
>> https://github.com/csound/csound/blob/csound5_17_3/Opcodes/fout.c
>>
>> in case that's useful to compare.
>>
>> I tried to spend a little time with gdb. If I put in a break at
>> fout_open_file, then bt, I get:
>>
>> #0  fout_open_file (csound=csound@entry=0xd40080, p=p@entry=0x0,
>>    fp=fp@entry=0x66fc68, fileType=fileType@entry=3, iFile=0x3df2558,
>>    isString=isString@entry=1, fileParams=0x6c7d63df ,
>>    forceSync=forceSync@entry=1)
>>    at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:75
>> #1  0x000000006c611337 in fiopen_ (csound=0xd40080, p=0x3dffe28, istring=1)
>>    at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:620
>> #2  0x000000006c511079 in init0 (csound=csound@entry=0xd40080)
>>
>> The error occurs before outfile_set is even called.  It's somewhat
>> bizarre, if I comment out fout in the CSD, the fiopen call works.  If
>> I put it back in, fiopen fails.
>>
>>> On Tue, Oct 11, 2016 at 12:01 PM, jpff  wrote:
>>> And the code -- fout.i can never work asit takesa andle and there is no way
>>> of creating a CSFILE_SND_W file outside fout.
>>>
>>>
>>>> On Tue, 11 Oct 2016, Victor Lazzarini wrote:
>>>>
>>>> Neither fout nor foutk can take a handle from fiopen currently, so we just
>>>> remove that notice.
>>>>
>>>>
>>>>> On 11 Oct 2016, at 15:56, jpff  wrote:
>>>>>
>>>>> Currently says
>>>>>     Notice that fout and >>>>     linkend="foutk">foutk can use
>>>>>     either a string containing a file pathname, or a handle-number
>>>>>     generated by >>>>     linkend="fiopen">fiopen.
>>>>>
>>>>> f the part about fiopen is removed then there is no way of creating a
>>>>> handle and so fout.i opcode can never happen.  Or we need to add
>>>>> options to fiopen to create _W files
>>>>>
>>>>> ==John ffitch
>>>>
>>>>

yes, this is different. If you open with fiopen,
fout will use this and write to the std file
(not a soundfile).

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 11 Oct 2016, at 18:22, Steven Yi  wrote:
> 
> I went back a bit further and fout from csound 5.00:
> 
> https://github.com/csound/csound/blob/csound-5.00.0/Opcodes/fout.c
> 
> Did not call fout_open_file when a filehandle was given. Perhaps that
> changed somewhere and that's causing the issues now?
> 
>> On Tue, Oct 11, 2016 at 12:54 PM, Steven Yi  wrote:
>> Sorry, I realize now the error has to do with textXXXX.aiff already
>> existing after the previous run. When I delete that and restart I do
>> get into outfile_set.
>> 
>>> On Tue, Oct 11, 2016 at 12:43 PM, Steven Yi  wrote:
>>> Just for reference, the code from Csound 5 can be viewed here:
>>> 
>>> https://github.com/csound/csound/blob/csound5_17_3/Opcodes/fout.c
>>> 
>>> in case that's useful to compare.
>>> 
>>> I tried to spend a little time with gdb. If I put in a break at
>>> fout_open_file, then bt, I get:
>>> 
>>> #0  fout_open_file (csound=csound@entry=0xd40080, p=p@entry=0x0,
>>>    fp=fp@entry=0x66fc68, fileType=fileType@entry=3, iFile=0x3df2558,
>>>    isString=isString@entry=1, fileParams=0x6c7d63df ,
>>>    forceSync=forceSync@entry=1)
>>>    at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:75
>>> #1  0x000000006c611337 in fiopen_ (csound=0xd40080, p=0x3dffe28, istring=1)
>>>    at C:/msys64/home/stevenyi/work/csound/csound/Opcodes/fout.c:620
>>> #2  0x000000006c511079 in init0 (csound=csound@entry=0xd40080)
>>> 
>>> The error occurs before outfile_set is even called.  It's somewhat
>>> bizarre, if I comment out fout in the CSD, the fiopen call works.  If
>>> I put it back in, fiopen fails.
>>> 
>>>> On Tue, Oct 11, 2016 at 12:01 PM, jpff  wrote:
>>>> And the code -- fout.i can never work asit takesa andle and there is no way
>>>> of creating a CSFILE_SND_W file outside fout.
>>>> 
>>>> 
>>>>> On Tue, 11 Oct 2016, Victor Lazzarini wrote:
>>>>> 
>>>>> Neither fout nor foutk can take a handle from fiopen currently, so we just
>>>>> remove that notice.
>>>>> 
>>>>> 
>>>>>> On 11 Oct 2016, at 15:56, jpff  wrote:
>>>>>> 
>>>>>> Currently says
>>>>>>     Notice that fout and >>>>>     linkend="foutk">foutk can use
>>>>>>     either a string containing a file pathname, or a handle-number
>>>>>>     generated by >>>>>     linkend="fiopen">fiopen.
>>>>>> 
>>>>>> f the part about fiopen is removed then there is no way of creating a
>>>>>> handle and so fout.i opcode can never happen.  Or we need to add
>>>>>> options to fiopen to create _W files
>>>>>> 
>>>>>> ==John ffitch
>>>>> 
>>>>>