First apologies for my messed up last message -- I had typed an answer
but decided it was rubbish bur hit the wrong key in aborting it.

I am totally unsure what the complaint is here.  In "normal" csound
use an e-opcode is added to the score, and is later interrogated to see
i the infinite score was expected and adjusted to match. This commit
just makes the API the same as csound.

If this is not the case I need a complete example.  I have no examples
here of using the PI so constructing a test against an unknown problem
is hard.

==John ff


> After this commit

> index 9b95674df..bf4c58881 100644
> @@ -2062,7 +2062,7 @@ int csoundReadScoreInternal(CSOUND *csound,
> const char *str)
>      csound->scorestr = corfile_create_w(csound);
>      corfile_puts(csound, (char *)str, csound->scorestr);
>      //#ifdef SCORE_PARSER
> -    corfile_puts(csound, "\n#exit\n", csound->scorestr);
> +    corfile_puts(csound, "\ne\n#exit\n", csound->scorestr);
>      //#endif
>      corfile_flush(csound, csound->scorestr);
>      /* copy sorted score name */

> After this change, all pieces using the API calls shown below, exit
> immediately upon calling csoundPerformKsmps. It used to be that with
> this sequence of calls, pieces would perform indefinitely, even if
> there were no pending score events, thus permitting the user to send
> score events at any time during an indefinite performance.

> I suspect a mistake in sending the "e" opcode in all cases.

> Regards,
> Mike

>     csound = csoundCreate(0);
>     csoundSetOption(csound, "-d");
>     csoundSetOption(csound, "-m167");
>     csoundSetOption(csound, "-odac");
>     csoundCompileOrc(csound, orc);
>     csoundReadScore(csound, sco);
>     csoundStart(csound);
>     while ((result = csoundPerformKsmps(csound)) == 0) {};
>     csoundDestroy(csound);


> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com

typo PI -> API

On Tue, 15 May 2018, Michael Gogins wrote:

> This is not about the Pi. I will send you my complete example soon. 
> Regards, 
> Mike
> 
> On Tue, May 15, 2018, 15:48 John  wrote:
>       First apologies for my messed up last message -- I had typed an
>       answer
>       but decided it was rubbish bur hit the wrong key in aborting it.
>
>       I am totally unsure what the complaint is here.  In "normal"
>       csound
>       use an e-opcode is added to the score, and is later interrogated
>       to see
>       i the infinite score was expected and adjusted to match. This
>       commit
>       just makes the API the same as csound.
>
>       If this is not the case I need a complete example.  I have no
>       examples
>       here of using the PI so constructing a test against an unknown
>       problem
>       is hard.
>
>       ==John ff
> k

I have not tested this, but I would expect that, given no score, performance goes on
forever.

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

> On 15 May 2018, at 20:48, John  wrote:
> 
> First apologies for my messed up last message -- I had typed an answer
> but decided it was rubbish bur hit the wrong key in aborting it.
> 
> I am totally unsure what the complaint is here.  In "normal" csound
> use an e-opcode is added to the score, and is later interrogated to see
> i the infinite score was expected and adjusted to match. This commit
> just makes the API the same as csound.
> 
> If this is not the case I need a complete example.  I have no examples
> here of using the PI so constructing a test against an unknown problem
> is hard.
> 
> ==John ff
> 
> 
>> After this commit
> 
>> index 9b95674df..bf4c58881 100644
>> @@ -2062,7 +2062,7 @@ int csoundReadScoreInternal(CSOUND *csound,
>> const char *str)
>>     csound->scorestr = corfile_create_w(csound);
>>     corfile_puts(csound, (char *)str, csound->scorestr);
>>     //#ifdef SCORE_PARSER
>> -    corfile_puts(csound, "\n#exit\n", csound->scorestr);
>> +    corfile_puts(csound, "\ne\n#exit\n", csound->scorestr);
>>     //#endif
>>     corfile_flush(csound, csound->scorestr);
>>     /* copy sorted score name */
> 
>> After this change, all pieces using the API calls shown below, exit
>> immediately upon calling csoundPerformKsmps. It used to be that with
>> this sequence of calls, pieces would perform indefinitely, even if
>> there were no pending score events, thus permitting the user to send
>> score events at any time during an indefinite performance.
> 
>> I suspect a mistake in sending the "e" opcode in all cases.
> 
>> Regards,
>> Mike
> 
>>    csound = csoundCreate(0);
>>    csoundSetOption(csound, "-d");
>>    csoundSetOption(csound, "-m167");
>>    csoundSetOption(csound, "-odac");
>>    csoundCompileOrc(csound, orc);
>>    csoundReadScore(csound, sco);
>>    csoundStart(csound);
>>    while ((result = csoundPerformKsmps(csound)) == 0) {};
>>    csoundDestroy(csound);
> 
> 
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com

