Csound Csound-dev Csound-tekno Search About

[Csnd] Csound-wasm version at https://csound.github.io/wasm/

Date2018-03-24 13:24
FromTarmo Johannes
Subject[Csnd] Csound-wasm version at https://csound.github.io/wasm/
Hi,

I noticed that the Csoud-wasm version on https://csound.github.io/wasm/ is 
still 6.09.
I think that it is good that there is a certain place in web where you can 
link to Csound-wasm recources like


and get the latest version of libcsound.wasm

Or what is the best practice to use Csound-wasm on one's own sites? Should one 
always download csound-wasm from download page, unzip and upload to the server 
where his html file is going to be?

Thanks!
tarmo

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Date2018-03-24 16:05
FromMichael Gogins
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
Good question. There are several places to download it now. The Csound
repository is one. It looks to be pretty up to date with
https://github.com/gogins/csound-extended/releases/download/v0.1.0-beta2/csound-wasm-6.11.0-beta2.zip.
Have you tried this? I think it's probably good.

I have two other sources. gogins.github.io is out of date and I will fix that.

I have another version of Csound for WebAssembly at
https://github.com/gogins/csound-extended, called csound_extended.js
instead of csound.js, that is implemented slightly differently but
supports most of the same JavaScript API. Right now the main
difference is that csound_extended.js follows the semantics of the
original Csound API somewhat more closely than does csound.js. As time
goes on I will be adding features, the first will be a WebAssembly
build of CsoundAC with a JavaScript interface. I am updating this
repository fairly regularly.

Regards,
Mike

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


On Sat, Mar 24, 2018 at 10:24 AM, Tarmo Johannes  wrote:
> Hi,
>
> I noticed that the Csoud-wasm version on https://csound.github.io/wasm/ is
> still 6.09.
> I think that it is good that there is a certain place in web where you can
> link to Csound-wasm recources like
> 
> 
> and get the latest version of libcsound.wasm
>
> Or what is the best practice to use Csound-wasm on one's own sites? Should one
> always download csound-wasm from download page, unzip and upload to the server
> where his html file is going to be?
>
> Thanks!
> tarmo
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Date2018-03-24 16:52
FromTarmo Johannes
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/

Hi,

 

On Saturday, March 24, 2018 6:05:58 PM EET you wrote:

> https://github.com/gogins/csound-extended/releases/download/v0.1.0-beta2//

> csound-wasm-6.11.0-beta2.zip.

 

Yes, this works nicely, thanks!

 

I think that it would be nice to have one place online where the latest Csound-wasm build can be reached, so that users don't have to always download unpack and upload the package when they want to use Csound-wasm in their page.

 

Is it now so that the libcsound.wasm file must be exmplicitly in the same folder as the user's html/javascript file? Is it perhaps possible to load it rempotely? In that case I would suggest that http://csound.com/wasm/ would be the place set link to.

 

tarmo


Date2018-03-24 17:18
FromSteven Yi
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
Perhaps best to file an issue, either on the Csound tracker or
csound.github.io tracker. 6.11.0 should be out soon and we can publish
it to whatever URL is proposed. We could host on csound.com, but we
could also look at other CDN sites too.  (I think we might not be able
to follow CORS rules for cross-site scripting and publishing publicly
on csound.com with github pages, but I haven't looked at that kind of
thing in a long while).

The benefit of unpacking/installing as part of your project is that
you don't have to deal with CORS and can depend upon it working
always.  I think Ed's done some research into making the inclusion
automated via Webpack and Hlodver's done some research making a single
JS all-in-one file that might make things simpler. (Perhaps they could
comment on their efforts here?)





On Sat, Mar 24, 2018 at 12:52 PM, Tarmo Johannes  wrote:
> Hi,
>
>
>
> On Saturday, March 24, 2018 6:05:58 PM EET you wrote:
>
>> https://github.com/gogins/csound-extended/releases/download/v0.1.0-beta2//
>
>> csound-wasm-6.11.0-beta2.zip.
>
>
>
> Yes, this works nicely, thanks!
>
>
>
> I think that it would be nice to have one place online where the latest
> Csound-wasm build can be reached, so that users don't have to always
> download unpack and upload the package when they want to use Csound-wasm in
> their page.
>
>
>
> Is it now so that the libcsound.wasm file must be exmplicitly in the same
> folder as the user's html/javascript file? Is it perhaps possible to load it
> rempotely? In that case I would suggest that http://csound.com/wasm/ would
> be the place set link to.
>
>
>
> tarmo
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Date2018-03-24 17:26
FromMichael Gogins
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
CORS is cross-origin resource sharing, which is a security risk. It is
however common, e.g. for CDNs, see https://enable-cors.org/.

Regards,
Mike

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


On Sat, Mar 24, 2018 at 2:18 PM, Steven Yi  wrote:
> Perhaps best to file an issue, either on the Csound tracker or
> csound.github.io tracker. 6.11.0 should be out soon and we can publish
> it to whatever URL is proposed. We could host on csound.com, but we
> could also look at other CDN sites too.  (I think we might not be able
> to follow CORS rules for cross-site scripting and publishing publicly
> on csound.com with github pages, but I haven't looked at that kind of
> thing in a long while).
>
> The benefit of unpacking/installing as part of your project is that
> you don't have to deal with CORS and can depend upon it working
> always.  I think Ed's done some research into making the inclusion
> automated via Webpack and Hlodver's done some research making a single
> JS all-in-one file that might make things simpler. (Perhaps they could
> comment on their efforts here?)
>
>
>
>
>
> On Sat, Mar 24, 2018 at 12:52 PM, Tarmo Johannes  wrote:
>> Hi,
>>
>>
>>
>> On Saturday, March 24, 2018 6:05:58 PM EET you wrote:
>>
>>> https://github.com/gogins/csound-extended/releases/download/v0.1.0-beta2//
>>
>>> csound-wasm-6.11.0-beta2.zip.
>>
>>
>>
>> Yes, this works nicely, thanks!
>>
>>
>>
>> I think that it would be nice to have one place online where the latest
>> Csound-wasm build can be reached, so that users don't have to always
>> download unpack and upload the package when they want to use Csound-wasm in
>> their page.
>>
>>
>>
>> Is it now so that the libcsound.wasm file must be exmplicitly in the same
>> folder as the user's html/javascript file? Is it perhaps possible to load it
>> rempotely? In that case I would suggest that http://csound.com/wasm/ would
>> be the place set link to.
>>
>>
>>
>> tarmo
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Date2018-03-24 21:19
FromEdward Costello
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
Yes, I have been able to get Csound working inside of a React app using Webpack 4. 

I am compiling the WASM using the following: 

emcc -v -O2 -g4 -DINIT_STATIC_MODULES=1 -s SINGLE_FILE=1 -s MODULARIZE=1 -s EXPORT_NAME=\"'libcsound'\" -s DEMANGLE_SUPPORT=1  -s WASM=1 -s ASSERTIONS=1 -s "BINARYEN_METHOD='native-wasm'" -s LINKABLE=1 -s RESERVED_FUNCTION_POINTERS=1 -s TOTAL_MEMORY=268435456 -s ALLOW_MEMORY_GROWTH=1 -s NO_EXIT_RUNTIME=0 -s EXTRA_EXPORTED_RUNTIME_METHODS="['FS', 'cwrap']" CsoundObj.bc FileList.bc libcsound.a ../deps/libsndfile-1.0.25/libsndfile-wasm.a  -o libcsound.js

Notice I added the SINGLE_FILE, MODULARIZE and EXPORT_NAME option. (As an aside I don’t think it’s necessary to have the Csound_Obj exported functions anymore in the above line as someone added the Emscripten Keep Alive macro to the CsoundObj.c source).
Also using SINGLE_FILE is not necessary, and seems to be slower to load than without.

In my Webpack 4 config:

module.exports = {
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: {
                    loader: "babel-loader"
                }
            },
            {
                test: /\.wasm$/,
                type: "webassembly/experimental"
            },
            {
                test: /\.csd$/,
                use: 'raw-loader'
            }
        ],
    },
    node: {
        fs:'empty',
        ws:'empty'
    },
    externals: ['ws']
}

I can then import Csound into a Javascript class like this:

import libcsound from './libcsound.js';

class MyClass {

	constructor() {

		libcsound().then((Module) => { console.log("libcsound loaded."); })
	}

}


> On 24 Mar 2018, at 10:26, Michael Gogins  wrote:
> 
> CORS is cross-origin resource sharing, which is a security risk. It is
> however common, e.g. for CDNs, see https://enable-cors.org/.
> 
> Regards,
> Mike
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Sat, Mar 24, 2018 at 2:18 PM, Steven Yi  wrote:
>> Perhaps best to file an issue, either on the Csound tracker or
>> csound.github.io tracker. 6.11.0 should be out soon and we can publish
>> it to whatever URL is proposed. We could host on csound.com, but we
>> could also look at other CDN sites too.  (I think we might not be able
>> to follow CORS rules for cross-site scripting and publishing publicly
>> on csound.com with github pages, but I haven't looked at that kind of
>> thing in a long while).
>> 
>> The benefit of unpacking/installing as part of your project is that
>> you don't have to deal with CORS and can depend upon it working
>> always.  I think Ed's done some research into making the inclusion
>> automated via Webpack and Hlodver's done some research making a single
>> JS all-in-one file that might make things simpler. (Perhaps they could
>> comment on their efforts here?)
>> 
>> 
>> 
>> 
>> 
>> On Sat, Mar 24, 2018 at 12:52 PM, Tarmo Johannes  wrote:
>>> Hi,
>>> 
>>> 
>>> 
>>> On Saturday, March 24, 2018 6:05:58 PM EET you wrote:
>>> 
>>>> https://github.com/gogins/csound-extended/releases/download/v0.1.0-beta2//
>>> 
>>>> csound-wasm-6.11.0-beta2.zip.
>>> 
>>> 
>>> 
>>> Yes, this works nicely, thanks!
>>> 
>>> 
>>> 
>>> I think that it would be nice to have one place online where the latest
>>> Csound-wasm build can be reached, so that users don't have to always
>>> download unpack and upload the package when they want to use Csound-wasm in
>>> their page.
>>> 
>>> 
>>> 
>>> Is it now so that the libcsound.wasm file must be exmplicitly in the same
>>> folder as the user's html/javascript file? Is it perhaps possible to load it
>>> rempotely? In that case I would suggest that http://csound.com/wasm/ would
>>> be the place set link to.
>>> 
>>> 
>>> 
>>> tarmo
>>> 
>>> Csound mailing list Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>> be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Date2018-03-24 22:22
FromHlöðver Sigurðsson
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
I made a single js, still work in progress

but this usage example shows it's simplicity

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
  </head>
  <body>
    <h5>Click Start realtime once, gotta love chrome's new autoplay ban policy</h5>
    <button id="start">Start realtime</button>
    <button onclick="csound.inputMessage('i 1 0 1')">Make beep!</h1>
    <script src="https://github.com/hlolli/csound-wasm/releases/download/6.10.0-4/csound-wasm-browser.js"></script>
  <script>
    const beeper = `
    instr 1
    asig = poscil:a(0.3, 440)
    outc asig, asig
    endin
    `
    document.getElementById('start').onclick = ()=> {
    csound.startRealtime();
    csound.compileOrc(beeper);
    };
  </script>
</body>
</html>

This will work anywhere, one can quickly try at

On 24 March 2018 at 22:19, Edward Costello <phasereset@gmail.com> wrote:
Yes, I have been able to get Csound working inside of a React app using Webpack 4.

I am compiling the WASM using the following:

emcc -v -O2 -g4 -DINIT_STATIC_MODULES=1 -s SINGLE_FILE=1 -s MODULARIZE=1 -s EXPORT_NAME=\"'libcsound'\" -s DEMANGLE_SUPPORT=1  -s WASM=1 -s ASSERTIONS=1 -s "BINARYEN_METHOD='native-wasm'" -s LINKABLE=1 -s RESERVED_FUNCTION_POINTERS=1 -s TOTAL_MEMORY=268435456 -s ALLOW_MEMORY_GROWTH=1 -s NO_EXIT_RUNTIME=0 -s EXTRA_EXPORTED_RUNTIME_METHODS="['FS', 'cwrap']" CsoundObj.bc FileList.bc libcsound.a ../deps/libsndfile-1.0.25/libsndfile-wasm.a  -o libcsound.js

Notice I added the SINGLE_FILE, MODULARIZE and EXPORT_NAME option. (As an aside I don’t think it’s necessary to have the Csound_Obj exported functions anymore in the above line as someone added the Emscripten Keep Alive macro to the CsoundObj.c source).
Also using SINGLE_FILE is not necessary, and seems to be slower to load than without.

In my Webpack 4 config:

module.exports = {
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: {
                    loader: "babel-loader"
                }
            },
            {
                test: /\.wasm$/,
                type: "webassembly/experimental"
            },
            {
                test: /\.csd$/,
                use: 'raw-loader'
            }
        ],
    },
    node: {
        fs:'empty',
        ws:'empty'
    },
    externals: ['ws']
}

I can then import Csound into a Javascript class like this:

import libcsound from './libcsound.js';

class MyClass {

        constructor() {

                libcsound().then((Module) => { console.log("libcsound loaded."); })
        }

}


