I have discovered some problems in commit
fd7c47656f7e8e5f00e6f314909f05229ac87ca1, tested on Linux.

When a program using the API calls compileCsdText, the number of
channels specified in the  element appears to be ignored.
This does not happen when the same CSD is run using the Csound
command. The -o option also is ignored and I bet ALL options are
ignored.

There is of course a workaround, namely to specify --nchnls=N with
csoundSetOption.

Is this behavior by design? Has this changed recently?

Another problem is that csoundPerformKsmps used to terminate returning
2 when the  element was finished. Now, when using the API and
calling compileCsdText and then going into a csoundPerformKsmps loop,
csoundPerformKsmps returns 2 immediately, and the score is not even
performed at all unless the return value of csoundPerformKsmps is
ignored so that the performance loop runs indefinitely. But then
Csound does not quit when the score is done.

Again, is this behavior by design? Has this changed recently?

Also, I see there is now an 'inc' dir along with 'H' and 'include'
with what appear to be duplicate files -- what the hell?

Regards,
Mike

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

OK, I see one thing I missed. A score element that ends with an 'e'
statement exits immediately. One that does not end with an 'e' event
behaves as it used to.

Regards,
Mikd

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


On Wed, Dec 28, 2016 at 4:44 PM, Michael Gogins
 wrote:
> I have discovered some problems in commit
> fd7c47656f7e8e5f00e6f314909f05229ac87ca1, tested on Linux.
>
> When a program using the API calls compileCsdText, the number of
> channels specified in the  element appears to be ignored.
> This does not happen when the same CSD is run using the Csound
> command. The -o option also is ignored and I bet ALL options are
> ignored.
>
> There is of course a workaround, namely to specify --nchnls=N with
> csoundSetOption.
>
> Is this behavior by design? Has this changed recently?
>
> Another problem is that csoundPerformKsmps used to terminate returning
> 2 when the  element was finished. Now, when using the API and
> calling compileCsdText and then going into a csoundPerformKsmps loop,
> csoundPerformKsmps returns 2 immediately, and the score is not even
> performed at all unless the return value of csoundPerformKsmps is
> ignored so that the performance loop runs indefinitely. But then
> Csound does not quit when the score is done.
>
> Again, is this behavior by design? Has this changed recently?
>
> Also, I see there is now an 'inc' dir along with 'H' and 'include'
> with what appear to be duplicate files -- what the hell?
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com

I don't think any of this has changed recently. The way it worked as far as I know
is this:

1) if the CSD is passed as an argument to Csound, before the engine starts (CsStart()
is explicitly or implicitly called), then all
options are read, etc., the score is loaded
and preprocessed.

2) If a CSD is passed to Csound after the
engine starts, then options and header
constants are ignored. The score is
read and preprocessed but passed in 
as RT events.

What I don't know without looking at the
code is whether a CSD passed in as text 
can be loaded as in 1) above or it is
always taken in as 2) even before the
engine has started. However, afaik this
code has not changed.

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

> On 28 Dec 2016, at 21:52, Michael Gogins  wrote:
> 
> OK, I see one thing I missed. A score element that ends with an 'e'
> statement exits immediately. One that does not end with an 'e' event
> behaves as it used to.
> 
> Regards,
> Mikd
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Wed, Dec 28, 2016 at 4:44 PM, Michael Gogins
>  wrote:
>> I have discovered some problems in commit
>> fd7c47656f7e8e5f00e6f314909f05229ac87ca1, tested on Linux.
>> 
>> When a program using the API calls compileCsdText, the number of
>> channels specified in the  element appears to be ignored.
>> This does not happen when the same CSD is run using the Csound
>> command. The -o option also is ignored and I bet ALL options are
>> ignored.
>> 
>> There is of course a workaround, namely to specify --nchnls=N with
>> csoundSetOption.
>> 
>> Is this behavior by design? Has this changed recently?
>> 
>> Another problem is that csoundPerformKsmps used to terminate returning
>> 2 when the  element was finished. Now, when using the API and
>> calling compileCsdText and then going into a csoundPerformKsmps loop,
>> csoundPerformKsmps returns 2 immediately, and the score is not even
>> performed at all unless the return value of csoundPerformKsmps is
>> ignored so that the performance loop runs indefinitely. But then
>> Csound does not quit when the score is done.
>> 
>> Again, is this behavior by design? Has this changed recently?
>> 
>> Also, I see there is now an 'inc' dir along with 'H' and 'include'
>> with what appear to be duplicate files -- what the hell?
>> 
>> Regards,
>> Mike
>> 
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com

My impression is that a CSD passed in as text used to be loaded as 1)
above but now is always taken is as 2).

Thanks,
Mike

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


On Wed, Dec 28, 2016 at 5:12 PM, Victor Lazzarini
 wrote:
> I don't think any of this has changed recently. The way it worked as far as I know
> is this:
>
> 1) if the CSD is passed as an argument to Csound, before the engine starts (CsStart()
> is explicitly or implicitly called), then all
> options are read, etc., the score is loaded
> and preprocessed.
>
> 2) If a CSD is passed to Csound after the
> engine starts, then options and header
> constants are ignored. The score is
> read and preprocessed but passed in
> as RT events.
>
> What I don't know without looking at the
> code is whether a CSD passed in as text
> can be loaded as in 1) above or it is
> always taken in as 2) even before the
> engine has started. However, afaik this
> code has not changed.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 28 Dec 2016, at 21:52, Michael Gogins  wrote:
>>
>> OK, I see one thing I missed. A score element that ends with an 'e'
>> statement exits immediately. One that does not end with an 'e' event
>> behaves as it used to.
>>
>> Regards,
>> Mikd
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Wed, Dec 28, 2016 at 4:44 PM, Michael Gogins
>>  wrote:
>>> I have discovered some problems in commit
>>> fd7c47656f7e8e5f00e6f314909f05229ac87ca1, tested on Linux.
>>>
>>> When a program using the API calls compileCsdText, the number of
>>> channels specified in the  element appears to be ignored.
>>> This does not happen when the same CSD is run using the Csound
>>> command. The -o option also is ignored and I bet ALL options are
>>> ignored.
>>>
>>> There is of course a workaround, namely to specify --nchnls=N with
>>> csoundSetOption.
>>>
>>> Is this behavior by design? Has this changed recently?
>>>
>>> Another problem is that csoundPerformKsmps used to terminate returning
>>> 2 when the  element was finished. Now, when using the API and
>>> calling compileCsdText and then going into a csoundPerformKsmps loop,
>>> csoundPerformKsmps returns 2 immediately, and the score is not even
>>> performed at all unless the return value of csoundPerformKsmps is
>>> ignored so that the performance loop runs indefinitely. But then
>>> Csound does not quit when the score is done.
>>>
>>> Again, is this behavior by design? Has this changed recently?
>>>
>>> Also, I see there is now an 'inc' dir along with 'H' and 'include'
>>> with what appear to be duplicate files -- what the hell?
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com