So would I

On Tue, 15 May 2018, Victor Lazzarini wrote:

> I have not tested this, but I would expect that, given no score, performance goes on
> forever.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 15 May 2018, at 20:48, John  wrote:
>>
>> First apologies for my messed up last message -- I had typed an answer
>> but decided it was rubbish bur hit the wrong key in aborting it.
>>
>> I am totally unsure what the complaint is here.  In "normal" csound
>> use an e-opcode is added to the score, and is later interrogated to see
>> i the infinite score was expected and adjusted to match. This commit
>> just makes the API the same as csound.
>>
>> If this is not the case I need a complete example.  I have no examples
>> here of using the PI so constructing a test against an unknown problem
>> is hard.
>>
>> ==John ff
>>
>>
>>> After this commit
>>
>>> index 9b95674df..bf4c58881 100644
>>> @@ -2062,7 +2062,7 @@ int csoundReadScoreInternal(CSOUND *csound,
>>> const char *str)
>>>     csound->scorestr = corfile_create_w(csound);
>>>     corfile_puts(csound, (char *)str, csound->scorestr);
>>>     //#ifdef SCORE_PARSER
>>> -    corfile_puts(csound, "\n#exit\n", csound->scorestr);
>>> +    corfile_puts(csound, "\ne\n#exit\n", csound->scorestr);
>>>     //#endif
>>>     corfile_flush(csound, csound->scorestr);
>>>     /* copy sorted score name */
>>
>>> After this change, all pieces using the API calls shown below, exit
>>> immediately upon calling csoundPerformKsmps. It used to be that with
>>> this sequence of calls, pieces would perform indefinitely, even if
>>> there were no pending score events, thus permitting the user to send
>>> score events at any time during an indefinite performance.
>>
>>> I suspect a mistake in sending the "e" opcode in all cases.
>>
>>> Regards,
>>> Mike
>>
>>>    csound = csoundCreate(0);
>>>    csoundSetOption(csound, "-d");
>>>    csoundSetOption(csound, "-m167");
>>>    csoundSetOption(csound, "-odac");
>>>    csoundCompileOrc(csound, orc);
>>>    csoundReadScore(csound, sco);
>>>    csoundStart(csound);
>>>    while ((result = csoundPerformKsmps(csound)) == 0) {};
>>>    csoundDestroy(csound);
>>
>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com