> On 24 Mar 2018, at 10:26, Michael Gogins <michael.gogins@GMAIL.COM> wrote:
>
> CORS is cross-origin resource sharing, which is a security risk. It is
> however common, e.g. for CDNs, see https://enable-cors.org/.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Sat, Mar 24, 2018 at 2:18 PM, Steven Yi <stevenyi@gmail.com> wrote:
>> Perhaps best to file an issue, either on the Csound tracker or
>> csound.github.io tracker. 6.11.0 should be out soon and we can publish
>> it to whatever URL is proposed. We could host on csound.com, but we
>> could also look at other CDN sites too.  (I think we might not be able
>> to follow CORS rules for cross-site scripting and publishing publicly
>> on csound.com with github pages, but I haven't looked at that kind of
>> thing in a long while).
>>
>> The benefit of unpacking/installing as part of your project is that
>> you don't have to deal with CORS and can depend upon it working
>> always.  I think Ed's done some research into making the inclusion
>> automated via Webpack and Hlodver's done some research making a single
>> JS all-in-one file that might make things simpler. (Perhaps they could
>> comment on their efforts here?)
>>
>>
>>
>>
>>
>> On Sat, Mar 24, 2018 at 12:52 PM, Tarmo Johannes <trmjhnns@gmail.com> wrote:
>>> Hi,
>>>
>>>
>>>
>>> On Saturday, March 24, 2018 6:05:58 PM EET you wrote:
>>>
>>>> https://github.com/gogins/csound-extended/releases/download/v0.1.0-beta2//
>>>
>>>> csound-wasm-6.11.0-beta2.zip.
>>>
>>>
>>>
>>> Yes, this works nicely, thanks!
>>>
>>>
>>>
>>> I think that it would be nice to have one place online where the latest
>>> Csound-wasm build can be reached, so that users don't have to always
>>> download unpack and upload the package when they want to use Csound-wasm in
>>> their page.
>>>
>>>
>>>
>>> Is it now so that the libcsound.wasm file must be exmplicitly in the same
>>> folder as the user's html/javascript file? Is it perhaps possible to load it
>>> rempotely? In that case I would suggest that http://csound.com/wasm/ would
>>> be the place set link to.
>>>
>>>
>>>
>>> tarmo
>>>
>>> Csound mailing list Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>> be posted here
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date2018-03-25 07:02
FromTarmo Johannes
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
Great!

I think something like that would be very welcome from users point of view! If 
it has no contradictions with security or else, I guess for Csound use in web 
pages that would be really useful.

I saw it has a new API method csound.startRealtime(config*).
It is probably necessary to distinguish from csound.start() but I find it very 
important -  if ever possible -  that all html/javascript associataed APIs 
would use same or similar methods -  so the same code works in Android, Csound 
For Node, Wasm, CsoundQt etc.  What do you think?

tarmo

On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
> I made a single js, still work in progress
> https://github.com/hlolli/csound-wasm
> 
> but this usage example shows it's simplicity
> 
> 
> 
>   
>     
>   
>   
>     
Click Start realtime once, gotta love chrome's new autoplay > ban policy
> >

Date2018-03-25 12:19
FromMichael Gogins
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
It's always possible to implement the existing API first and then add any new functionality that may be desired or required, with new names. 

This is what I did in csound_extended.js. I think this is the right approach. 

This does not appear to be the case with csound.js. 

Regards, 
Mike

On Sun, Mar 25, 2018, 2:02 AM Tarmo Johannes <trmjhnns@gmail.com> wrote:
Great!

I think something like that would be very welcome from users point of view! If
it has no contradictions with security or else, I guess for Csound use in web
pages that would be really useful.

I saw it has a new API method csound.startRealtime(config*).
It is probably necessary to distinguish from csound.start() but I find it very
important -  if ever possible -  that all html/javascript associataed APIs
would use same or similar methods -  so the same code works in Android, Csound
For Node, Wasm, CsoundQt etc.  What do you think?

tarmo

