Hi All,

I've been doing a fair amount of live code practice both using the
WASM build (via https://kunstmusik.github.io/csound-live-code) and the
desktop version of Csound. I've found some stability issues I think
should be addressed before next release.  In particular:

1. With WASM, after coding for a while it will inevitably get to a bad
point where sound will die and Csound will repeatedly mention a NaN
error.  When Csound gets into this state, there's nothing to do be
restart the page.

2. With desktop Csound, I've seen it get into an equivalent NaN kind
of state.  However, it seems to happen less frequently and sometimes
gets back to producing sound.  I suspect it happens less on desktop
Csound due to it being 64-bit doubles rather than WASM build's 32-bit.
(I suspect memory corruption somewhere).

3. I saw it happen yesterday that while live coding via UDP server on
desktop, I went to evaluate some code and there was an error in the
code and rather than report the error, Csound just died.

4. For testing I suppose it would be good to have some kind of shell
or python script to send UDP messages to Csound to have something of a
repeatable test.

5. There are compiler warnings that appear in our builds. I think it
would be good to do clean builds and take note of where we're at, run
static anlyzer in XCode, etc.

6. I saw that we haven't done a Coverity Scan in quite some time
(since May).  I've gone and merged the latest from develop into
coverity_scan and pushed that to Github to trigger a scan.

Thanks!

On Mon, 23 Oct 2017, Steven Yi wrote:


> 6. I saw that we haven't done a Coverity Scan in quite some time
> (since May).  I've gone and merged the latest from develop into
> coverity_scan and pushed that to Github to trigger a scan.
>


Took a quick look and many of them are plain wrong.   Case fall through is 

I suspect some of these exceptions are caused by type casting integer
types to floats or doubles in such a way that the bit pattern does not
match the standard for floating-point numbers.

Regards,
Mike


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


On Mon, Oct 23, 2017 at 12:32 PM, Victor Lazzarini
 wrote:
> I have the impression that WASM is NaN prone for some reason. I remember
> that the
> emscrpten asm.js could not cope with some of the mathematics (exponentials
> for instance did not work).
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
> On 23 Oct 2017, at 17:04, Michael Gogins  wrote:
>
> Thanks, I'll fix as many of the Coverity  issues as I can. The WASM NaNs
> have been reported for other projects also.
>
> Best,
> Mike
>
> On Oct 23, 2017 11:16, "Steven Yi"  wrote:
>>
>> Hi All,
>>
>> I've been doing a fair amount of live code practice both using the
>> WASM build (via https://kunstmusik.github.io/csound-live-code) and the
>> desktop version of Csound. I've found some stability issues I think
>> should be addressed before next release.  In particular:
>>
>> 1. With WASM, after coding for a while it will inevitably get to a bad
>> point where sound will die and Csound will repeatedly mention a NaN
>> error.  When Csound gets into this state, there's nothing to do be
>> restart the page.
>>
>> 2. With desktop Csound, I've seen it get into an equivalent NaN kind
>> of state.  However, it seems to happen less frequently and sometimes
>> gets back to producing sound.  I suspect it happens less on desktop
>> Csound due to it being 64-bit doubles rather than WASM build's 32-bit.
>> (I suspect memory corruption somewhere).
>>
>> 3. I saw it happen yesterday that while live coding via UDP server on
>> desktop, I went to evaluate some code and there was an error in the
>> code and rather than report the error, Csound just died.
>>
>> 4. For testing I suppose it would be good to have some kind of shell
>> or python script to send UDP messages to Csound to have something of a
>> repeatable test.
>>
>> 5. There are compiler warnings that appear in our builds. I think it
>> would be good to do clean builds and take note of where we're at, run
>> static anlyzer in XCode, etc.
>>
>> 6. I saw that we haven't done a Coverity Scan in quite some time
>> (since May).  I've gone and merged the latest from develop into
>> coverity_scan and pushed that to Github to trigger a scan.
>>
>> Thanks!

Yeah right now I haven't looked deeply enough to figure out what
exactly is going on. Both the NaN and sudden stop issues are a bit
disconcerting and I think are going to require some time to diagnose.

Some other notes:

1. The WASM examples: I've been thinking that we needed a site for Web
Csound templates/examples.  I double-checked and the examples we
provide in the Csound WASM release demonstrate the things users might
want (midi input, audio input), but I'm thinking they're a little
dated now and could use a refresh.

2. It seems like we should provide more than just the examples with
the WASM release. I was thinking documentation would be good,
something more along the lines of what we give with Csound for iOS and
Csound for Android, that walks a user through various features and how
to use them.

3. On a positive note: I tested my csound-live-code page on my
somewhat underpowered, 2-year old, Acer CB3 Chromebook running Chrome
OS.  I'm happy to say the page loaded just fine and I was able to live
code with Csound on the device.

Thanks!
steven




On Mon, Oct 23, 2017 at 12:58 PM, Michael Gogins
 wrote:
> I suspect some of these exceptions are caused by type casting integer
> types to floats or doubles in such a way that the bit pattern does not
> match the standard for floating-point numbers.
>
> Regards,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Mon, Oct 23, 2017 at 12:32 PM, Victor Lazzarini
>  wrote:
>> I have the impression that WASM is NaN prone for some reason. I remember
>> that the
>> emscrpten asm.js could not cope with some of the mathematics (exponentials
>> for instance did not work).
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>> On 23 Oct 2017, at 17:04, Michael Gogins  wrote:
>>
>> Thanks, I'll fix as many of the Coverity  issues as I can. The WASM NaNs
>> have been reported for other projects also.
>>
>> Best,
>> Mike
>>
>> On Oct 23, 2017 11:16, "Steven Yi"  wrote:
>>>
>>> Hi All,
>>>
>>> I've been doing a fair amount of live code practice both using the
>>> WASM build (via https://kunstmusik.github.io/csound-live-code) and the
>>> desktop version of Csound. I've found some stability issues I think
>>> should be addressed before next release.  In particular:
>>>
>>> 1. With WASM, after coding for a while it will inevitably get to a bad
>>> point where sound will die and Csound will repeatedly mention a NaN
>>> error.  When Csound gets into this state, there's nothing to do be
>>> restart the page.
>>>
>>> 2. With desktop Csound, I've seen it get into an equivalent NaN kind
>>> of state.  However, it seems to happen less frequently and sometimes
>>> gets back to producing sound.  I suspect it happens less on desktop
>>> Csound due to it being 64-bit doubles rather than WASM build's 32-bit.
>>> (I suspect memory corruption somewhere).
>>>
>>> 3. I saw it happen yesterday that while live coding via UDP server on
>>> desktop, I went to evaluate some code and there was an error in the
>>> code and rather than report the error, Csound just died.
>>>
>>> 4. For testing I suppose it would be good to have some kind of shell
>>> or python script to send UDP messages to Csound to have something of a
>>> repeatable test.
>>>
>>> 5. There are compiler warnings that appear in our builds. I think it
>>> would be good to do clean builds and take note of where we're at, run
>>> static anlyzer in XCode, etc.
>>>
>>> 6. I saw that we haven't done a Coverity Scan in quite some time
>>> (since May).  I've gone and merged the latest from develop into
>>> coverity_scan and pushed that to Github to trigger a scan.
>>>
>>> Thanks!

And on another out there note, I ran my csound-live-code page on my
Moto G4 Android phone.  Using a Bluetooth keyboard, I was able to use
ctrl-e to evaluate and live code on the phone.  Out there! :)

On Mon, Oct 23, 2017 at 7:11 PM, Steven Yi  wrote:
> Yeah right now I haven't looked deeply enough to figure out what
> exactly is going on. Both the NaN and sudden stop issues are a bit
> disconcerting and I think are going to require some time to diagnose.
>
> Some other notes:
>
> 1. The WASM examples: I've been thinking that we needed a site for Web
> Csound templates/examples.  I double-checked and the examples we
> provide in the Csound WASM release demonstrate the things users might
> want (midi input, audio input), but I'm thinking they're a little
> dated now and could use a refresh.
>
> 2. It seems like we should provide more than just the examples with
> the WASM release. I was thinking documentation would be good,
> something more along the lines of what we give with Csound for iOS and
> Csound for Android, that walks a user through various features and how
> to use them.
>
> 3. On a positive note: I tested my csound-live-code page on my
> somewhat underpowered, 2-year old, Acer CB3 Chromebook running Chrome
> OS.  I'm happy to say the page loaded just fine and I was able to live
> code with Csound on the device.
>
> Thanks!
> steven
>
>
>
>
> On Mon, Oct 23, 2017 at 12:58 PM, Michael Gogins
>  wrote:
>> I suspect some of these exceptions are caused by type casting integer
>> types to floats or doubles in such a way that the bit pattern does not
>> match the standard for floating-point numbers.
>>
>> Regards,
>> Mike
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Mon, Oct 23, 2017 at 12:32 PM, Victor Lazzarini
>>  wrote:
>>> I have the impression that WASM is NaN prone for some reason. I remember
>>> that the
>>> emscrpten asm.js could not cope with some of the mathematics (exponentials
>>> for instance did not work).
>>>
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>>
>>> On 23 Oct 2017, at 17:04, Michael Gogins  wrote:
>>>
>>> Thanks, I'll fix as many of the Coverity  issues as I can. The WASM NaNs
>>> have been reported for other projects also.
>>>
>>> Best,
>>> Mike
>>>
>>> On Oct 23, 2017 11:16, "Steven Yi"  wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I've been doing a fair amount of live code practice both using the
>>>> WASM build (via https://kunstmusik.github.io/csound-live-code) and the
>>>> desktop version of Csound. I've found some stability issues I think
>>>> should be addressed before next release.  In particular:
>>>>
>>>> 1. With WASM, after coding for a while it will inevitably get to a bad
>>>> point where sound will die and Csound will repeatedly mention a NaN
>>>> error.  When Csound gets into this state, there's nothing to do be
>>>> restart the page.
>>>>
>>>> 2. With desktop Csound, I've seen it get into an equivalent NaN kind
>>>> of state.  However, it seems to happen less frequently and sometimes
>>>> gets back to producing sound.  I suspect it happens less on desktop
>>>> Csound due to it being 64-bit doubles rather than WASM build's 32-bit.
>>>> (I suspect memory corruption somewhere).
>>>>
>>>> 3. I saw it happen yesterday that while live coding via UDP server on
>>>> desktop, I went to evaluate some code and there was an error in the
>>>> code and rather than report the error, Csound just died.
>>>>
>>>> 4. For testing I suppose it would be good to have some kind of shell
>>>> or python script to send UDP messages to Csound to have something of a
>>>> repeatable test.
>>>>
>>>> 5. There are compiler warnings that appear in our builds. I think it
>>>> would be good to do clean builds and take note of where we're at, run
>>>> static anlyzer in XCode, etc.
>>>>
>>>> 6. I saw that we haven't done a Coverity Scan in quite some time
>>>> (since May).  I've gone and merged the latest from develop into
>>>> coverity_scan and pushed that to Github to trigger a scan.
>>>>
>>>> Thanks!