I am having trouble getting to the bottom of this. There is no
question that removing the "e" opcode from the commit enables some of
my HTML5 Csound pieces to perform properly, but with the "e" opcode
they do not perform. However, I am having a hard time coming up with a
cut-down example that reproduces the problem.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, May 15, 2018 at 4:11 PM, jpff  wrote:
> So would I
>
>
> On Tue, 15 May 2018, Victor Lazzarini wrote:
>
>> I have not tested this, but I would expect that, given no score,
>> performance goes on
>> forever.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>>> On 15 May 2018, at 20:48, John  wrote:
>>>
>>> First apologies for my messed up last message -- I had typed an answer
>>> but decided it was rubbish bur hit the wrong key in aborting it.
>>>
>>> I am totally unsure what the complaint is here.  In "normal" csound
>>> use an e-opcode is added to the score, and is later interrogated to see
>>> i the infinite score was expected and adjusted to match. This commit
>>> just makes the API the same as csound.
>>>
>>> If this is not the case I need a complete example.  I have no examples
>>> here of using the PI so constructing a test against an unknown problem
>>> is hard.
>>>
>>> ==John ff
>>>
>>>
>>>> After this commit
>>>
>>>
>>>> index 9b95674df..bf4c58881 100644
>>>> @@ -2062,7 +2062,7 @@ int csoundReadScoreInternal(CSOUND *csound,
>>>> const char *str)
>>>>     csound->scorestr = corfile_create_w(csound);
>>>>     corfile_puts(csound, (char *)str, csound->scorestr);
>>>>     //#ifdef SCORE_PARSER
>>>> -    corfile_puts(csound, "\n#exit\n", csound->scorestr);
>>>> +    corfile_puts(csound, "\ne\n#exit\n", csound->scorestr);
>>>>     //#endif
>>>>     corfile_flush(csound, csound->scorestr);
>>>>     /* copy sorted score name */
>>>
>>>
>>>> After this change, all pieces using the API calls shown below, exit
>>>> immediately upon calling csoundPerformKsmps. It used to be that with
>>>> this sequence of calls, pieces would perform indefinitely, even if
>>>> there were no pending score events, thus permitting the user to send
>>>> score events at any time during an indefinite performance.
>>>
>>>
>>>> I suspect a mistake in sending the "e" opcode in all cases.
>>>
>>>
>>>> Regards,
>>>> Mike
>>>
>>>
>>>>    csound = csoundCreate(0);
>>>>    csoundSetOption(csound, "-d");
>>>>    csoundSetOption(csound, "-m167");
>>>>    csoundSetOption(csound, "-odac");
>>>>    csoundCompileOrc(csound, orc);
>>>>    csoundReadScore(csound, sco);
>>>>    csoundStart(csound);
>>>>    while ((result = csoundPerformKsmps(csound)) == 0) {};
>>>>    csoundDestroy(csound);
>>>
>>>
>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>
>>

All right, attached is a C program that reproduces the error, along
with log files for test cases.

For performance_mode_with_e.txt, csound.c line 2065 is:
corfile_puts(csound, "\ne\n#exit\n", csound->scorestr);

For performance_mode_without_e.txt, csound.c line 2065 is:
corfile_puts(csound, "\n#exit\n", csound->scorestr);

At the top of my program is a shell command that should build the
program, which is completely self-contained. Compile with -std=gnu11,
which enables embedding the Csound orc and sco as multi-line string
constants in the C source file.

The use case is to compile an orc, run Csound without a sco for a bit,
then send Csound one or more sco texts to perform. This is what I have
been doing for years for visual music and other interactive Csound
pieces.

Before commit 926499aa96643dadafd00ce036b908488f81f79b, this worked
fine. Now, Csound exits at the first call to csoundPerformKsmps.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, May 15, 2018 at 8:44 PM, Michael Gogins
 wrote:
> I am having trouble getting to the bottom of this. There is no
> question that removing the "e" opcode from the commit enables some of
> my HTML5 Csound pieces to perform properly, but with the "e" opcode
> they do not perform. However, I am having a hard time coming up with a
> cut-down example that reproduces the problem.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, May 15, 2018 at 4:11 PM, jpff  wrote:
>> So would I
>>
>>
>> On Tue, 15 May 2018, Victor Lazzarini wrote:
>>
>>> I have not tested this, but I would expect that, given no score,
>>> performance goes on
>>> forever.
>>>
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>>
>>>> On 15 May 2018, at 20:48, John  wrote:
>>>>
>>>> First apologies for my messed up last message -- I had typed an answer
>>>> but decided it was rubbish bur hit the wrong key in aborting it.
>>>>
>>>> I am totally unsure what the complaint is here.  In "normal" csound
>>>> use an e-opcode is added to the score, and is later interrogated to see
>>>> i the infinite score was expected and adjusted to match. This commit
>>>> just makes the API the same as csound.
>>>>
>>>> If this is not the case I need a complete example.  I have no examples
>>>> here of using the PI so constructing a test against an unknown problem
>>>> is hard.
>>>>
>>>> ==John ff
>>>>
>>>>
>>>>> After this commit
>>>>
>>>>
>>>>> index 9b95674df..bf4c58881 100644
>>>>> @@ -2062,7 +2062,7 @@ int csoundReadScoreInternal(CSOUND *csound,
>>>>> const char *str)
>>>>>     csound->scorestr = corfile_create_w(csound);
>>>>>     corfile_puts(csound, (char *)str, csound->scorestr);
>>>>>     //#ifdef SCORE_PARSER
>>>>> -    corfile_puts(csound, "\n#exit\n", csound->scorestr);
>>>>> +    corfile_puts(csound, "\ne\n#exit\n", csound->scorestr);
>>>>>     //#endif
>>>>>     corfile_flush(csound, csound->scorestr);
>>>>>     /* copy sorted score name */
>>>>
>>>>
>>>>> After this change, all pieces using the API calls shown below, exit
>>>>> immediately upon calling csoundPerformKsmps. It used to be that with
>>>>> this sequence of calls, pieces would perform indefinitely, even if
>>>>> there were no pending score events, thus permitting the user to send
>>>>> score events at any time during an indefinite performance.
>>>>
>>>>
>>>>> I suspect a mistake in sending the "e" opcode in all cases.
>>>>
>>>>
>>>>> Regards,
>>>>> Mike
>>>>
>>>>
>>>>>    csound = csoundCreate(0);
>>>>>    csoundSetOption(csound, "-d");
>>>>>    csoundSetOption(csound, "-m167");
>>>>>    csoundSetOption(csound, "-odac");
>>>>>    csoundCompileOrc(csound, orc);
>>>>>    csoundReadScore(csound, sco);
>>>>>    csoundStart(csound);
>>>>>    while ((result = csoundPerformKsmps(csound)) == 0) {};
>>>>>    csoundDestroy(csound);
>>>>
>>>>
>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>

I get totakly different beaviour with the e in the score


C S O U N D   P E R F O R M A N C E   M O D E
By Michael Gogins

This program demonstrates Csound performance modes ('real-time' vs. 'non-real-time').
It attempts to answer questions that remain after reading documentation and source code.


Testing csoundCompileCsdText...

0dBFS level = 32768.0
--Csound version 6.11 (double samples) Jan 28 2018 
[commit: 30810e2f5f345b2a09578ef316d0d63f2a4c1423]
libsndfile-1.0.29pre1
STARTING FILE
Creating options
Creating orchestra
closing tag
Creating score
instr Harpsichord uses instrument number 1
instr Buzzer uses instrument number 2
rtaudio: ALSA module enabled
rtmidi: ALSA Raw MIDI module enabled
displays suppressed
0dBFS level = 32768.0
ftable 101:
ftable 102:
orch now loaded
audio buffered in 256 sample-frame blocks
ALSA output: total buffer size: 1024, period size: 256
writing 512 sample blks of 64-bit floats to dac 
SECTION 1:
B  0.000 ..  0.100 T  0.100 TT  0.100 M:      0        0 
new alloc for instr Harpsichord:
WARNING: instr Harpsichord uses 11 p-fields but is given 5
instr    1 t    0.1000 d    0.8050 k   60.0000 v   60.0000 p    0.0000
B  0.100 ..  0.200 T  0.200 TT  0.200 M:    -9.63   -17.29
new alloc for instr Buzzer:
WARNING: instr Buzzer uses 11 p-fields but is given 5
instr    2 t    0.2000 d    0.7000 k   64.0000 v   60.0000 p    0.0000
B  0.200 ..  0.300 T  0.300 TT  0.300 M:    -7.44   -15.10
new alloc for instr Buzzer:
WARNING: instr Buzzer uses 11 p-fields but is given 5
instr    2 t    0.3000 d    0.7000 k   67.0000 v   60.0000 p    0.0000
B  0.300 ..  0.400 T  0.400 TT  0.400 M:    -2.81   -10.47
new alloc for instr Harpsichord:
WARNING: instr Harpsichord uses 11 p-fields but is given 5
instr    1 t    0.4000 d    0.8050 k   71.0000 v   60.0000 p    0.0000
B  0.400 ..  0.700 T  0.900 TT  0.900 M:    -1.45    -9.11
B  0.700 ..  0.600 T  0.905 TT  0.905 M:   -10.63   -18.28
B  0.600 ..  0.950 T  0.950 TT  0.950 M:    -7.33   -14.99
B  0.950 ..  0.800 T  1.000 TT  1.000 M:   -13.33   -20.98
B  0.800 ..  1.050 T  1.050 TT  1.050 M:   -18.04   -25.69
B  1.050 ..  0.900 T  1.205 TT  1.205 M:   -19.27   -26.93
B  0.900 ..  1.506 T  1.506 TT  1.506 M:   -22.59   -30.24
Score finished in csoundPerformKsmps() with 2.
inactive allocs returned to freespace
end of score.		   overall amps:    -1.45    -9.11
 	   overall samples out of range:        0        0