On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
> I made a single js, still work in progress
> https://github.com/hlolli/csound-wasm
>
> but this usage example shows it's simplicity
>
> <!DOCTYPE html>
> <html lang="en">
>   <head>
>     <meta charset="utf-8">
>   </head>
>   <body>
>     <h5>Click Start realtime once, gotta love chrome's new autoplay
> ban policy</h5>
>     <button id="start">Start realtime</button>
>     <button onclick="csound.inputMessage('i 1 0 1')">Make beep!</h1>
>     <script
> src="https://github.com/hlolli/csound-wasm/releases/download/6.10.0-4/csoun
> d-wasm-browser.js"></script> <script>    const beeper = `    instr 1    asig
> = poscil:a(0.3, 440) outc asig, asig    endin    `
> document.getElementById('start').onclick = ()=> {
> csound.startRealtime();    csound.compileOrc(beeper);    };  </script>
> </body>
> </html>
>
>
> This will work anywhere, one can quickly try at
> https://jsfiddle.net/
>
> On 24 March 2018 at 22:19, Edward Costello <phasereset@gmail.com> wrote:
> > Yes, I have been able to get Csound working inside of a React app using
> > Webpack 4.
> >
> > I am compiling the WASM using the following:
> >
> > emcc -v -O2 -g4 -DINIT_STATIC_MODULES=1 -s SINGLE_FILE=1 -s MODULARIZE=1
> > -s EXPORT_NAME=\"'libcsound'\" -s DEMANGLE_SUPPORT=1  -s WASM=1 -s
> > ASSERTIONS=1 -s "BINARYEN_METHOD='native-wasm'" -s LINKABLE=1 -s
> > RESERVED_FUNCTION_POINTERS=1 -s TOTAL_MEMORY=268435456 -s
> > ALLOW_MEMORY_GROWTH=1 -s NO_EXIT_RUNTIME=0 -s
> > EXTRA_EXPORTED_RUNTIME_METHODS="['FS', 'cwrap']" CsoundObj.bc FileList.bc
> > libcsound.a ../deps/libsndfile-1.0.25/libsndfile-wasm.a -o libcsound.js
> >
> > Notice I added the SINGLE_FILE, MODULARIZE and EXPORT_NAME option. (As an
> > aside I don’t think it’s necessary to have the Csound_Obj exported
> > functions anymore in the above line as someone added the Emscripten Keep
> > Alive macro to the CsoundObj.c source).
> > Also using SINGLE_FILE is not necessary, and seems to be slower to load
> > than without.
> >
> > In my Webpack 4 config:
> >
> > module.exports = {
> >
> >     module: {
> >
> >         rules: [
> >
> >             {
> >
> >                 test: /\.js$/,
> >                 exclude: /node_modules/,
> >                 use: {
> >
> >                     loader: "babel-loader"
> >
> >                 }
> >
> >             },
> >             {
> >
> >                 test: /\.wasm$/,
> >                 type: "webassembly/experimental"
> >
> >             },
> >             {
> >
> >                 test: /\.csd$/,
> >                 use: 'raw-loader'
> >
> >             }
> >
> >         ],
> >
> >     },
> >     node: {
> >
> >         fs:'empty',
> >         ws:'empty'
> >
> >     },
> >     externals: ['ws']
> >
> > }
> >
> > I can then import Csound into a Javascript class like this:
> >
> > import libcsound from './libcsound.js';
> >
> > class MyClass {
> >
> >         constructor() {
> >
> >                 libcsound().then((Module) => { console.log("libcsound
> >
> > loaded."); })
> >
> >         }
> >
> > }
> >
> > > On 24 Mar 2018, at 10:26, Michael Gogins <michael.gogins@GMAIL.COM>
> >
> > wrote:
> > > CORS is cross-origin resource sharing, which is a security risk. It is
> > > however common, e.g. for CDNs, see https://enable-cors.org/.
> > >
> > > Regards,
> > > Mike
> > >
> > > -----------------------------------------------------
> > > Michael Gogins
> > > Irreducible Productions
> > > http://michaelgogins.tumblr.com
> > > Michael dot Gogins at gmail dot com
> > >
> > > On Sat, Mar 24, 2018 at 2:18 PM, Steven Yi <stevenyi@gmail.com> wrote:
> > >> Perhaps best to file an issue, either on the Csound tracker or
> > >> csound.github.io tracker. 6.11.0 should be out soon and we can publish
> > >> it to whatever URL is proposed. We could host on csound.com, but we
> > >> could also look at other CDN sites too.  (I think we might not be able
> > >> to follow CORS rules for cross-site scripting and publishing publicly
> > >> on csound.com with github pages, but I haven't looked at that kind of
> > >> thing in a long while).
> > >>
> > >> The benefit of unpacking/installing as part of your project is that
> > >> you don't have to deal with CORS and can depend upon it working
> > >> always.  I think Ed's done some research into making the inclusion
> > >> automated via Webpack and Hlodver's done some research making a single
> > >> JS all-in-one file that might make things simpler. (Perhaps they could
> > >> comment on their efforts here?)
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Sat, Mar 24, 2018 at 12:52 PM, Tarmo Johannes <trmjhnns@gmail.com>
> >
> > wrote:
> > >>> Hi,
> > >>>
> > >>> On Saturday, March 24, 2018 6:05:58 PM EET you wrote:
> > >>>> https://github.com/gogins/csound-extended/releases/
> >
> > download/v0.1.0-beta2//
> >
> > >>>> csound-wasm-6.11.0-beta2.zip.
> > >>>
> > >>> Yes, this works nicely, thanks!
> > >>>
> > >>>
> > >>>
> > >>> I think that it would be nice to have one place online where the
> > >>> latest
> > >>> Csound-wasm build can be reached, so that users don't have to always
> > >>> download unpack and upload the package when they want to use
> >
> > Csound-wasm in
> >
> > >>> their page.
> > >>>
> > >>>
> > >>>
> > >>> Is it now so that the libcsound.wasm file must be exmplicitly in the
> >
> > same
> >
> > >>> folder as the user's html/javascript file? Is it perhaps possible to
> >
> > load it
> >
> > >>> rempotely? In that case I would suggest that http://csound.com/wasm/
> >
> > would
> >
> > >>> be the place set link to.
> > >>>
> > >>>
> > >>>
> > >>> tarmo
> > >>>
> > >>> Csound mailing list Csound@listserv.heanet.ie
> > >>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> > >>> https://github.com/csound/csound/issues Discussions of bugs and
> >
> > features can
> >
> > >>> be posted here
> > >>
> > >> Csound mailing list
> > >> Csound@listserv.heanet.ie
> > >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > >> Send bugs reports to
> > >>
> > >>        https://github.com/csound/csound/issues
> > >>
> > >> Discussions of bugs and features can be posted here
> > >
> > > Csound mailing list
> > > Csound@listserv.heanet.ie
> > > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > > Send bugs reports to
> > >
> > >        https://github.com/csound/csound/issues
> > >
> > > Discussions of bugs and features can be posted here
> >
> > Csound mailing list
> > Csound@listserv.heanet.ie
> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > Send bugs reports to
> >
> >         https://github.com/csound/csound/issues
> >
> > Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date2018-03-25 12:27
FromVictor Lazzarini
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
No, csound.js is meant as port of the PNaCl Csound, not as an extension to CsoundObj. It is effectively a JS frontend in the same way as PNaCl Csound.

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

On 25 Mar 2018, at 12:19, Michael Gogins <michael.gogins@GMAIL.COM> wrote:

It's always possible to implement the existing API first and then add any new functionality that may be desired or required, with new names. 

This is what I did in csound_extended.js. I think this is the right approach. 

This does not appear to be the case with csound.js. 

Regards, 
Mike

On Sun, Mar 25, 2018, 2:02 AM Tarmo Johannes <trmjhnns@gmail.com> wrote:
Great!

I think something like that would be very welcome from users point of view! If
it has no contradictions with security or else, I guess for Csound use in web
pages that would be really useful.

I saw it has a new API method csound.startRealtime(config*).
It is probably necessary to distinguish from csound.start() but I find it very
important -  if ever possible -  that all html/javascript associataed APIs
would use same or similar methods -  so the same code works in Android, Csound
For Node, Wasm, CsoundQt etc.  What do you think?

tarmo

On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
> I made a single js, still work in progress
> https://github.com/hlolli/csound-wasm
>
> but this usage example shows it's simplicity
>
> <!DOCTYPE html>
> <html lang="en">
>   <head>
>     <meta charset="utf-8">
>   </head>
>   <body>
>     <h5>Click Start realtime once, gotta love chrome's new autoplay
> ban policy</h5>
>     <button id="start">Start realtime</button>
>     <button onclick="csound.inputMessage('i 1 0 1')">Make beep!</h1>
>     <script
> src="https://github.com/hlolli/csound-wasm/releases/download/6.10.0-4/csoun
> d-wasm-browser.js"></script> <script>    const beeper = `    instr 1    asig
> = poscil:a(0.3, 440) outc asig, asig    endin    `
> document.getElementById('start').onclick = ()=> {
> csound.startRealtime();    csound.compileOrc(beeper);    };  </script>
> </body>
> </html>
>
>
> This will work anywhere, one can quickly try at
> https://jsfiddle.net/
>
> On 24 March 2018 at 22:19, Edward Costello <phasereset@gmail.com> wrote:
> > Yes, I have been able to get Csound working inside of a React app using
> > Webpack 4.
> >
> > I am compiling the WASM using the following:
> >
> > emcc -v -O2 -g4 -DINIT_STATIC_MODULES=1 -s SINGLE_FILE=1 -s MODULARIZE=1
> > -s EXPORT_NAME=\"'libcsound'\" -s DEMANGLE_SUPPORT=1  -s WASM=1 -s
> > ASSERTIONS=1 -s "BINARYEN_METHOD='native-wasm'" -s LINKABLE=1 -s
> > RESERVED_FUNCTION_POINTERS=1 -s TOTAL_MEMORY=268435456 -s
> > ALLOW_MEMORY_GROWTH=1 -s NO_EXIT_RUNTIME=0 -s
> > EXTRA_EXPORTED_RUNTIME_METHODS="['FS', 'cwrap']" CsoundObj.bc FileList.bc
> > libcsound.a ../deps/libsndfile-1.0.25/libsndfile-wasm.a -o libcsound.js
> >
> > Notice I added the SINGLE_FILE, MODULARIZE and EXPORT_NAME option. (As an
> > aside I don’t think it’s necessary to have the Csound_Obj exported
> > functions anymore in the above line as someone added the Emscripten Keep
> > Alive macro to the CsoundObj.c source).
> > Also using SINGLE_FILE is not necessary, and seems to be slower to load
> > than without.
> >
> > In my Webpack 4 config:
> >
> > module.exports = {
> >
> >     module: {
> >
> >         rules: [
> >
> >             {
> >
> >                 test: /\.js$/,
> >                 exclude: /node_modules/,
> >                 use: {
> >
> >                     loader: "babel-loader"
> >
> >                 }
> >
> >             },
> >             {
> >
> >                 test: /\.wasm$/,
> >                 type: "webassembly/experimental"
> >
> >             },
> >             {
> >
> >                 test: /\.csd$/,
> >                 use: 'raw-loader'
> >
> >             }
> >
> >         ],
> >
> >     },
> >     node: {
> >
> >         fs:'empty',
> >         ws:'empty'
> >
> >     },
> >     externals: ['ws']
> >
> > }
> >
> > I can then import Csound into a Javascript class like this:
> >
> > import libcsound from './libcsound.js';
> >
> > class MyClass {
> >
> >         constructor() {
> >
> >                 libcsound().then((Module) => { console.log("libcsound
> >
> > loaded."); })
> >
> >         }
> >
> > }
> >
> > > On 24 Mar 2018, at 10:26, Michael Gogins <michael.gogins@GMAIL.COM>
> >
> > wrote:
> > > CORS is cross-origin resource sharing, which is a security risk. It is
> > > however common, e.g. for CDNs, see https://enable-cors.org/.
> > >
> > > Regards,
> > > Mike
> > >
> > > -----------------------------------------------------
> > > Michael Gogins
> > > Irreducible Productions
> > > http://michaelgogins.tumblr.com
> > > Michael dot Gogins at gmail dot com
> > >
> > > On Sat, Mar 24, 2018 at 2:18 PM, Steven Yi <stevenyi@gmail.com> wrote:
> > >> Perhaps best to file an issue, either on the Csound tracker or
> > >> csound.github.io tracker. 6.11.0 should be out soon and we can publish
> > >> it to whatever URL is proposed. We could host on csound.com, but we
> > >> could also look at other CDN sites too.  (I think we might not be able
> > >> to follow CORS rules for cross-site scripting and publishing publicly
> > >> on csound.com with github pages, but I haven't looked at that kind of
> > >> thing in a long while).
> > >>
> > >> The benefit of unpacking/installing as part of your project is that
> > >> you don't have to deal with CORS and can depend upon it working
> > >> always.  I think Ed's done some research into making the inclusion
> > >> automated via Webpack and Hlodver's done some research making a single
> > >> JS all-in-one file that might make things simpler. (Perhaps they could
> > >> comment on their efforts here?)
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Sat, Mar 24, 2018 at 12:52 PM, Tarmo Johannes <trmjhnns@gmail.com>
> >
> > wrote:
> > >>> Hi,
> > >>>
> > >>> On Saturday, March 24, 2018 6:05:58 PM EET you wrote:
> > >>>> https://github.com/gogins/csound-extended/releases/
> >
> > download/v0.1.0-beta2//
> >
> > >>>> csound-wasm-6.11.0-beta2.zip.
> > >>>
> > >>> Yes, this works nicely, thanks!
> > >>>
> > >>>
> > >>>
> > >>> I think that it would be nice to have one place online where the
> > >>> latest
> > >>> Csound-wasm build can be reached, so that users don't have to always
> > >>> download unpack and upload the package when they want to use
> >
> > Csound-wasm in
> >
> > >>> their page.
> > >>>
> > >>>
> > >>>
> > >>> Is it now so that the libcsound.wasm file must be exmplicitly in the
> >
> > same
> >
> > >>> folder as the user's html/javascript file? Is it perhaps possible to
> >
> > load it
> >
> > >>> rempotely? In that case I would suggest that http://csound.com/wasm/
> >
> > would
> >
> > >>> be the place set link to.
> > >>>
> > >>>
> > >>>
> > >>> tarmo
> > >>>
> > >>> Csound mailing list Csound@listserv.heanet.ie
> > >>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> > >>> https://github.com/csound/csound/issues Discussions of bugs and
> >
> > features can
> >
> > >>> be posted here
> > >>
> > >> Csound mailing list
> > >> Csound@listserv.heanet.ie
> > >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > >> Send bugs reports to
> > >>
> > >>        https://github.com/csound/csound/issues
> > >>
> > >> Discussions of bugs and features can be posted here
> > >
> > > Csound mailing list
> > > Csound@listserv.heanet.ie
> > > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > > Send bugs reports to
> > >
> > >        https://github.com/csound/csound/issues
> > >
> > > Discussions of bugs and features can be posted here
> >
> > Csound mailing list
> > Csound@listserv.heanet.ie
> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > Send bugs reports to
> >
> >         https://github.com/csound/csound/issues
> >
> > Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date2018-03-26 00:46
FromMichael Gogins
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
Attachmentsconformance.html  
Tarmo: I don't think that the interface in CsoundObj.js is likely to
be changed to conform more closely to the API defined in csound.hpp,
which in turn follows csound.h very very closely.

Victor, can you confirm that?

So, if one wants such an interface that is more like csound.hpp, one
can use the interface in csound_extended.js in the csound-extended
repo, which does conform.

Victor: In case you are interested in the details they are:

Method names in CsoundObj.js are camel case, method names in
csound.hpp are initial caps. There are a few other differences.

In CsoundObj.js (and also in csound.js) calling start before compiling
the orchestra or csd does not work. Performance happens and messages
are printed, but no live audio is heard. Compiling the orchestra or
csd and then calling start works fine. I have attached a test HTML
file that demonstrates this. I believe the cause is that in
CsoundObj.js, _prepareRT is always called within the body of
compileOrc etc., when perhaps it should be called in start. Would
changing this break backwards compatibility with examples etc.?

Both sequences work in csound_extended.js.

The interfaces in csound.node and the Csound for Android app are quite
close to csound_extended.js and a lot of the same pieces run in all
these environments.

Regards,
Mike

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


On Sun, Mar 25, 2018 at 8:27 AM, Victor Lazzarini
 wrote:
> No, csound.js is meant as port of the PNaCl Csound, not as an extension to
> CsoundObj. It is effectively a JS frontend in the same way as PNaCl Csound.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
> On 25 Mar 2018, at 12:19, Michael Gogins  wrote:
>
> It's always possible to implement the existing API first and then add any
> new functionality that may be desired or required, with new names.
>
> This is what I did in csound_extended.js. I think this is the right
> approach.
>
> This does not appear to be the case with csound.js.
>
> Regards,
> Mike
>
> On Sun, Mar 25, 2018, 2:02 AM Tarmo Johannes  wrote:
>>
>> Great!
>>
>> I think something like that would be very welcome from users point of
>> view! If
>> it has no contradictions with security or else, I guess for Csound use in
>> web
>> pages that would be really useful.
>>
>> I saw it has a new API method csound.startRealtime(config*).
>> It is probably necessary to distinguish from csound.start() but I find it
>> very
>> important -  if ever possible -  that all html/javascript associataed APIs
>> would use same or similar methods -  so the same code works in Android,
>> Csound
>> For Node, Wasm, CsoundQt etc.  What do you think?
>>
>> tarmo
>>
>> On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
>> > I made a single js, still work in progress
>> > https://github.com/hlolli/csound-wasm
>> >
>> > but this usage example shows it's simplicity
>> >
>> > 
>> > 
>> >   
>> >     
>> >   
>> >   
>> >     
Click Start realtime once, gotta love chrome's new autoplay >> > ban policy
>> > >> >

Date2018-03-26 09:37
FromVictor Lazzarini
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
I do not think the API will change in the case of CsoundObj, but if it does, it is Steven’s decision,
since he originated the design and wrote most of it.

It is possible, however, if anyone has the time and patience to do it, to write a JS version
of the Csound API that wraps the C or C++ functions more closely. I don’t know how 
useful that would be, since all the interfacing with Web Audio etc will have to be done
outside it. But I guess it would give a lower level access to libcsound WASM.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 26 Mar 2018, at 00:46, Michael Gogins  wrote:
> 
> Tarmo: I don't think that the interface in CsoundObj.js is likely to
> be changed to conform more closely to the API defined in csound.hpp,
> which in turn follows csound.h very very closely.
> 
> Victor, can you confirm that?
> 
> So, if one wants such an interface that is more like csound.hpp, one
> can use the interface in csound_extended.js in the csound-extended
> repo, which does conform.
> 
> Victor: In case you are interested in the details they are:
> 
> Method names in CsoundObj.js are camel case, method names in
> csound.hpp are initial caps. There are a few other differences.
> 
> In CsoundObj.js (and also in csound.js) calling start before compiling
> the orchestra or csd does not work. Performance happens and messages
> are printed, but no live audio is heard. Compiling the orchestra or
> csd and then calling start works fine. I have attached a test HTML
> file that demonstrates this. I believe the cause is that in
> CsoundObj.js, _prepareRT is always called within the body of
> compileOrc etc., when perhaps it should be called in start. Would
> changing this break backwards compatibility with examples etc.?
> 
> Both sequences work in csound_extended.js.
> 
> The interfaces in csound.node and the Csound for Android app are quite
> close to csound_extended.js and a lot of the same pieces run in all
> these environments.
> 
> Regards,
> Mike
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Sun, Mar 25, 2018 at 8:27 AM, Victor Lazzarini
>  wrote:
>> No, csound.js is meant as port of the PNaCl Csound, not as an extension to
>> CsoundObj. It is effectively a JS frontend in the same way as PNaCl Csound.
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>> On 25 Mar 2018, at 12:19, Michael Gogins  wrote:
>> 
>> It's always possible to implement the existing API first and then add any
>> new functionality that may be desired or required, with new names.
>> 
>> This is what I did in csound_extended.js. I think this is the right
>> approach.
>> 
>> This does not appear to be the case with csound.js.
>> 
>> Regards,
>> Mike
>> 
>> On Sun, Mar 25, 2018, 2:02 AM Tarmo Johannes  wrote:
>>> 
>>> Great!
>>> 
>>> I think something like that would be very welcome from users point of
>>> view! If
>>> it has no contradictions with security or else, I guess for Csound use in
>>> web
>>> pages that would be really useful.
>>> 
>>> I saw it has a new API method csound.startRealtime(config*).
>>> It is probably necessary to distinguish from csound.start() but I find it
>>> very
>>> important -  if ever possible -  that all html/javascript associataed APIs
>>> would use same or similar methods -  so the same code works in Android,
>>> Csound
>>> For Node, Wasm, CsoundQt etc.  What do you think?
>>> 
>>> tarmo
>>> 
>>> On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
>>>> I made a single js, still work in progress
>>>> https://github.com/hlolli/csound-wasm
>>>> 
>>>> but this usage example shows it's simplicity
>>>> 
>>>> 
>>>> 
>>>>  
>>>>    
>>>>  
>>>>  
>>>>    
Click Start realtime once, gotta love chrome's new autoplay >>>> ban policy
>>>> >>>>

Date2018-03-26 10:29
FromSteven Yi
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
CsoundObj.js was not written by me, and at the time of its creation I
had commented it would be nice to have it be similar to the CsoundObj
API on Android and iOS.  I think it largely has been.

CsoundObj as an API was not designed to be like csound.hpp, so it
doesn't really make sense to compare them.  CsoundObj was designed to
be platform-specific and idiomatic to the particular language/platform
it is on.  For example, some languages use objects while others may
expect function pointers or blocks. Some languages like Obj-C have
function and argument naming conventions that are different than
something like Java or JS.  CsoundObj was designed to be a
higher-level wrapping than csound.hpp or libcsound and originally
designed for Android/iOS.  Something like having method names with
upper-case would be expected on some platforms (C#) but not on others
(Java, C++, etc.).

CsoundObj implementations are expected to be slightly different per
platform but overall follow similar patterns of usage.  The idea being
a person writing a CsoundObj-based app for iOS would feel comfortable
porting their app to Android and to Web, but have their code be
written in a style that is idiomatic to the target platform.

I have no problems with CsoundObj changing and evolving, but I don't
think it makes sense to make it into something it wasn't designed to
be, which is the exact same on every platform. Also, for the original
platforms for CsoundObj (iOS and Android), it was always possible to
use the full Csound API for more complex tasks than what was in
CsoundObj. On Android this was via the C++ based Csound class, on iOS
via the Csound C API.

Finally, the issues about CsoundObj are taking into account issues
only related to different Javascript-based platforms and is influenced
by implementation details (like auto-wrapping methods when making them
available from WebViews).  I don't find the conventions being pushed
to be particularly idiomatic for Javascript (like function and method
names starting with capitals).

There's nothing preventing a separate API from being written that,
like CsoundObj.js, uses cwrap to get the C functions and then be
written to do what you want. (You could also subclass or wrap
AndroidCsound on Android and add your own methods with different names
and annotations, etc.). That'd solve your particular cross-JavaScript
problem without breaking CsoundObj's design and intent.





On Mon, Mar 26, 2018 at 4:37 AM, Victor Lazzarini
 wrote:
> I do not think the API will change in the case of CsoundObj, but if it does, it is Steven’s decision,
> since he originated the design and wrote most of it.
>
> It is possible, however, if anyone has the time and patience to do it, to write a JS version
> of the Csound API that wraps the C or C++ functions more closely. I don’t know how
> useful that would be, since all the interfacing with Web Audio etc will have to be done
> outside it. But I guess it would give a lower level access to libcsound WASM.
>
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 26 Mar 2018, at 00:46, Michael Gogins  wrote:
>>
>> Tarmo: I don't think that the interface in CsoundObj.js is likely to
>> be changed to conform more closely to the API defined in csound.hpp,
>> which in turn follows csound.h very very closely.
>>
>> Victor, can you confirm that?
>>
>> So, if one wants such an interface that is more like csound.hpp, one
>> can use the interface in csound_extended.js in the csound-extended
>> repo, which does conform.
>>
>> Victor: In case you are interested in the details they are:
>>
>> Method names in CsoundObj.js are camel case, method names in
>> csound.hpp are initial caps. There are a few other differences.
>>
>> In CsoundObj.js (and also in csound.js) calling start before compiling
>> the orchestra or csd does not work. Performance happens and messages
>> are printed, but no live audio is heard. Compiling the orchestra or
>> csd and then calling start works fine. I have attached a test HTML
>> file that demonstrates this. I believe the cause is that in
>> CsoundObj.js, _prepareRT is always called within the body of
>> compileOrc etc., when perhaps it should be called in start. Would
>> changing this break backwards compatibility with examples etc.?
>>
>> Both sequences work in csound_extended.js.
>>
>> The interfaces in csound.node and the Csound for Android app are quite
>> close to csound_extended.js and a lot of the same pieces run in all
>> these environments.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Sun, Mar 25, 2018 at 8:27 AM, Victor Lazzarini
>>  wrote:
>>> No, csound.js is meant as port of the PNaCl Csound, not as an extension to
>>> CsoundObj. It is effectively a JS frontend in the same way as PNaCl Csound.
>>>
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>>
>>> On 25 Mar 2018, at 12:19, Michael Gogins  wrote:
>>>
>>> It's always possible to implement the existing API first and then add any
>>> new functionality that may be desired or required, with new names.
>>>
>>> This is what I did in csound_extended.js. I think this is the right
>>> approach.
>>>
>>> This does not appear to be the case with csound.js.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Sun, Mar 25, 2018, 2:02 AM Tarmo Johannes  wrote:
>>>>
>>>> Great!
>>>>
>>>> I think something like that would be very welcome from users point of
>>>> view! If
>>>> it has no contradictions with security or else, I guess for Csound use in
>>>> web
>>>> pages that would be really useful.
>>>>
>>>> I saw it has a new API method csound.startRealtime(config*).
>>>> It is probably necessary to distinguish from csound.start() but I find it
>>>> very
>>>> important -  if ever possible -  that all html/javascript associataed APIs
>>>> would use same or similar methods -  so the same code works in Android,
>>>> Csound
>>>> For Node, Wasm, CsoundQt etc.  What do you think?
>>>>
>>>> tarmo
>>>>
>>>> On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
>>>>> I made a single js, still work in progress
>>>>> https://github.com/hlolli/csound-wasm
>>>>>
>>>>> but this usage example shows it's simplicity
>>>>>
>>>>> 
>>>>> 
>>>>>  
>>>>>    
>>>>>  
>>>>>  
>>>>>    
Click Start realtime once, gotta love chrome's new autoplay >>>>> ban policy
>>>>> >>>>>

Date2018-03-26 11:28
FromMichael Gogins
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
Thanks for your comments. 

Being idiomatic can be necessary at times, but in this case it was not necessary. 

So now we have a situation where a programmer or musician has one API for Android, iOS, and WASM, and another API for C++, Python, Java, Lua, etc. Rather than one pattern that works on all. 

I have no problem at all with the mere existence of CsoundObj or its implementation of an idiomatic pattern. But it should be an addition not a replacement. 

I suggest that you add the interface of Csound.hpp to CsoundObj.js, and also fix the sequencing difference I mentioned inn my earlier email. 

Then people new to Csound could use the idiom of the platform they know, and people who know Csound but are new to a platform can use the idiom of the synthesizer they know. 

In addition it would be much easier to move pieces especially those using HTML5 from platform to platform. This is really the main reason for standardizing the API.

Best, 
Mike

On Mon, Mar 26, 2018, 06:29 Steven Yi <stevenyi@gmail.com> wrote:
CsoundObj.js was not written by me, and at the time of its creation I
had commented it would be nice to have it be similar to the CsoundObj
API on Android and iOS.  I think it largely has been.

CsoundObj as an API was not designed to be like csound.hpp, so it
doesn't really make sense to compare them.  CsoundObj was designed to
be platform-specific and idiomatic to the particular language/platform
it is on.  For example, some languages use objects while others may
expect function pointers or blocks. Some languages like Obj-C have
function and argument naming conventions that are different than
something like Java or JS.  CsoundObj was designed to be a
higher-level wrapping than csound.hpp or libcsound and originally
designed for Android/iOS.  Something like having method names with
upper-case would be expected on some platforms (C#) but not on others
(Java, C++, etc.).

CsoundObj implementations are expected to be slightly different per
platform but overall follow similar patterns of usage.  The idea being
a person writing a CsoundObj-based app for iOS would feel comfortable
porting their app to Android and to Web, but have their code be
written in a style that is idiomatic to the target platform.

I have no problems with CsoundObj changing and evolving, but I don't
think it makes sense to make it into something it wasn't designed to
be, which is the exact same on every platform. Also, for the original
platforms for CsoundObj (iOS and Android), it was always possible to
use the full Csound API for more complex tasks than what was in
CsoundObj. On Android this was via the C++ based Csound class, on iOS
via the Csound C API.

Finally, the issues about CsoundObj are taking into account issues
only related to different Javascript-based platforms and is influenced
by implementation details (like auto-wrapping methods when making them
available from WebViews).  I don't find the conventions being pushed
to be particularly idiomatic for Javascript (like function and method
names starting with capitals).

There's nothing preventing a separate API from being written that,
like CsoundObj.js, uses cwrap to get the C functions and then be
written to do what you want. (You could also subclass or wrap
AndroidCsound on Android and add your own methods with different names
and annotations, etc.). That'd solve your particular cross-JavaScript
problem without breaking CsoundObj's design and intent.





On Mon, Mar 26, 2018 at 4:37 AM, Victor Lazzarini
<Victor.Lazzarini@mu.ie> wrote:
> I do not think the API will change in the case of CsoundObj, but if it does, it is Steven’s decision,
> since he originated the design and wrote most of it.
>
> It is possible, however, if anyone has the time and patience to do it, to write a JS version
> of the Csound API that wraps the C or C++ functions more closely. I don’t know how
> useful that would be, since all the interfacing with Web Audio etc will have to be done
> outside it. But I guess it would give a lower level access to libcsound WASM.
>
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 26 Mar 2018, at 00:46, Michael Gogins <michael.gogins@GMAIL.COM> wrote:
>>
>> Tarmo: I don't think that the interface in CsoundObj.js is likely to
>> be changed to conform more closely to the API defined in csound.hpp,
>> which in turn follows csound.h very very closely.
>>
>> Victor, can you confirm that?
>>
>> So, if one wants such an interface that is more like csound.hpp, one
>> can use the interface in csound_extended.js in the csound-extended
>> repo, which does conform.
>>
>> Victor: In case you are interested in the details they are:
>>
>> Method names in CsoundObj.js are camel case, method names in
>> csound.hpp are initial caps. There are a few other differences.
>>
>> In CsoundObj.js (and also in csound.js) calling start before compiling
>> the orchestra or csd does not work. Performance happens and messages
>> are printed, but no live audio is heard. Compiling the orchestra or
>> csd and then calling start works fine. I have attached a test HTML
>> file that demonstrates this. I believe the cause is that in
>> CsoundObj.js, _prepareRT is always called within the body of
>> compileOrc etc., when perhaps it should be called in start. Would
>> changing this break backwards compatibility with examples etc.?
>>
>> Both sequences work in csound_extended.js.
>>
>> The interfaces in csound.node and the Csound for Android app are quite
>> close to csound_extended.js and a lot of the same pieces run in all
>> these environments.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Sun, Mar 25, 2018 at 8:27 AM, Victor Lazzarini
>> <Victor.Lazzarini@mu.ie> wrote:
>>> No, csound.js is meant as port of the PNaCl Csound, not as an extension to
>>> CsoundObj. It is effectively a JS frontend in the same way as PNaCl Csound.
>>>
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>>
>>> On 25 Mar 2018, at 12:19, Michael Gogins <michael.gogins@GMAIL.COM> wrote:
>>>
>>> It's always possible to implement the existing API first and then add any
>>> new functionality that may be desired or required, with new names.
>>>
>>> This is what I did in csound_extended.js. I think this is the right
>>> approach.
>>>
>>> This does not appear to be the case with csound.js.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Sun, Mar 25, 2018, 2:02 AM Tarmo Johannes <trmjhnns@gmail.com> wrote:
>>>>
>>>> Great!
>>>>
>>>> I think something like that would be very welcome from users point of
>>>> view! If
>>>> it has no contradictions with security or else, I guess for Csound use in
>>>> web
>>>> pages that would be really useful.
>>>>
>>>> I saw it has a new API method csound.startRealtime(config*).
>>>> It is probably necessary to distinguish from csound.start() but I find it
>>>> very
>>>> important -  if ever possible -  that all html/javascript associataed APIs
>>>> would use same or similar methods -  so the same code works in Android,
>>>> Csound
>>>> For Node, Wasm, CsoundQt etc.  What do you think?
>>>>
>>>> tarmo
>>>>
>>>> On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
>>>>> I made a single js, still work in progress
>>>>> https://github.com/hlolli/csound-wasm
>>>>>
>>>>> but this usage example shows it's simplicity
>>>>>
>>>>> <!DOCTYPE html>
>>>>> <html lang="en">
>>>>>  <head>
>>>>>    <meta charset="utf-8">
>>>>>  </head>
>>>>>  <body>
>>>>>    <h5>Click Start realtime once, gotta love chrome's new autoplay
>>>>> ban policy</h5>
>>>>>    <button id="start">Start realtime</button>
>>>>>    <button onclick="csound.inputMessage('i 1 0 1')">Make beep!</h1>
>>>>>    <script
>>>>>
>>>>> src="https://github.com/hlolli/csound-wasm/releases/download/6.10.0-4/csoun
>>>>> d-wasm-browser.js"></script> <script>    const beeper = `    instr 1
>>>>> asig
>>>>> = poscil:a(0.3, 440) outc asig, asig    endin    `
>>>>> document.getElementById('start').onclick = ()=> {
>>>>> csound.startRealtime();    csound.compileOrc(beeper);    };  </script>
>>>>> </body>
>>>>> </html>
>>>>>
>>>>>
>>>>> This will work anywhere, one can quickly try at
>>>>> https://jsfiddle.net/
>>>>>
>>>>> On 24 March 2018 at 22:19, Edward Costello <phasereset@gmail.com> wrote:
>>>>>> Yes, I have been able to get Csound working inside of a React app
>>>>>> using
>>>>>> Webpack 4.
>>>>>>
>>>>>> I am compiling the WASM using the following:
>>>>>>
>>>>>> emcc -v -O2 -g4 -DINIT_STATIC_MODULES=1 -s SINGLE_FILE=1 -s
>>>>>> MODULARIZE=1
>>>>>> -s EXPORT_NAME=\"'libcsound'\" -s DEMANGLE_SUPPORT=1  -s WASM=1 -s
>>>>>> ASSERTIONS=1 -s "BINARYEN_METHOD='native-wasm'" -s LINKABLE=1 -s
>>>>>> RESERVED_FUNCTION_POINTERS=1 -s TOTAL_MEMORY=268435456 -s
>>>>>> ALLOW_MEMORY_GROWTH=1 -s NO_EXIT_RUNTIME=0 -s
>>>>>> EXTRA_EXPORTED_RUNTIME_METHODS="['FS', 'cwrap']" CsoundObj.bc
>>>>>> FileList.bc
>>>>>> libcsound.a ../deps/libsndfile-1.0.25/libsndfile-wasm.a -o
>>>>>> libcsound.js
>>>>>>
>>>>>> Notice I added the SINGLE_FILE, MODULARIZE and EXPORT_NAME option. (As
>>>>>> an
>>>>>> aside I don’t think it’s necessary to have the Csound_Obj exported
>>>>>> functions anymore in the above line as someone added the Emscripten
>>>>>> Keep
>>>>>> Alive macro to the CsoundObj.c source).
>>>>>> Also using SINGLE_FILE is not necessary, and seems to be slower to
>>>>>> load
>>>>>> than without.
>>>>>>
>>>>>> In my Webpack 4 config:
>>>>>>
>>>>>> module.exports = {
>>>>>>
>>>>>>    module: {
>>>>>>
>>>>>>        rules: [
>>>>>>
>>>>>>            {
>>>>>>
>>>>>>                test: /\.js$/,
>>>>>>                exclude: /node_modules/,
>>>>>>                use: {
>>>>>>
>>>>>>                    loader: "babel-loader"
>>>>>>
>>>>>>                }
>>>>>>
>>>>>>            },
>>>>>>            {
>>>>>>
>>>>>>                test: /\.wasm$/,
>>>>>>                type: "webassembly/experimental"
>>>>>>
>>>>>>            },
>>>>>>            {
>>>>>>
>>>>>>                test: /\.csd$/,
>>>>>>                use: 'raw-loader'
>>>>>>
>>>>>>            }
>>>>>>
>>>>>>        ],
>>>>>>
>>>>>>    },
>>>>>>    node: {
>>>>>>
>>>>>>        fs:'empty',
>>>>>>        ws:'empty'
>>>>>>
>>>>>>    },
>>>>>>    externals: ['ws']
>>>>>>
>>>>>> }
>>>>>>
>>>>>> I can then import Csound into a Javascript class like this:
>>>>>>
>>>>>> import libcsound from './libcsound.js';
>>>>>>
>>>>>> class MyClass {
>>>>>>
>>>>>>        constructor() {
>>>>>>
>>>>>>                libcsound().then((Module) => { console.log("libcsound
>>>>>>
>>>>>> loaded."); })
>>>>>>
>>>>>>        }
>>>>>>
>>>>>> }
>>>>>>
>>>>>>> On 24 Mar 2018, at 10:26, Michael Gogins <michael.gogins@GMAIL.COM>
>>>>>>
>>>>>> wrote:
>>>>>>> CORS is cross-origin resource sharing, which is a security risk. It
>>>>>>> is
>>>>>>> however common, e.g. for CDNs, see https://enable-cors.org/.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike
>>>>>>>
>>>>>>> -----------------------------------------------------
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://michaelgogins.tumblr.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>> On Sat, Mar 24, 2018 at 2:18 PM, Steven Yi <stevenyi@gmail.com>
>>>>>>> wrote:
>>>>>>>> Perhaps best to file an issue, either on the Csound tracker or
>>>>>>>> csound.github.io tracker. 6.11.0 should be out soon and we can
>>>>>>>> publish
>>>>>>>> it to whatever URL is proposed. We could host on csound.com, but we
>>>>>>>> could also look at other CDN sites too.  (I think we might not be
>>>>>>>> able
>>>>>>>> to follow CORS rules for cross-site scripting and publishing
>>>>>>>> publicly
>>>>>>>> on csound.com with github pages, but I haven't looked at that kind
>>>>>>>> of
>>>>>>>> thing in a long while).
>>>>>>>>
>>>>>>>> The benefit of unpacking/installing as part of your project is that
>>>>>>>> you don't have to deal with CORS and can depend upon it working
>>>>>>>> always.  I think Ed's done some research into making the inclusion
>>>>>>>> automated via Webpack and Hlodver's done some research making a
>>>>>>>> single
>>>>>>>> JS all-in-one file that might make things simpler. (Perhaps they
>>>>>>>> could
>>>>>>>> comment on their efforts here?)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Mar 24, 2018 at 12:52 PM, Tarmo Johannes
>>>>>>>> <trmjhnns@gmail.com>
>>>>>>
>>>>>> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Saturday, March 24, 2018 6:05:58 PM EET you wrote:
>>>>>>>>>> https://github.com/gogins/csound-extended/releases/
>>>>>>
>>>>>> download/v0.1.0-beta2//
>>>>>>
>>>>>>>>>> csound-wasm-6.11.0-beta2.zip.
>>>>>>>>>
>>>>>>>>> Yes, this works nicely, thanks!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think that it would be nice to have one place online where the
>>>>>>>>> latest
>>>>>>>>> Csound-wasm build can be reached, so that users don't have to
>>>>>>>>> always
>>>>>>>>> download unpack and upload the package when they want to use
>>>>>>
>>>>>> Csound-wasm in
>>>>>>
>>>>>>>>> their page.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is it now so that the libcsound.wasm file must be exmplicitly in
>>>>>>>>> the
>>>>>>
>>>>>> same
>>>>>>
>>>>>>>>> folder as the user's html/javascript file? Is it perhaps possible
>>>>>>>>> to
>>>>>>
>>>>>> load it
>>>>>>
>>>>>>>>> rempotely? In that case I would suggest that
>>>>>>>>> http://csound.com/wasm/
>>>>>>
>>>>>> would
>>>>>>
>>>>>>>>> be the place set link to.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> tarmo
>>>>>>>>>
>>>>>>>>> Csound mailing list Csound@listserv.heanet.ie
>>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports
>>>>>>>>> to
>>>>>>>>> https://github.com/csound/csound/issues Discussions of bugs and
>>>>>>
>>>>>> features can
>>>>>>
>>>>>>>>> be posted here
>>>>>>>>
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>
>>>>>>>>       https://github.com/csound/csound/issues
>>>>>>>>
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>
>>>>>>>       https://github.com/csound/csound/issues
>>>>>>>
>>>>>>> Discussions of bugs and features can be posted here
>>>>>>
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>
>>>>>>        https://github.com/csound/csound/issues
>>>>>>
>>>>>> Discussions of bugs and features can be posted here
>>>>>
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>        https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>>
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>        https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>
>>> Csound mailing list Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>> be posted here
>>>
>>> Csound mailing list Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>> be posted here
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>> <conformance.html>
>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date2018-03-26 12:14
FromMichael Gogins
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
What you suggest is similar to what I have done in csound_extended.js.

I used Emscripten's Embind wrapper generator. A single declaration wraps any signature that contains only numbers or std::strings as parameters. 

I subclassed Csound in csound.hpp as CsoundEmbind to create methods with std::string in place of char *.

Then I wrapped a CsoundEmbind object in a CsoundWebAudio JavaScript class which just uses the Web Audio and Web MIDI code from CsoundObj.js.

I do expose more of the Csound API this way and the semantics and sequencing are the same. 

The WASM Working Group is planning features that will make this easier. At some point pthreads and then dynamic loading will be possible. Then browser and DOM objects will appear in WASM, making it possible to code the Web Audio driver in C++.

Regards, 
Mike

On Mon, Mar 26, 2018, 4:37 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
I do not think the API will change in the case of CsoundObj, but if it does, it is Steven’s decision,
since he originated the design and wrote most of it.

It is possible, however, if anyone has the time and patience to do it, to write a JS version
of the Csound API that wraps the C or C++ functions more closely. I don’t know how
useful that would be, since all the interfacing with Web Audio etc will have to be done
outside it. But I guess it would give a lower level access to libcsound WASM.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

> On 26 Mar 2018, at 00:46, Michael Gogins <michael.gogins@GMAIL.COM> wrote:
>
> Tarmo: I don't think that the interface in CsoundObj.js is likely to
> be changed to conform more closely to the API defined in csound.hpp,
> which in turn follows csound.h very very closely.
>
> Victor, can you confirm that?
>
> So, if one wants such an interface that is more like csound.hpp, one
> can use the interface in csound_extended.js in the csound-extended
> repo, which does conform.
>
> Victor: In case you are interested in the details they are:
>
> Method names in CsoundObj.js are camel case, method names in
> csound.hpp are initial caps. There are a few other differences.
>
> In CsoundObj.js (and also in csound.js) calling start before compiling
> the orchestra or csd does not work. Performance happens and messages
> are printed, but no live audio is heard. Compiling the orchestra or
> csd and then calling start works fine. I have attached a test HTML
> file that demonstrates this. I believe the cause is that in
> CsoundObj.js, _prepareRT is always called within the body of
> compileOrc etc., when perhaps it should be called in start. Would
> changing this break backwards compatibility with examples etc.?
>
> Both sequences work in csound_extended.js.
>
> The interfaces in csound.node and the Csound for Android app are quite
> close to csound_extended.js and a lot of the same pieces run in all
> these environments.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Sun, Mar 25, 2018 at 8:27 AM, Victor Lazzarini
> <Victor.Lazzarini@mu.ie> wrote:
>> No, csound.js is meant as port of the PNaCl Csound, not as an extension to
>> CsoundObj. It is effectively a JS frontend in the same way as PNaCl Csound.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>> On 25 Mar 2018, at 12:19, Michael Gogins <michael.gogins@GMAIL.COM> wrote:
>>
>> It's always possible to implement the existing API first and then add any
>> new functionality that may be desired or required, with new names.
>>
>> This is what I did in csound_extended.js. I think this is the right
>> approach.
>>
>> This does not appear to be the case with csound.js.
>>
>> Regards,
>> Mike
>>
>> On Sun, Mar 25, 2018, 2:02 AM Tarmo Johannes <trmjhnns@gmail.com> wrote:
>>>
>>> Great!
>>>
>>> I think something like that would be very welcome from users point of
>>> view! If
>>> it has no contradictions with security or else, I guess for Csound use in
>>> web
>>> pages that would be really useful.
>>>
>>> I saw it has a new API method csound.startRealtime(config*).
>>> It is probably necessary to distinguish from csound.start() but I find it
>>> very
>>> important -  if ever possible -  that all html/javascript associataed APIs
>>> would use same or similar methods -  so the same code works in Android,
>>> Csound
>>> For Node, Wasm, CsoundQt etc.  What do you think?
>>>
>>> tarmo
>>>
>>> On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
>>>> I made a single js, still work in progress
>>>> https://github.com/hlolli/csound-wasm
>>>>
>>>> but this usage example shows it's simplicity
>>>>
>>>> <!DOCTYPE html>
>>>> <html lang="en">
>>>>  <head>
>>>>    <meta charset="utf-8">
>>>>  </head>
>>>>  <body>
>>>>    <h5>Click Start realtime once, gotta love chrome's new autoplay
>>>> ban policy</h5>
>>>>    <button id="start">Start realtime</button>
>>>>    <button onclick="csound.inputMessage('i 1 0 1')">Make beep!</h1>
>>>>    <script
>>>>
>>>> src="https://github.com/hlolli/csound-wasm/releases/download/6.10.0-4/csoun
>>>> d-wasm-browser.js"></script> <script>    const beeper = `    instr 1
>>>> asig
>>>> = poscil:a(0.3, 440) outc asig, asig    endin    `
>>>> document.getElementById('start').onclick = ()=> {
>>>> csound.startRealtime();    csound.compileOrc(beeper);    };  </script>
>>>> </body>
>>>> </html>
>>>>
>>>>
>>>> This will work anywhere, one can quickly try at
>>>> https://jsfiddle.net/
>>>>
>>>> On 24 March 2018 at 22:19, Edward Costello <phasereset@gmail.com> wrote:
>>>>> Yes, I have been able to get Csound working inside of a React app
>>>>> using
>>>>> Webpack 4.
>>>>>
>>>>> I am compiling the WASM using the following:
>>>>>
>>>>> emcc -v -O2 -g4 -DINIT_STATIC_MODULES=1 -s SINGLE_FILE=1 -s
>>>>> MODULARIZE=1
>>>>> -s EXPORT_NAME=\"'libcsound'\" -s DEMANGLE_SUPPORT=1  -s WASM=1 -s
>>>>> ASSERTIONS=1 -s "BINARYEN_METHOD='native-wasm'" -s LINKABLE=1 -s
>>>>> RESERVED_FUNCTION_POINTERS=1 -s TOTAL_MEMORY=268435456 -s
>>>>> ALLOW_MEMORY_GROWTH=1 -s NO_EXIT_RUNTIME=0 -s
>>>>> EXTRA_EXPORTED_RUNTIME_METHODS="['FS', 'cwrap']" CsoundObj.bc
>>>>> FileList.bc
>>>>> libcsound.a ../deps/libsndfile-1.0.25/libsndfile-wasm.a -o
>>>>> libcsound.js
>>>>>
>>>>> Notice I added the SINGLE_FILE, MODULARIZE and EXPORT_NAME option. (As
>>>>> an
>>>>> aside I don’t think it’s necessary to have the Csound_Obj exported
>>>>> functions anymore in the above line as someone added the Emscripten
>>>>> Keep
>>>>> Alive macro to the CsoundObj.c source).
>>>>> Also using SINGLE_FILE is not necessary, and seems to be slower to
>>>>> load
>>>>> than without.
>>>>>
>>>>> In my Webpack 4 config:
>>>>>
>>>>> module.exports = {
>>>>>
>>>>>    module: {
>>>>>
>>>>>        rules: [
>>>>>
>>>>>            {
>>>>>
>>>>>                test: /\.js$/,
>>>>>                exclude: /node_modules/,
>>>>>                use: {
>>>>>
>>>>>                    loader: "babel-loader"
>>>>>
>>>>>                }
>>>>>
>>>>>            },
>>>>>            {
>>>>>
>>>>>                test: /\.wasm$/,
>>>>>                type: "webassembly/experimental"
>>>>>
>>>>>            },
>>>>>            {
>>>>>
>>>>>                test: /\.csd$/,
>>>>>                use: 'raw-loader'
>>>>>
>>>>>            }
>>>>>
>>>>>        ],
>>>>>
>>>>>    },
>>>>>    node: {
>>>>>
>>>>>        fs:'empty',
>>>>>        ws:'empty'
>>>>>
>>>>>    },
>>>>>    externals: ['ws']
>>>>>
>>>>> }
>>>>>
>>>>> I can then import Csound into a Javascript class like this:
>>>>>
>>>>> import libcsound from './libcsound.js';
>>>>>
>>>>> class MyClass {
>>>>>
>>>>>        constructor() {
>>>>>
>>>>>                libcsound().then((Module) => { console.log("libcsound
>>>>>
>>>>> loaded."); })
>>>>>
>>>>>        }
>>>>>
>>>>> }
>>>>>
>>>>>> On 24 Mar 2018, at 10:26, Michael Gogins <michael.gogins@GMAIL.COM>
>>>>>
>>>>> wrote:
>>>>>> CORS is cross-origin resource sharing, which is a security risk. It
>>>>>> is
>>>>>> however common, e.g. for CDNs, see https://enable-cors.org/.
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>> On Sat, Mar 24, 2018 at 2:18 PM, Steven Yi <stevenyi@gmail.com>
>>>>>> wrote:
>>>>>>> Perhaps best to file an issue, either on the Csound tracker or
>>>>>>> csound.github.io tracker. 6.11.0 should be out soon and we can
>>>>>>> publish
>>>>>>> it to whatever URL is proposed. We could host on csound.com, but we
>>>>>>> could also look at other CDN sites too.  (I think we might not be
>>>>>>> able
>>>>>>> to follow CORS rules for cross-site scripting and publishing
>>>>>>> publicly
>>>>>>> on csound.com with github pages, but I haven't looked at that kind
>>>>>>> of
>>>>>>> thing in a long while).
>>>>>>>
>>>>>>> The benefit of unpacking/installing as part of your project is that
>>>>>>> you don't have to deal with CORS and can depend upon it working
>>>>>>> always.  I think Ed's done some research into making the inclusion
>>>>>>> automated via Webpack and Hlodver's done some research making a
>>>>>>> single
>>>>>>> JS all-in-one file that might make things simpler. (Perhaps they
>>>>>>> could
>>>>>>> comment on their efforts here?)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Mar 24, 2018 at 12:52 PM, Tarmo Johannes
>>>>>>> <trmjhnns@gmail.com>
>>>>>
>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Saturday, March 24, 2018 6:05:58 PM EET you wrote:
>>>>>>>>> https://github.com/gogins/csound-extended/releases/
>>>>>
>>>>> download/v0.1.0-beta2//
>>>>>
>>>>>>>>> csound-wasm-6.11.0-beta2.zip.
>>>>>>>>
>>>>>>>> Yes, this works nicely, thanks!
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I think that it would be nice to have one place online where the
>>>>>>>> latest
>>>>>>>> Csound-wasm build can be reached, so that users don't have to
>>>>>>>> always
>>>>>>>> download unpack and upload the package when they want to use
>>>>>
>>>>> Csound-wasm in
>>>>>
>>>>>>>> their page.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Is it now so that the libcsound.wasm file must be exmplicitly in
>>>>>>>> the
>>>>>
>>>>> same
>>>>>
>>>>>>>> folder as the user's html/javascript file? Is it perhaps possible
>>>>>>>> to
>>>>>
>>>>> load it
>>>>>
>>>>>>>> rempotely? In that case I would suggest that
>>>>>>>> http://csound.com/wasm/
>>>>>
>>>>> would
>>>>>
>>>>>>>> be the place set link to.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> tarmo
>>>>>>>>
>>>>>>>> Csound mailing list Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports
>>>>>>>> to
>>>>>>>> https://github.com/csound/csound/issues Discussions of bugs and
>>>>>
>>>>> features can
>>>>>
>>>>>>>> be posted here
>>>>>>>
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>
>>>>>>>       https://github.com/csound/csound/issues
>>>>>>>
>>>>>>> Discussions of bugs and features can be posted here
>>>>>>
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>
>>>>>>       https://github.com/csound/csound/issues
>>>>>>
>>>>>> Discussions of bugs and features can be posted here
>>>>>
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>
>>>>>        https://github.com/csound/csound/issues
>>>>>
>>>>> Discussions of bugs and features can be posted here
>>>>
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>        https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
> <conformance.html>


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date2018-03-26 12:15
FromSteven Yi
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
I'll say it again: the CsoundObj API is designed to be idiomatic and
platform-specific, but share common design as much as possible to make
things easy to port between platforms.

Your comments about CsoundObj API don't make sense as it *IS* an
addition and not a replacment.  As I said, it is a higher-level API,
and access to the lower level ones was always available (C API on iOS,
C++ API on Android, cwrap on Web Csound).  Again, the whole point of
it is is to be platform-specific.

Does using upper-case named methods in Java make it look like anything
they'd see or learn when reading a "How to Program Android
Applications" book? Or any API documentation at all for Android? No.
The API for Csound for Android was designed with beginning Android
developers in mind, same as CsoundObj on iOS, etc. (It sticks out like
a sore thumb to me too whenever I use the C++ or wrapped API in Java
and Python on the desktop. And why not snake_case on Python?)  The
reason for that is the assumption not everyone who wants to make an
Android or iOS or Web app is going to be a seasoned programmer (maybe
just a musician with a dream) and making things idiomatic and in line
with documentation and conventions found for that platform/language
should make it easier for those users.

If you're an experienced Csound APi users on a different platform and
want to use the C++ API on Android, you can via the AndroidCsound
class, which is provided in the CsoundForAndroid SDK.  CsoundObj
itself uses it.  If you want to use the C API on iOS from Obj-C or
Swift, great, it's there. If you want to make a csound.hpp compatible
API for WebCsound, great, use cwrap and create one, no one is stopping
you.

In all of these cases, CsoundObj is an addition and adds tailoring to
the target language/platform.

Anyways, I know what you want, which is to write one JS app and run it
on multiple platforms. That isn't the goal of CsoundObj and CsoundObj
being around does not prevent you from achieving your goal. (And could
a CsoundObj implementation be made for each JS platform that was
identical to each other and still in-line with the other CsoundObj
implementations? Yes.)

The sequencing difference seems like a bug that should be fixed, but
otherwise these criticisms don't make much sense to me.


On Mon, Mar 26, 2018 at 6:28 AM, Michael Gogins
 wrote:
> Thanks for your comments.
>
> Being idiomatic can be necessary at times, but in this case it was not
> necessary.
>
> So now we have a situation where a programmer or musician has one API for
> Android, iOS, and WASM, and another API for C++, Python, Java, Lua, etc.
> Rather than one pattern that works on all.
>
> I have no problem at all with the mere existence of CsoundObj or its
> implementation of an idiomatic pattern. But it should be an addition not a
> replacement.
>
> I suggest that you add the interface of Csound.hpp to CsoundObj.js, and also
> fix the sequencing difference I mentioned inn my earlier email.
>
> Then people new to Csound could use the idiom of the platform they know, and
> people who know Csound but are new to a platform can use the idiom of the
> synthesizer they know.
>
> In addition it would be much easier to move pieces especially those using
> HTML5 from platform to platform. This is really the main reason for
> standardizing the API.
>
> Best,
> Mike
>
> On Mon, Mar 26, 2018, 06:29 Steven Yi  wrote:
>>
>> CsoundObj.js was not written by me, and at the time of its creation I
>> had commented it would be nice to have it be similar to the CsoundObj
>> API on Android and iOS.  I think it largely has been.
>>
>> CsoundObj as an API was not designed to be like csound.hpp, so it
>> doesn't really make sense to compare them.  CsoundObj was designed to
>> be platform-specific and idiomatic to the particular language/platform
>> it is on.  For example, some languages use objects while others may
>> expect function pointers or blocks. Some languages like Obj-C have
>> function and argument naming conventions that are different than
>> something like Java or JS.  CsoundObj was designed to be a
>> higher-level wrapping than csound.hpp or libcsound and originally
>> designed for Android/iOS.  Something like having method names with
>> upper-case would be expected on some platforms (C#) but not on others
>> (Java, C++, etc.).
>>
>> CsoundObj implementations are expected to be slightly different per
>> platform but overall follow similar patterns of usage.  The idea being
>> a person writing a CsoundObj-based app for iOS would feel comfortable
>> porting their app to Android and to Web, but have their code be
>> written in a style that is idiomatic to the target platform.
>>
>> I have no problems with CsoundObj changing and evolving, but I don't
>> think it makes sense to make it into something it wasn't designed to
>> be, which is the exact same on every platform. Also, for the original
>> platforms for CsoundObj (iOS and Android), it was always possible to
>> use the full Csound API for more complex tasks than what was in
>> CsoundObj. On Android this was via the C++ based Csound class, on iOS
>> via the Csound C API.
>>
>> Finally, the issues about CsoundObj are taking into account issues
>> only related to different Javascript-based platforms and is influenced
>> by implementation details (like auto-wrapping methods when making them
>> available from WebViews).  I don't find the conventions being pushed
>> to be particularly idiomatic for Javascript (like function and method
>> names starting with capitals).
>>
>> There's nothing preventing a separate API from being written that,
>> like CsoundObj.js, uses cwrap to get the C functions and then be
>> written to do what you want. (You could also subclass or wrap
>> AndroidCsound on Android and add your own methods with different names
>> and annotations, etc.). That'd solve your particular cross-JavaScript
>> problem without breaking CsoundObj's design and intent.
>>
>>
>>
>>
>>
>> On Mon, Mar 26, 2018 at 4:37 AM, Victor Lazzarini
>>  wrote:
>> > I do not think the API will change in the case of CsoundObj, but if it
>> > does, it is Steven’s decision,
>> > since he originated the design and wrote most of it.
>> >
>> > It is possible, however, if anyone has the time and patience to do it,
>> > to write a JS version
>> > of the Csound API that wraps the C or C++ functions more closely. I
>> > don’t know how
>> > useful that would be, since all the interfacing with Web Audio etc will
>> > have to be done
>> > outside it. But I guess it would give a lower level access to libcsound
>> > WASM.
>> >
>> > ========================
>> > Prof. Victor Lazzarini
>> > Dean of Arts, Celtic Studies, and Philosophy,
>> > Maynooth University,
>> > Maynooth, Co Kildare, Ireland
>> > Tel: 00 353 7086936
>> > Fax: 00 353 1 7086952
>> >
>> >> On 26 Mar 2018, at 00:46, Michael Gogins 
>> >> wrote:
>> >>
>> >> Tarmo: I don't think that the interface in CsoundObj.js is likely to
>> >> be changed to conform more closely to the API defined in csound.hpp,
>> >> which in turn follows csound.h very very closely.
>> >>
>> >> Victor, can you confirm that?
>> >>
>> >> So, if one wants such an interface that is more like csound.hpp, one
>> >> can use the interface in csound_extended.js in the csound-extended
>> >> repo, which does conform.
>> >>
>> >> Victor: In case you are interested in the details they are:
>> >>
>> >> Method names in CsoundObj.js are camel case, method names in
>> >> csound.hpp are initial caps. There are a few other differences.
>> >>
>> >> In CsoundObj.js (and also in csound.js) calling start before compiling
>> >> the orchestra or csd does not work. Performance happens and messages
>> >> are printed, but no live audio is heard. Compiling the orchestra or
>> >> csd and then calling start works fine. I have attached a test HTML
>> >> file that demonstrates this. I believe the cause is that in
>> >> CsoundObj.js, _prepareRT is always called within the body of
>> >> compileOrc etc., when perhaps it should be called in start. Would
>> >> changing this break backwards compatibility with examples etc.?
>> >>
>> >> Both sequences work in csound_extended.js.
>> >>
>> >> The interfaces in csound.node and the Csound for Android app are quite
>> >> close to csound_extended.js and a lot of the same pieces run in all
>> >> these environments.
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >> -----------------------------------------------------
>> >> Michael Gogins
>> >> Irreducible Productions
>> >> http://michaelgogins.tumblr.com
>> >> Michael dot Gogins at gmail dot com
>> >>
>> >>
>> >> On Sun, Mar 25, 2018 at 8:27 AM, Victor Lazzarini
>> >>  wrote:
>> >>> No, csound.js is meant as port of the PNaCl Csound, not as an
>> >>> extension to
>> >>> CsoundObj. It is effectively a JS frontend in the same way as PNaCl
>> >>> Csound.
>> >>>
>> >>> Victor Lazzarini
>> >>> Dean of Arts, Celtic Studies, and Philosophy
>> >>> Maynooth University
>> >>> Ireland
>> >>>
>> >>> On 25 Mar 2018, at 12:19, Michael Gogins 
>> >>> wrote:
>> >>>
>> >>> It's always possible to implement the existing API first and then add
>> >>> any
>> >>> new functionality that may be desired or required, with new names.
>> >>>
>> >>> This is what I did in csound_extended.js. I think this is the right
>> >>> approach.
>> >>>
>> >>> This does not appear to be the case with csound.js.
>> >>>
>> >>> Regards,
>> >>> Mike
>> >>>
>> >>> On Sun, Mar 25, 2018, 2:02 AM Tarmo Johannes 
>> >>> wrote:
>> >>>>
>> >>>> Great!
>> >>>>
>> >>>> I think something like that would be very welcome from users point of
>> >>>> view! If
>> >>>> it has no contradictions with security or else, I guess for Csound
>> >>>> use in
>> >>>> web
>> >>>> pages that would be really useful.
>> >>>>
>> >>>> I saw it has a new API method csound.startRealtime(config*).
>> >>>> It is probably necessary to distinguish from csound.start() but I
>> >>>> find it
>> >>>> very
>> >>>> important -  if ever possible -  that all html/javascript associataed
>> >>>> APIs
>> >>>> would use same or similar methods -  so the same code works in
>> >>>> Android,
>> >>>> Csound
>> >>>> For Node, Wasm, CsoundQt etc.  What do you think?
>> >>>>
>> >>>> tarmo
>> >>>>
>> >>>> On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
>> >>>>> I made a single js, still work in progress
>> >>>>> https://github.com/hlolli/csound-wasm
>> >>>>>
>> >>>>> but this usage example shows it's simplicity
>> >>>>>
>> >>>>> 
>> >>>>> 
>> >>>>>  
>> >>>>>    
>> >>>>>  
>> >>>>>  
>> >>>>>    
Click Start realtime once, gotta love chrome's new autoplay >> >>>>> ban policy
>> >>>>> >> >>>>>

Date2018-03-27 00:44
FromPatrick Hinkle
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
One of the first opcodes and associated example files from the Csound Manual that I tried to implement and run is the flooper2 example program shown below, in the same form as in my text editor, except that I am trying to play a little jam session of mine that I recorded called "ringmod.wav" and I am trying to use flooper2 and the csound command line to play it back in different times and ways/w/different parameters. When I run the following csound command in the Terminal:
csound -Q0 -+rtaudio=coreaudio -odac -iadc flooper21.csd

& the flooper21.csd file that I try to run is in this form:

<CsoundSynthesizer>
<CsOptions>

</CsOptions>
<CsInstruments>

sr = 44100
ksmps = 32
nchnls = 2
0dbfs  = 1

instr 1
; looping back and forth,  0.05 crossfade 
kst  line     .2, p3, 2 ;vary loopstartpoint
;aout flooper2 .8, 1, 0, kst, 0.05, 1, 0, 2  
aout flooper2 16000, 1, 1, 5, 0.05, 1 ;LOOP STARTS AT 1 SEC, 
;FOR 4 SEC, 0.05 CROSSFADE. 
     outs     aout, aout

endin
</CsInstruments>
<CsScore>
; Its table size is deferred,
; and format taken from the soundfile header
f 1 0 0 1 "ringmod.wav" 2 3 2

i 1 0 12
e
</CsScore>
</CsoundSynthesizer>

But I get the following output & error:


0dBFS level = 32768.0

--Csound version 6.10 (double samples) Dec 21 2017 

[commit: 3bc82359c20c6c35cf0240b9fe8c8fb4ad29ddf4]

libsndfile-1.0.25

WARNING: could not open library '/Library/Frameworks/CsoundLib64.framework/Versions/6.0/Resources/Opcodes64/librtjack.dylib' (-1)

UnifiedCSD:  flooper21.csd

STARTING FILE

Creating options

Creating orchestra

closing tag

Creating score

rtaudio: coreaaudio-AuHAL module enabled

rtmidi: PortMIDI module enabled

Elapsed time at end of orchestra compile: real: 0.034s, CPU: 0.004s

sorting score ...

... done

Elapsed time at end of score sort: real: 0.034s, CPU: 0.004s

0: IAC Driver Bus 1 (portmidi)

1: IAC Driver IAC Bus 2 (portmidi)

2: IAC Driver IAC Bus 3 (portmidi)

PortMIDI: selected output device 0: 'IAC Driver Bus 1' (CoreMIDI)

graphics suppressed, ascii substituted

0dBFS level = 1.0

orch now loaded

audio buffered in 1024 sample-frame blocks

==========================================================

AuHAL Module: found 2 input device(s):

1: Built-in Microphone (2 channels) 

2: Movavi Sound Grabber (2 channels) 

selected input device: Built-in Microphone 

***** AuHAL module: input device open with 1024 buffer frames

reading 4096-byte blks of shorts from adc (RAW)

AuHAL Module: found 2 output device(s):

1: Built-in Output (2 channels) 

2: Movavi Sound Grabber (2 channels) 

selected output device: Built-in Output 

***** AuHAL module: output device open with 1024 buffer frames

==========================================================

writing 2048 sample blks of 64-bit floats to dac 

SECTION 1:

ftable 1:

deferred alloc for fox.wav

soundin cannot open fox.wav

ftable 1: Failed to open file fox.wav

f  1     0.00     0.00     1.00  "fox.wav" ...

new alloc for instr 1:

Invalid ftable no. 1.000000

INIT ERROR in instr 1: function table not found


aout flooper2 .8 1 0 kst 0.05 1 0 0

  B  0.000 - note deleted.  i1 had 1 init errors

Score finished in csoundPerform().

inactive allocs returned to freespace

end of score.   overall amps:  0.00000  0.00000

  overall samples out of range:        0        0

1 errors in performance

Elapsed time at end of performance: real: 3.435s, CPU: 0.062s

AuHAL module: device closed

0 2048 sample blks of 64-bit floats written to dac


I don't know where this "fox.wav" file is coming from since I replaced it with my jam session file "ringmod.wav", but it seems to be struggling to open my GEN01 function table.
Do you know of any ways that I can fix this program (or maybe command line) to play my "ringmod.wav" file? Any help would be greatly appreciated.
Patrick
















On Sun, Mar 25, 2018 at 4:27 AM, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
No, csound.js is meant as port of the PNaCl Csound, not as an extension to CsoundObj. It is effectively a JS frontend in the same way as PNaCl Csound.

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

On 25 Mar 2018, at 12:19, Michael Gogins <michael.gogins@GMAIL.COM> wrote:

It's always possible to implement the existing API first and then add any new functionality that may be desired or required, with new names. 

This is what I did in csound_extended.js. I think this is the right approach. 

This does not appear to be the case with csound.js. 

Regards, 
Mike

On Sun, Mar 25, 2018, 2:02 AM Tarmo Johannes <trmjhnns@gmail.com> wrote:
Great!

I think something like that would be very welcome from users point of view! If
it has no contradictions with security or else, I guess for Csound use in web
pages that would be really useful.

I saw it has a new API method csound.startRealtime(config*).
It is probably necessary to distinguish from csound.start() but I find it very
important -  if ever possible -  that all html/javascript associataed APIs
would use same or similar methods -  so the same code works in Android, Csound
For Node, Wasm, CsoundQt etc.  What do you think?

tarmo

On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
> I made a single js, still work in progress
> https://github.com/hlolli/csound-wasm
>
> but this usage example shows it's simplicity
>
> <!DOCTYPE html>
> <html lang="en">
>   <head>
>     <meta charset="utf-8">
>   </head>
>   <body>
>     <h5>Click Start realtime once, gotta love chrome's new autoplay
> ban policy</h5>
>     <button id="start">Start realtime</button>
>     <button onclick="csound.inputMessage('i 1 0 1')">Make beep!</h1>
>     <script
> src="https://github.com/hlolli/csound-wasm/releases/download/6.10.0-4/csoun
> d-wasm-browser.js"></script> <script>    const beeper = `    instr 1    asig
> = poscil:a(0.3, 440) outc asig, asig    endin    `
> document.getElementById('start').onclick = ()=> {
> csound.startRealtime();    csound.compileOrc(beeper);    };  </script>
> </body>
> </html>
>
>
> This will work anywhere, one can quickly try at
> https://jsfiddle.net/
>
> On 24 March 2018 at 22:19, Edward Costello <phasereset@gmail.com> wrote:
> > Yes, I have been able to get Csound working inside of a React app using
> > Webpack 4.
> >
> > I am compiling the WASM using the following:
> >
> > emcc -v -O2 -g4 -DINIT_STATIC_MODULES=1 -s SINGLE_FILE=1 -s MODULARIZE=1
> > -s EXPORT_NAME=\"'libcsound'\" -s DEMANGLE_SUPPORT=1  -s WASM=1 -s
> > ASSERTIONS=1 -s "BINARYEN_METHOD='native-wasm'" -s LINKABLE=1 -s
> > RESERVED_FUNCTION_POINTERS=1 -s TOTAL_MEMORY=268435456 -s
> > ALLOW_MEMORY_GROWTH=1 -s NO_EXIT_RUNTIME=0 -s
> > EXTRA_EXPORTED_RUNTIME_METHODS="['FS', 'cwrap']" CsoundObj.bc FileList.bc
> > libcsound.a ../deps/libsndfile-1.0.25/libsndfile-wasm.a -o libcsound.js
> >
> > Notice I added the SINGLE_FILE, MODULARIZE and EXPORT_NAME option. (As an
> > aside I don’t think it’s necessary to have the Csound_Obj exported
> > functions anymore in the above line as someone added the Emscripten Keep
> > Alive macro to the CsoundObj.c source).
> > Also using SINGLE_FILE is not necessary, and seems to be slower to load
> > than without.
> >
> > In my Webpack 4 config:
> >
> > module.exports = {
> >
> >     module: {
> >
> >         rules: [
> >
> >             {
> >
> >                 test: /\.js$/,
> >                 exclude: /node_modules/,
> >                 use: {
> >
> >                     loader: "babel-loader"
> >
> >                 }
> >
> >             },
> >             {
> >
> >                 test: /\.wasm$/,
> >                 type: "webassembly/experimental"
> >
> >             },
> >             {
> >
> >                 test: /\.csd$/,
> >                 use: 'raw-loader'
> >
> >             }
> >
> >         ],
> >
> >     },
> >     node: {
> >
> >         fs:'empty',
> >         ws:'empty'
> >
> >     },
> >     externals: ['ws']
> >
> > }
> >
> > I can then import Csound into a Javascript class like this:
> >
> > import libcsound from './libcsound.js';
> >
> > class MyClass {
> >
> >         constructor() {
> >
> >                 libcsound().then((Module) => { console.log("libcsound
> >
> > loaded."); })
> >
> >         }
> >
> > }
> >
> > > On 24 Mar 2018, at 10:26, Michael Gogins <michael.gogins@GMAIL.COM>
> >
> > wrote:
> > > CORS is cross-origin resource sharing, which is a security risk. It is
> > > however common, e.g. for CDNs, see https://enable-cors.org/.
> > >
> > > Regards,
> > > Mike
> > >
> > > -----------------------------------------------------
> > > Michael Gogins
> > > Irreducible Productions
> > > http://michaelgogins.tumblr.com
> > > Michael dot Gogins at gmail dot com
> > >
> > > On Sat, Mar 24, 2018 at 2:18 PM, Steven Yi <stevenyi@gmail.com> wrote:
> > >> Perhaps best to file an issue, either on the Csound tracker or
> > >> csound.github.io tracker. 6.11.0 should be out soon and we can publish
> > >> it to whatever URL is proposed. We could host on csound.com, but we
> > >> could also look at other CDN sites too.  (I think we might not be able
> > >> to follow CORS rules for cross-site scripting and publishing publicly
> > >> on csound.com with github pages, but I haven't looked at that kind of
> > >> thing in a long while).
> > >>
> > >> The benefit of unpacking/installing as part of your project is that
> > >> you don't have to deal with CORS and can depend upon it working
> > >> always.  I think Ed's done some research into making the inclusion
> > >> automated via Webpack and Hlodver's done some research making a single
> > >> JS all-in-one file that might make things simpler. (Perhaps they could
> > >> comment on their efforts here?)
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Sat, Mar 24, 2018 at 12:52 PM, Tarmo Johannes <trmjhnns@gmail.com>
> >
> > wrote:
> > >>> Hi,
> > >>>
> > >>> On Saturday, March 24, 2018 6:05:58 PM EET you wrote:
> > >>>> https://github.com/gogins/csound-extended/releases/
> >
> > download/v0.1.0-beta2//
> >
> > >>>> csound-wasm-6.11.0-beta2.zip.
> > >>>
> > >>> Yes, this works nicely, thanks!
> > >>>
> > >>>
> > >>>
> > >>> I think that it would be nice to have one place online where the
> > >>> latest
> > >>> Csound-wasm build can be reached, so that users don't have to always
> > >>> download unpack and upload the package when they want to use
> >
> > Csound-wasm in
> >
> > >>> their page.
> > >>>
> > >>>
> > >>>
> > >>> Is it now so that the libcsound.wasm file must be exmplicitly in the
> >
> > same
> >
> > >>> folder as the user's html/javascript file? Is it perhaps possible to
> >
> > load it
> >
> > >>> rempotely? In that case I would suggest that http://csound.com/wasm/
> >
> > would
> >
> > >>> be the place set link to.
> > >>>
> > >>>
> > >>>
> > >>> tarmo
> > >>>
> > >>> Csound mailing list Csound@listserv.heanet.ie
> > >>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> > >>> https://github.com/csound/csound/issues Discussions of bugs and
> >
> > features can
> >
> > >>> be posted here
> > >>
> > >> Csound mailing list
> > >> Csound@listserv.heanet.ie
> > >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > >> Send bugs reports to
> > >>
> > >>        https://github.com/csound/csound/issues
> > >>
> > >> Discussions of bugs and features can be posted here
> > >
> > > Csound mailing list
> > > Csound@listserv.heanet.ie
> > > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > > Send bugs reports to
> > >
> > >        https://github.com/csound/csound/issues
> > >
> > > Discussions of bugs and features can be posted here
> >
> > Csound mailing list
> > Csound@listserv.heanet.ie
> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > Send bugs reports to
> >
> >         https://github.com/csound/csound/issues
> >
> > Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date2018-03-27 08:33
Fromjoachim heintz
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
yes it says it has this line in your csd:
   f  1     0.00     0.00     1.00  "fox.wav" ...

can you double check you really don't have in the csd you call?



On 27/03/18 01:44, Patrick Hinkle wrote:
> One of the first opcodes and associated example files from the Csound
> Manual that I tried to implement and run is the flooper2 example program
> shown below, in the same form as in my text editor, except that I am
> trying to play a little jam session of mine that I recorded called
> "ringmod.wav" and I am trying to use flooper2 and the csound command
> line to play it back in different times and ways/w/different parameters.
> When I run the following csound command in the Terminal:
> csound -Q0 -+rtaudio=coreaudio -odac -iadc flooper21.csd
>
> & the flooper21.csd file that I try to run is in this form:
>
> 
> 
>
> 
> 
>
> sr = 44100
> ksmps = 32
> nchnls = 2
> 0dbfs  = 1
>
> instr 1
> ; looping back and forth,  0.05 crossfade
> kst  line     .2, p3, 2 ;vary loopstartpoint
> ;aout flooper2 .8, 1, 0, kst, 0.05, 1, 0, 2
> aout flooper2 16000, 1, 1, 5, 0.05, 1 ;LOOP STARTS AT 1 SEC,
> ;FOR 4 SEC, 0.05 CROSSFADE.
>      outs     aout, aout
>
> endin
> 
> 
> ; Its table size is deferred,
> ; and format taken from the soundfile header
> f 1 0 0 1 "ringmod.wav" 2 3 2
>
> i 1 0 12
> e
> 
> 
>
> But I get the following output & error:
>
>
> 0dBFS level = 32768.0
>
> --Csound version 6.10 (double samples) Dec 21 2017
>
> [commit: 3bc82359c20c6c35cf0240b9fe8c8fb4ad29ddf4]
>
> libsndfile-1.0.25
>
> WARNING: could not open library
> '/Library/Frameworks/CsoundLib64.framework/Versions/6.0/Resources/Opcodes64/librtjack.dylib'
> (-1)
>
> UnifiedCSD:  flooper21.csd
>
> STARTING FILE
>
> Creating options
>
> Creating orchestra
>
> closing tag
>
> Creating score
>
> rtaudio: coreaaudio-AuHAL module enabled
>
> rtmidi: PortMIDI module enabled
>
> Elapsed time at end of orchestra compile: real: 0.034s, CPU: 0.004s
>
> sorting score ...
>
> ... done
>
> Elapsed time at end of score sort: real: 0.034s, CPU: 0.004s
>
> 0: IAC Driver Bus 1 (portmidi)
>
> 1: IAC Driver IAC Bus 2 (portmidi)
>
> 2: IAC Driver IAC Bus 3 (portmidi)
>
> PortMIDI: selected output device 0: 'IAC Driver Bus 1' (CoreMIDI)
>
> graphics suppressed, ascii substituted
>
> 0dBFS level = 1.0
>
> orch now loaded
>
> audio buffered in 1024 sample-frame blocks
>
> ==========================================================
>
> AuHAL Module: found 2 input device(s):
>
> 1: Built-in Microphone (2 channels)
>
> 2: Movavi Sound Grabber (2 channels)
>
> selected input device: Built-in Microphone
>
> ***** AuHAL module: input device open with 1024 buffer frames
>
> reading 4096-byte blks of shorts from adc (RAW)
>
> AuHAL Module: found 2 output device(s):
>
> 1: Built-in Output (2 channels)
>
> 2: Movavi Sound Grabber (2 channels)
>
> selected output device: Built-in Output
>
> ***** AuHAL module: output device open with 1024 buffer frames
>
> ==========================================================
>
> writing 2048 sample blks of 64-bit floats to dac
>
> SECTION 1:
>
> ftable 1:
>
> deferred alloc for fox.wav
>
> soundin cannot open fox.wav
>
> ftable 1: Failed to open file fox.wav
>
> f  1     0.00     0.00     1.00  "fox.wav" ...
>
> new alloc for instr 1:
>
> Invalid ftable no. 1.000000
>
> INIT ERROR in instr 1: function table not found
>
>
> aoutflooper2.810kst0.05100
>
>   B  0.000 - note deleted.  i1 had 1 init errors
>
> Score finished in csoundPerform().
>
> inactive allocs returned to freespace
>
> end of score.  overall amps:  0.00000  0.00000
>
>   overall samples out of range:        0        0
>
> 1 errors in performance
>
> Elapsed time at end of performance: real: 3.435s, CPU: 0.062s
>
> AuHAL module: device closed
>
> 0 2048 sample blks of 64-bit floats written to dac
>
>
> I don't know where this "fox.wav" file is coming from since I replaced
> it with my jam session file "ringmod.wav", but it seems to be struggling
> to open my GEN01 function table.
> Do you know of any ways that I can fix this program (or maybe command
> line) to play my "ringmod.wav" file? Any help would be greatly appreciated.
> Patrick
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sun, Mar 25, 2018 at 4:27 AM, Victor Lazzarini
> > wrote:
>
>     No, csound.js is meant as port of the PNaCl Csound, not as an
>     extension to CsoundObj. It is effectively a JS frontend in the same
>     way as PNaCl Csound.
>
>     Victor Lazzarini
>     Dean of Arts, Celtic Studies, and Philosophy
>     Maynooth University
>     Ireland
>
>     On 25 Mar 2018, at 12:19, Michael Gogins      > wrote:
>
>>     It's always possible to implement the existing API first and then
>>     add any new functionality that may be desired or required, with
>>     new names.
>>
>>     This is what I did in csound_extended.js. I think this is the
>>     right approach.
>>
>>     This does not appear to be the case with csound.js.
>>
>>     Regards,
>>     Mike
>>
>>     On Sun, Mar 25, 2018, 2:02 AM Tarmo Johannes >     > wrote:
>>
>>         Great!
>>
>>         I think something like that would be very welcome from users
>>         point of view! If
>>         it has no contradictions with security or else, I guess for
>>         Csound use in web
>>         pages that would be really useful.
>>
>>         I saw it has a new API method csound.startRealtime(config*).
>>         It is probably necessary to distinguish from csound.start()
>>         but I find it very
>>         important -  if ever possible -  that all html/javascript
>>         associataed APIs
>>         would use same or similar methods -  so the same code works in
>>         Android, Csound
>>         For Node, Wasm, CsoundQt etc.  What do you think?
>>
>>         tarmo
>>
>>         On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
>>         > I made a single js, still work in progress
>>         > https://github.com/hlolli/csound-wasm
>>         
>>         >
>>         > but this usage example shows it's simplicity
>>         >
>>         > 
>>         > 
>>         >   
>>         >     
>>         >   
>>         >   
>>         >     
Click Start realtime once, gotta love chrome's new >> autoplay >> > ban policy
>> > >> >

Date2018-03-27 08:35
Fromjoachim heintz
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
by the way: i just see it has nothing to do with the subject you replied 
to ...
please use another subject.



On 27/03/18 01:44, Patrick Hinkle wrote:
> One of the first opcodes and associated example files from the Csound
> Manual that I tried to implement and run is the flooper2 example program
> shown below, in the same form as in my text editor, except that I am
> trying to play a little jam session of mine that I recorded called
> "ringmod.wav" and I am trying to use flooper2 and the csound command
> line to play it back in different times and ways/w/different parameters.
> When I run the following csound command in the Terminal:
> csound -Q0 -+rtaudio=coreaudio -odac -iadc flooper21.csd
>
> & the flooper21.csd file that I try to run is in this form:
>
> 
> 
>
> 
> 
>
> sr = 44100
> ksmps = 32
> nchnls = 2
> 0dbfs  = 1
>
> instr 1
> ; looping back and forth,  0.05 crossfade
> kst  line     .2, p3, 2 ;vary loopstartpoint
> ;aout flooper2 .8, 1, 0, kst, 0.05, 1, 0, 2
> aout flooper2 16000, 1, 1, 5, 0.05, 1 ;LOOP STARTS AT 1 SEC,
> ;FOR 4 SEC, 0.05 CROSSFADE.
>      outs     aout, aout
>
> endin
> 
> 
> ; Its table size is deferred,
> ; and format taken from the soundfile header
> f 1 0 0 1 "ringmod.wav" 2 3 2
>
> i 1 0 12
> e
> 
> 
>
> But I get the following output & error:
>
>
> 0dBFS level = 32768.0
>
> --Csound version 6.10 (double samples) Dec 21 2017
>
> [commit: 3bc82359c20c6c35cf0240b9fe8c8fb4ad29ddf4]
>
> libsndfile-1.0.25
>
> WARNING: could not open library
> '/Library/Frameworks/CsoundLib64.framework/Versions/6.0/Resources/Opcodes64/librtjack.dylib'
> (-1)
>
> UnifiedCSD:  flooper21.csd
>
> STARTING FILE
>
> Creating options
>
> Creating orchestra
>
> closing tag
>
> Creating score
>
> rtaudio: coreaaudio-AuHAL module enabled
>
> rtmidi: PortMIDI module enabled
>
> Elapsed time at end of orchestra compile: real: 0.034s, CPU: 0.004s
>
> sorting score ...
>
> ... done
>
> Elapsed time at end of score sort: real: 0.034s, CPU: 0.004s
>
> 0: IAC Driver Bus 1 (portmidi)
>
> 1: IAC Driver IAC Bus 2 (portmidi)
>
> 2: IAC Driver IAC Bus 3 (portmidi)
>
> PortMIDI: selected output device 0: 'IAC Driver Bus 1' (CoreMIDI)
>
> graphics suppressed, ascii substituted
>
> 0dBFS level = 1.0
>
> orch now loaded
>
> audio buffered in 1024 sample-frame blocks
>
> ==========================================================
>
> AuHAL Module: found 2 input device(s):
>
> 1: Built-in Microphone (2 channels)
>
> 2: Movavi Sound Grabber (2 channels)
>
> selected input device: Built-in Microphone
>
> ***** AuHAL module: input device open with 1024 buffer frames
>
> reading 4096-byte blks of shorts from adc (RAW)
>
> AuHAL Module: found 2 output device(s):
>
> 1: Built-in Output (2 channels)
>
> 2: Movavi Sound Grabber (2 channels)
>
> selected output device: Built-in Output
>
> ***** AuHAL module: output device open with 1024 buffer frames
>
> ==========================================================
>
> writing 2048 sample blks of 64-bit floats to dac
>
> SECTION 1:
>
> ftable 1:
>
> deferred alloc for fox.wav
>
> soundin cannot open fox.wav
>
> ftable 1: Failed to open file fox.wav
>
> f  1     0.00     0.00     1.00  "fox.wav" ...
>
> new alloc for instr 1:
>
> Invalid ftable no. 1.000000
>
> INIT ERROR in instr 1: function table not found
>
>
> aoutflooper2.810kst0.05100
>
>   B  0.000 - note deleted.  i1 had 1 init errors
>
> Score finished in csoundPerform().
>
> inactive allocs returned to freespace
>
> end of score.  overall amps:  0.00000  0.00000
>
>   overall samples out of range:        0        0
>
> 1 errors in performance
>
> Elapsed time at end of performance: real: 3.435s, CPU: 0.062s
>
> AuHAL module: device closed
>
> 0 2048 sample blks of 64-bit floats written to dac
>
>
> I don't know where this "fox.wav" file is coming from since I replaced
> it with my jam session file "ringmod.wav", but it seems to be struggling
> to open my GEN01 function table.
> Do you know of any ways that I can fix this program (or maybe command
> line) to play my "ringmod.wav" file? Any help would be greatly appreciated.
> Patrick
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sun, Mar 25, 2018 at 4:27 AM, Victor Lazzarini
> > wrote:
>
>     No, csound.js is meant as port of the PNaCl Csound, not as an
>     extension to CsoundObj. It is effectively a JS frontend in the same
>     way as PNaCl Csound.
>
>     Victor Lazzarini
>     Dean of Arts, Celtic Studies, and Philosophy
>     Maynooth University
>     Ireland
>
>     On 25 Mar 2018, at 12:19, Michael Gogins      > wrote:
>
>>     It's always possible to implement the existing API first and then
>>     add any new functionality that may be desired or required, with
>>     new names.
>>
>>     This is what I did in csound_extended.js. I think this is the
>>     right approach.
>>
>>     This does not appear to be the case with csound.js.
>>
>>     Regards,
>>     Mike
>>
>>     On Sun, Mar 25, 2018, 2:02 AM Tarmo Johannes >     > wrote:
>>
>>         Great!
>>
>>         I think something like that would be very welcome from users
>>         point of view! If
>>         it has no contradictions with security or else, I guess for
>>         Csound use in web
>>         pages that would be really useful.
>>
>>         I saw it has a new API method csound.startRealtime(config*).
>>         It is probably necessary to distinguish from csound.start()
>>         but I find it very
>>         important -  if ever possible -  that all html/javascript
>>         associataed APIs
>>         would use same or similar methods -  so the same code works in
>>         Android, Csound
>>         For Node, Wasm, CsoundQt etc.  What do you think?
>>
>>         tarmo
>>
>>         On Sunday, March 25, 2018 12:22:33 AM EEST you wrote:
>>         > I made a single js, still work in progress
>>         > https://github.com/hlolli/csound-wasm
>>         
>>         >
>>         > but this usage example shows it's simplicity
>>         >
>>         > 
>>         > 
>>         >   
>>         >     
>>         >   
>>         >   
>>         >     
Click Start realtime once, gotta love chrome's new >> autoplay >> > ban policy
>> > >> >

Date2020-01-10 19:24
FromJulio Benavides <000001af805ab429-dmarc-request@LISTSERV.HEANET.IE>
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
Hello hlolli.
Is is possible to use p4 and p5 (--midi-key-cps=4 --midi-velocity-amp=5 with
csound.startRealtime() with  csound.compileOrc()?
 There is a csound.setOption() function but I don´t find any documentation
about how to use it.
Regards
Julio.



-----
Then Barry said, "Let's make some noise" and there was Csound.
--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Date2020-01-10 19:59
FromVictor Lazzarini
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
https://csound.com/docs/api/group___a_t_t_r_i_b_u_t_e_s.html#ga332ed5da3d399f0ae039906c380764e1

Prof. Victor Lazzarini
Maynooth University
Ireland

On 10 Jan 2020, at 19:31, Julio Benavides <000001af805ab429-dmarc-request@listserv.heanet.ie> wrote:

Hello hlolli.
Is is possible to use p4 and p5 (--midi-key-cps=4 --midi-velocity-amp=5 with
csound.startRealtime() with  csound.compileOrc()?
There is a csound.setOption() function but I don´t find any documentation
about how to use it.
Regards
Julio.



-----
Then Barry said, "Let's make some noise" and there was Csound.
--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Date2020-01-13 10:27
FromJulio Benavides <000001af805ab429-dmarc-request@LISTSERV.HEANET.IE>
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
Thanks Dr. Victor for the link.
Actually, I could already find the solution.
I'm new to web technology and I'm implementing my first csound demo
synthesizer with the Sigurðsson's csound-wasm.
On the other hand, is there an easy way to solve the warning "AudioContext
was not allowed to start..."
my code works on Brave but not on Chrome 79, Opera 66
Regards.
J.




-----
Then Barry said, "Let's make some noise" and there was Csound.
--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Date2020-01-13 18:12
FromHlöðver Sigurðsson
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
Hi Julio, I replied to you on the github repository.

On Mon, 13 Jan 2020 at 11:55, Julio Benavides <000001af805ab429-dmarc-request@listserv.heanet.ie> wrote:
Thanks Dr. Victor for the link.
Actually, I could already find the solution.
I'm new to web technology and I'm implementing my first csound demo
synthesizer with the Sigurðsson's csound-wasm.
On the other hand, is there an easy way to solve the warning "AudioContext
was not allowed to start..."
my code works on Brave but not on Chrome 79, Opera 66
Regards.
J.




-----
Then Barry said, "Let's make some noise" and there was Csound.
--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date2020-01-13 19:09
FromJulio César
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
Thanks!!

On Monday, January 13, 2020, 01:12:27 PM GMT-5, Hlöðver Sigurðsson <hlolli@gmail.com> wrote:


Hi Julio, I replied to you on the github repository.

On Mon, 13 Jan 2020 at 11:55, Julio Benavides <000001af805ab429-dmarc-request@listserv.heanet.ie> wrote:
Thanks Dr. Victor for the link.
Actually, I could already find the solution.
I'm new to web technology and I'm implementing my first csound demo
synthesizer with the Sigurðsson's csound-wasm.
On the other hand, is there an easy way to solve the warning "AudioContext
was not allowed to start..."
my code works on Brave but not on Chrome 79, Opera 66
Regards.
J.




-----
Then Barry said, "Let's make some noise" and there was Csound.
--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date2020-01-17 04:29
FromJulio Benavides <000001af805ab429-dmarc-request@LISTSERV.HEANET.IE>
SubjectRe: [Csnd] Csound-wasm version at https://csound.github.io/wasm/
Hello Csounders
For me it is a little difficult to get used to web technology, I am doing my
best purpose to understand it ...
I'm exploring the examples (Csound6.13.0-Web) and messing with them ...
Is there any possibility to play the following code in real time with MIDI
messages from a controller?
This code is based on randgen.html by V Lazzarini ...
Regards!

***********************************
function main(){


CsoundObj.importScripts("./app/").then( () => {
    document.getElementById("Engine").addEventListener('click',CtxStatus);
    CSOUND_AUDIO_CONTEXT.suspend();
    csound = new CsoundObj();
    csound.compileCSD(csd);
    csound.start(); 
    window.addEventListener('unload', function(e){
        if (csound != null) csound.destroy();
    }, false);
   
});

}; //end of main



//Gestión de los estados del audioContext para Csound///
let playing = false;
function CtxStatus(){
    if (playing == false){
        CSOUND_AUDIO_CONTEXT.resume(); 
        document.getElementById("Engine").value="pause"
        playing = true;
    } else {
        CSOUND_AUDIO_CONTEXT.suspend();
        document.getElementById("Engine").value="start"
        playing = false;
    }
    
}


const csd =
`


-n -d -+rtmidi=NULL -M0 -m0d --midi-key-cps=4 --midi-velocity-amp=5


        massign 0, 1 ;all MIDI channell for instrument 1
; Initialize the global variables. 
ksmps = 32
nchnls = 2
0dbfs = 1

;instrument will be triggered by keyboard widget
        instr 1

kAEG    madsr .01, .001, .8, .01
a1      oscili  p5 * kAEG   ,   p4
        outs    a1          ,   a1
        endin




f0 z
;i   1   0   .25  880 .2
;i   1   +   .25  440 .2
;i   1   +   .25  660 .2
i    1   0  3600 ; for RT.



`



-----
Then Barry said, "Let's make some noise" and there was Csound.
--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here