0 errors in performance
Elapsed time at end of performance: real: 1.501s, CPU: 0.140s
519 512 sample blks of 64-bit floats written to dac


Testing csoundCompileOrc...

0dBFS level = 32768.0
--Csound version 6.11 (double samples) Jan 28 2018 
[commit: 30810e2f5f345b2a09578ef316d0d63f2a4c1423]
libsndfile-1.0.29pre1
instr Harpsichord uses instrument number 1
instr Buzzer uses instrument number 2
Reading options from $HOME/.csound6rc
Reading options from local directory .csound6rc 
rtaudio: pulseaudio module enabled
rtmidi: ALSA Raw MIDI module enabled
displays suppressed
0dBFS level = 32768.0
ftable 101:
ftable 102:
orch now loaded
audio buffered in 256 sample-frame blocks
PulseAudio output server: default
pulseaudio output open
writing 512 sample blks of 64-bit floats to dac 
SECTION 1:
   rtevent:	   T  0.214 TT  0.214 M:      0        0 
new alloc for instr Harpsichord:
WARNING: instr Harpsichord uses 11 p-fields but is given 5
instr    1 t    0.2145 d    0.8050 k   60.0000 v   60.0000 p    0.0000
  rtevent:	   T  0.314 TT  0.314 M:    -9.63   -17.29
new alloc for instr Buzzer:
WARNING: instr Buzzer uses 11 p-fields but is given 5
instr    2 t    0.3145 d    0.7000 k   64.0000 v   60.0000 p    0.0000
  rtevent:	   T  0.415 TT  0.415 M:    -7.44   -15.10
new alloc for instr Buzzer:
WARNING: instr Buzzer uses 11 p-fields but is given 5
instr    2 t    0.4145 d    0.7000 k   67.0000 v   60.0000 p    0.0000
  rtevent:	   T  0.515 TT  0.515 M:    -2.81   -10.47
new alloc for instr Harpsichord:
WARNING: instr Harpsichord uses 11 p-fields but is given 5
instr    1 t    0.5145 d    0.8050 k   71.0000 v   60.0000 p    0.0000

A




Not worked out hat te br

I'm sorry, but I can't understand your email.

What do you mean, "e in the score?" Do you mean with "e" in csound.c?

What do you mean, "Not worked out hat te br program is doing yet"?

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Wed, May 16, 2018 at 4:38 PM, jpff  wrote:
> I get totakly different beaviour with the e in the score
>
>
> C S O U N D   P E R F O R M A N C E   M O D E
> By Michael Gogins
>
> This program demonstrates Csound performance modes ('real-time' vs.
> 'non-real-time').
> It attempts to answer questions that remain after reading documentation and
> source code.
>
>
> Testing csoundCompileCsdText...
>
> 0dBFS level = 32768.0
> --Csound version 6.11 (double samples) Jan 28 2018 [commit:
> 30810e2f5f345b2a09578ef316d0d63f2a4c1423]
> libsndfile-1.0.29pre1
> STARTING FILE
> Creating options
> Creating orchestra
> closing tag
> Creating score
> instr Harpsichord uses instrument number 1
> instr Buzzer uses instrument number 2
> rtaudio: ALSA module enabled
> rtmidi: ALSA Raw MIDI module enabled
> displays suppressed
> 0dBFS level = 32768.0
> ftable 101:
> ftable 102:
> orch now loaded
> audio buffered in 256 sample-frame blocks
> ALSA output: total buffer size: 1024, period size: 256
> writing 512 sample blks of 64-bit floats to dac SECTION 1:
> B  0.000 ..  0.100 T  0.100 TT  0.100 M:      0        0 new alloc for instr
> Harpsichord:
> WARNING:  [minstr Harpsichord uses 11 p-fields but is given 5 [m
> [minstr    1 t    0.1000 d    0.8050 k   60.0000 v   60.0000 p    0.0000
> [mB  0.100 ..  0.200 T  0.200 TT  0.200 M:    -9.63   -17.29
> new alloc for instr Buzzer:
> WARNING:  [minstr Buzzer uses 11 p-fields but is given 5 [m
> [minstr    2 t    0.2000 d    0.7000 k   64.0000 v   60.0000 p    0.0000
> [mB  0.200 ..  0.300 T  0.300 TT  0.300 M:    -7.44   -15.10
> new alloc for instr Buzzer:
> WARNING:  [minstr Buzzer uses 11 p-fields but is given 5 [m
> [minstr    2 t    0.3000 d    0.7000 k   67.0000 v   60.0000 p    0.0000
> [mB  0.300 ..  0.400 T  0.400 TT  0.400 M:    -2.81   -10.47
> new alloc for instr Harpsichord:
> WARNING:  [minstr Harpsichord uses 11 p-fields but is given 5 [m
> [minstr    1 t    0.4000 d    0.8050 k   71.0000 v   60.0000 p    0.0000
> [mB  0.400 ..  0.700 T  0.900 TT  0.900 M:    -1.45    -9.11
> B  0.700 ..  0.600 T  0.905 TT  0.905 M:   -10.63   -18.28
> B  0.600 ..  0.950 T  0.950 TT  0.950 M:    -7.33   -14.99
> B  0.950 ..  0.800 T  1.000 TT  1.000 M:   -13.33   -20.98
> B  0.800 ..  1.050 T  1.050 TT  1.050 M:   -18.04   -25.69
> B  1.050 ..  0.900 T  1.205 TT  1.205 M:   -19.27   -26.93
> B  0.900 ..  1.506 T  1.506 TT  1.506 M:   -22.59   -30.24
> Score finished in csoundPerformKsmps() with 2.
> inactive allocs returned to freespace
> end of score.              overall amps:    -1.45    -9.11
>            overall samples out of range:        0        0
> 0 errors in performance
> Elapsed time at end of performance: real: 1.501s, CPU: 0.140s
> 519 512 sample blks of 64-bit floats written to dac
>
>
> Testing csoundCompileOrc...
>
> 0dBFS level = 32768.0
> --Csound version 6.11 (double samples) Jan 28 2018 [commit:
> 30810e2f5f345b2a09578ef316d0d63f2a4c1423]
> libsndfile-1.0.29pre1
> instr Harpsichord uses instrument number 1
> instr Buzzer uses instrument number 2
> Reading options from $HOME/.csound6rc
> Reading options from local directory .csound6rc rtaudio: pulseaudio module
> enabled
> rtmidi: ALSA Raw MIDI module enabled
> displays suppressed
> 0dBFS level = 32768.0
> ftable 101:
> ftable 102:
> orch now loaded
> audio buffered in 256 sample-frame blocks
> PulseAudio output server: default
> pulseaudio output open
> writing 512 sample blks of 64-bit floats to dac SECTION 1:
>   rtevent:         T  0.214 TT  0.214 M:      0        0 new alloc for instr
> Harpsichord:
> WARNING:  [minstr Harpsichord uses 11 p-fields but is given 5 [m
> [minstr    1 t    0.2145 d    0.8050 k   60.0000 v   60.0000 p    0.0000
> [m  rtevent:       T  0.314 TT  0.314 M:    -9.63   -17.29
> new alloc for instr Buzzer:
> WARNING:  [minstr Buzzer uses 11 p-fields but is given 5 [m
> [minstr    2 t    0.3145 d    0.7000 k   64.0000 v   60.0000 p    0.0000
> [m  rtevent:       T  0.415 TT  0.415 M:    -7.44   -15.10
> new alloc for instr Buzzer:
> WARNING:  [minstr Buzzer uses 11 p-fields but is given 5 [m
> [minstr    2 t    0.4145 d    0.7000 k   67.0000 v   60.0000 p    0.0000
> [m  rtevent:       T  0.515 TT  0.515 M:    -2.81   -10.47
> new alloc for instr Harpsichord:
> WARNING:  [minstr Harpsichord uses 11 p-fields but is given 5 [m
> [minstr    1 t    0.5145 d    0.8050 k   71.0000 v   60.0000 p    0.0000
> [m
> A
>
>
>
>
> Not worked out hat te br

Sorry.  My attempt yesterday was flawed as I picked up old versions of the libcsound64.  Will try again.

⁣Sent from TypeApp ​

On May 16, 2018, 21:54, at 21:54, Michael Gogins  wrote:
>I'm sorry, but I can't understand your email.
>
>What do you mean, "e in the score?" Do you mean with "e" in csound.c?
>
>What do you mean, "Not worked out hat te br program is doing yet"?
>
>Regards,
>Mike
>
>-----------------------------------------------------
>Michael Gogins
>Irreducible Productions
>http://michaelgogins.tumblr.com
>Michael dot Gogins at gmail dot com
>
>
>On Wed, May 16, 2018 at 4:38 PM, jpff  wrote:
>> I get totakly different beaviour with the e in the score
>>
>>
>> C S O U N D   P E R F O R M A N C E   M O D E
>> By Michael Gogins
>>
>> This program demonstrates Csound performance modes ('real-time' vs.
>> 'non-real-time').
>> It attempts to answer questions that remain after reading
>documentation and
>> source code.
>>
>>
>> Testing csoundCompileCsdText...
>>
>> 0dBFS level = 32768.0
>> --Csound version 6.11 (double samples) Jan 28 2018 [commit:
>> 30810e2f5f345b2a09578ef316d0d63f2a4c1423]
>> libsndfile-1.0.29pre1
>> STARTING FILE
>> Creating options
>> Creating orchestra
>> closing tag
>> Creating score
>> instr Harpsichord uses instrument number 1
>> instr Buzzer uses instrument number 2
>> rtaudio: ALSA module enabled
>> rtmidi: ALSA Raw MIDI module enabled
>> displays suppressed
>> 0dBFS level = 32768.0
>> ftable 101:
>> ftable 102:
>> orch now loaded
>> audio buffered in 256 sample-frame blocks
>> ALSA output: total buffer size: 1024, period size: 256
>> writing 512 sample blks of 64-bit floats to dac SECTION 1:
>> B  0.000 ..  0.100 T  0.100 TT  0.100 M:      0        0 new alloc
>for instr
>> Harpsichord:
>> WARNING:  [minstr Harpsichord uses 11 p-fields but is given 5 [m
>> [minstr    1 t    0.1000 d    0.8050 k   60.0000 v   60.0000 p   
>0.0000
>> [mB  0.100 ..  0.200 T  0.200 TT  0.200 M:    -9.63   -17.29
>> new alloc for instr Buzzer:
>> WARNING:  [minstr Buzzer uses 11 p-fields but is given 5 [m
>> [minstr    2 t    0.2000 d    0.7000 k   64.0000 v   60.0000 p   
>0.0000
>> [mB  0.200 ..  0.300 T  0.300 TT  0.300 M:    -7.44   -15.10
>> new alloc for instr Buzzer:
>> WARNING:  [minstr Buzzer uses 11 p-fields but is given 5 [m
>> [minstr    2 t    0.3000 d    0.7000 k   67.0000 v   60.0000 p   
>0.0000
>> [mB  0.300 ..  0.400 T  0.400 TT  0.400 M:    -2.81   -10.47
>> new alloc for instr Harpsichord:
>> WARNING:  [minstr Harpsichord uses 11 p-fields but is given 5 [m
>> [minstr    1 t    0.4000 d    0.8050 k   71.0000 v   60.0000 p   
>0.0000
>> [mB  0.400 ..  0.700 T  0.900 TT  0.900 M:    -1.45    -9.11
>> B  0.700 ..  0.600 T  0.905 TT  0.905 M:   -10.63   -18.28
>> B  0.600 ..  0.950 T  0.950 TT  0.950 M:    -7.33   -14.99
>> B  0.950 ..  0.800 T  1.000 TT  1.000 M:   -13.33   -20.98
>> B  0.800 ..  1.050 T  1.050 TT  1.050 M:   -18.04   -25.69
>> B  1.050 ..  0.900 T  1.205 TT  1.205 M:   -19.27   -26.93
>> B  0.900 ..  1.506 T  1.506 TT  1.506 M:   -22.59   -30.24
>> Score finished in csoundPerformKsmps() with 2.
>> inactive allocs returned to freespace
>> end of score.              overall amps:    -1.45    -9.11
>>            overall samples out of range:        0        0
>> 0 errors in performance
>> Elapsed time at end of performance: real: 1.501s, CPU: 0.140s
>> 519 512 sample blks of 64-bit floats written to dac
>>
>>
>> Testing csoundCompileOrc...
>>
>> 0dBFS level = 32768.0
>> --Csound version 6.11 (double samples) Jan 28 2018 [commit:
>> 30810e2f5f345b2a09578ef316d0d63f2a4c1423]
>> libsndfile-1.0.29pre1
>> instr Harpsichord uses instrument number 1
>> instr Buzzer uses instrument number 2
>> Reading options from $HOME/.csound6rc
>> Reading options from local directory .csound6rc rtaudio: pulseaudio
>module
>> enabled
>> rtmidi: ALSA Raw MIDI module enabled
>> displays suppressed
>> 0dBFS level = 32768.0
>> ftable 101:
>> ftable 102:
>> orch now loaded
>> audio buffered in 256 sample-frame blocks
>> PulseAudio output server: default
>> pulseaudio output open
>> writing 512 sample blks of 64-bit floats to dac SECTION 1:
>>   rtevent:         T  0.214 TT  0.214 M:      0        0 new alloc
>for instr
>> Harpsichord:
>> WARNING:  [minstr Harpsichord uses 11 p-fields but is given 5 [m
>> [minstr    1 t    0.2145 d    0.8050 k   60.0000 v   60.0000 p   
>0.0000
>> [m  rtevent:       T  0.314 TT  0.314 M:    -9.63   -17.29
>> new alloc for instr Buzzer:
>> WARNING:  [minstr Buzzer uses 11 p-fields but is given 5 [m
>> [minstr    2 t    0.3145 d    0.7000 k   64.0000 v   60.0000 p   
>0.0000
>> [m  rtevent:       T  0.415 TT  0.415 M:    -7.44   -15.10
>> new alloc for instr Buzzer:
>> WARNING:  [minstr Buzzer uses 11 p-fields but is given 5 [m
>> [minstr    2 t    0.4145 d    0.7000 k   67.0000 v   60.0000 p   
>0.0000
>> [m  rtevent:       T  0.515 TT  0.515 M:    -2.81   -10.47
>> new alloc for instr Harpsichord:
>> WARNING:  [minstr Harpsichord uses 11 p-fields but is given 5 [m
>> [minstr    1 t    0.5145 d    0.8050 k   71.0000 v   60.0000 p   
>0.0000
>> [m
>> A
>>
>>
>>
>>
>> Not worked out hat te br

I have commited code that I think behaves as you want, but I am not 
totally sure it is right.  I still fixes the earlier problem of not 
ending.  Now the performans_mode program runs foreer.

Thanks, I will try this now. I'll also look at your code.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, May 17, 2018 at 11:34 AM, jpff  wrote:
> I have commited code that I think behaves as you want, but I am not totally
> sure it is right.  I still fixes the earlier problem of not ending.  Now the
> performans_mode program runs foreer.