Quantcast

Browser-based SuperCollider?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Browser-based SuperCollider?

grahamsw
Given that SC is portable, and that a modern browsers' JS engine is easily as powerful as a 90's PC, is there a reason that there isn't a JavaScript port of Supercollider?

I've seen entire gaming engines run the Quake II in the brower, and I can't believe the computational demands of SC are higher than that. I've seen SCScript, but that hasn't been worked on for 3 years.

Is there simply no demand for this? Is seems to me that it would be a hell of a way of making SuperCollider skills more valuable, and of getting a much larger developer community involved.

What am I missing?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

marc
Maybe it could be done using:
Marc

On May 15, 2017, at 10:53 AM, [hidden email] wrote:

Given that SC is portable, and that a modern browsers' JS engine is easily as
powerful as a 90's PC, is there a reason that there isn't a JavaScript port
of Supercollider?

I've seen entire gaming engines run the Quake II in the brower, and I can't
believe the computational demands of SC are higher than that. I've seen
SCScript <https://github.com/mohayonao/SCScript>  , but that hasn't been
worked on for 3 years.

Is there simply no demand for this? Is seems to me that it would be a hell
of a way of making SuperCollider skills more valuable, and of getting a much
larger developer community involved.

What am I missing?





--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Browser-based-SuperCollider-tp7632388.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

patrick

There's supercollider.js https://github.com/crucialfelix/supercolliderjs


Patrick




From: [hidden email] <[hidden email]> on behalf of [hidden email] <[hidden email]>
Sent: May 15, 2017 11:39 AM
To: [hidden email]
Subject: Re: [sc-users] Browser-based SuperCollider?
 
Maybe it could be done using:
Marc

On May 15, 2017, at 10:53 AM, [hidden email] wrote:

Given that SC is portable, and that a modern browsers' JS engine is easily as
powerful as a 90's PC, is there a reason that there isn't a JavaScript port
of Supercollider?

I've seen entire gaming engines run the Quake II in the brower, and I can't
believe the computational demands of SC are higher than that. I've seen
SCScript <https://github.com/mohayonao/SCScript>  , but that hasn't been
worked on for 3 years.

Is there simply no demand for this? Is seems to me that it would be a hell
of a way of making SuperCollider skills more valuable, and of getting a much
larger developer community involved.

What am I missing?





--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Browser-based-SuperCollider-tp7632388.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

grahamsw
Does this implement the scsynth in Javascript? or is it a means of communicating with a running scsynth via OSC?

The ideal would be to have the synth running in the browser's JS Engine, distributing the CPU intensive work all the way to the client.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

patrick

I haven't used it myself, but I think it's a client written in JS that communicates with a running SC server. The author is a SC developer who reads this mailing list. Hopefully, he will see your messages.


Patrick




From: [hidden email] <[hidden email]> on behalf of [hidden email] <[hidden email]>
Sent: May 15, 2017 1:10 PM
To: [hidden email]
Subject: [sc-users] Re: Browser-based SuperCollider?
 
Does this implement the scsynth in Javascript? or is it a means of
communicating with a running scsynth via OSC?

The ideal would be to have the synth running in the browser's JS Engine,
distributing the CPU intensive work all the way to the client.



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Browser-based-SuperCollider-tp7632388p7632392.html

Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx

archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

Aegean Heart
In reply to this post by grahamsw
I’d be very interested to see the results of that.



_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

daniel palkowski
Phil Burk made it work with JSyn, so why not SC?

On Mon, May 15, 2017 at 2:20 PM, <[hidden email]> wrote:
I’d be very interested to see the results of that.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

marc
JSyn was made with the available technology in 1998. It “made sense” (back then) to use Java for elaborate web software. Now there’s more options, and there will be more. A port to Javascript could be a lot of work, and I suspect that it would not be as fast as the native C++ version, and it’s rarely a good idea to maintain a version in some other language. A Webassembly port would be able to use the C++ source with little adaptation, but it’s not yet a stable tool. The other “native” options are NaCI and PNaCI from Google, but they are probably being phased out in favour of WebAssembly.
Marc


On May 15, 2017, at 3:20 PM, [hidden email] wrote:

Phil Burk made it work with JSyn, so why not SC?

On Mon, May 15, 2017 at 2:20 PM, <[hidden email]> wrote:
I’d be very interested to see the results of that.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

simdax

I've used supercollider js.
you need sc to be installed client side. I tried to stream results from server but no easy going solutions are available.

I think the most powerful js audio lib this days is tone js. It uses Web audio API.

It has basic Synthese capacity and simple sequence pattern Lib. It lacks the great
Pbind thing and great nDef God.

The best solution seems to me to fork tone js to give it better live coding syntax and maybe magical synthDef things.

It s certainly not impossible to emulate it but we need motivation!


Le 15 mai 2017 22:18, "marc [via New SuperCollider Mailing Lists Forums (Use These!!!)]" <[hidden email]> a écrit :
JSyn was made with the available technology in 1998. It “made sense” (back then) to use Java for elaborate web software. Now there’s more options, and there will be more. A port to Javascript could be a lot of work, and I suspect that it would not be as fast as the native C++ version, and it’s rarely a good idea to maintain a version in some other language. A Webassembly port would be able to use the C++ source with little adaptation, but it’s not yet a stable tool. The other “native” options are NaCI and PNaCI from Google, but they are probably being phased out in favour of WebAssembly.
Marc


On May 15, 2017, at 3:20 PM, [hidden email] wrote:

Phil Burk made it work with JSyn, so why not SC?

On Mon, May 15, 2017 at 2:20 PM, <[hidden email]> wrote:
I’d be very interested to see the results of that.





To start a new topic under SuperCollider Users New (Use this!!!!), email [hidden email]
To unsubscribe from SuperCollider Users New (Use this!!!!), click here.
NAML
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

grahamsw
Java was definitely the right solution back then.

It would be a ton of work to port - maybe when WebAssembly will make that easier, and more rewarding, but it's still going to take a combination of skills, motivation, and time/money to make this happen that doesn't seem to have been there. Surprising to me that the game companies haven't got into this, but I guess they think they can get by with sampling and Web Audio.

Feels like a lack of vision though, or maybe there just aren't enough SC developers to justify it.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

Charlie Roberts
The biggest holdup isn't efficiency, it's that JavaScript audio callbacks (via the ScriptProcessor node) run in the main thread (!!!) and incur an extra buffer of latency. Audio Worklets will help solve this problem when they finally see the light of day. - Charlie

On Tue, May 16, 2017 at 5:03 PM, <[hidden email]> wrote:
Java was definitely the right solution back then.

It would be a ton of work to port - maybe when WebAssembly will make that
easier, and more rewarding, but it's still going to take a combination of
skills, motivation, and time/money to make this happen that doesn't seem to
have been there. Surprising to me that the game companies haven't got into
this, but I guess they think they can get by with sampling and Web Audio.

Feels like a lack of vision though, or maybe there just aren't enough SC
developers to justify it.





--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Browser-based-SuperCollider-tp7632388p7632415.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

crucialfelix

supercollider.js is an alternative to sclang. It controls scsynth in the exact same way as sclang does.
JavaScript aka ECMA script is now a very nice language.
Primarily it is for writing music applications that run on node.js on your computer.


examples:

When people hear "javascript" they assume that it must therefore run in the browser.  
It is at this point a general purpose programming language with a lot of nice language features.

Many things that were exciting about supercollider are now in javascript. I think it's a much nicer language than sclang now.

I have written Electron apps with it and some browser based apps that run on my local machine.
A few other people have built apps with it. React and Vue.

But still the bridging costs are high and trying to make this work adds to the complexity.
It's advanced, not suitable for beginners. It isn't easy yet.

webassembly may be able to compile scsynth to run inside a browser at some point. There will be limitations though.
Timing and garbage collection issues.
Communicating back and forth with UI is harder. Realtime MIDI and OSC are going to require work. 

WASM will enable some specific high performance computing tasks like graphics and ML on the edge (in client machines, not always in the cloud) But it isn't a general purpose "C++ in the browser".  Shit, we can barely get audio to run on linux, how are we going to get it to run in the browser ;)

What is the real purpose of running in a browser ? It has a DOM which you can use to make dynamic interfaces.
Actually the DOM is the biggest performance blocker and source of frustration. Plenty of people trying to get around the DOM.

WebGL is nice but then you can have real OpenGL if you program in OpenFrameworks or similar.

I do love javascript. It's a mess though. A lot of us are moving to pure functional programming. 
Facebook has an OCaml to javascript compiler that they use to write really solid js driven apps.

- felix (supercollider.js) 


On Tue, May 16, 2017 at 5:47 PM <[hidden email]> wrote:
The biggest holdup isn't efficiency, it's that JavaScript audio callbacks (via the ScriptProcessor node) run in the main thread (!!!) and incur an extra buffer of latency. Audio Worklets will help solve this problem when they finally see the light of day. - Charlie

On Tue, May 16, 2017 at 5:03 PM, <[hidden email]> wrote:
Java was definitely the right solution back then.

It would be a ton of work to port - maybe when WebAssembly will make that
easier, and more rewarding, but it's still going to take a combination of
skills, motivation, and time/money to make this happen that doesn't seem to
have been there. Surprising to me that the game companies haven't got into
this, but I guess they think they can get by with sampling and Web Audio.

Feels like a lack of vision though, or maybe there just aren't enough SC
developers to justify it.





--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Browser-based-SuperCollider-tp7632388p7632415.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

simdax
```
webassembly may be able to compile scsynth to run inside a browser at some point. There will be limitations though.
Timing and garbage collection issues.
Communicating back and forth with UI is harder. Realtime MIDI and OSC are going to require work. 

WASM will enable some specific high performance computing tasks like graphics and ML on the edge (in client machines, not always in the cloud) But it isn't a general purpose "C++ in the browser".  Shit, we can barely get audio to run on linux, how are we going to get it to run in the browser ;)

What is the real purpose of running in a browser ? It has a DOM which you can use to make dynamic interfaces.
Actually the DOM is the biggest performance blocker and source of frustration. Plenty of people trying to get around the DOM.

```

Do you know WASM ? What if we put SuperCollider code on it ??



2017-05-16 23:32 GMT+02:00 <[hidden email]>:

supercollider.js is an alternative to sclang. It controls scsynth in the exact same way as sclang does.
JavaScript aka ECMA script is now a very nice language.
Primarily it is for writing music applications that run on node.js on your computer.


examples:

When people hear "javascript" they assume that it must therefore run in the browser.  
It is at this point a general purpose programming language with a lot of nice language features.

Many things that were exciting about supercollider are now in javascript. I think it's a much nicer language than sclang now.

I have written Electron apps with it and some browser based apps that run on my local machine.
A few other people have built apps with it. React and Vue.

But still the bridging costs are high and trying to make this work adds to the complexity.
It's advanced, not suitable for beginners. It isn't easy yet.

webassembly may be able to compile scsynth to run inside a browser at some point. There will be limitations though.
Timing and garbage collection issues.
Communicating back and forth with UI is harder. Realtime MIDI and OSC are going to require work. 

WASM will enable some specific high performance computing tasks like graphics and ML on the edge (in client machines, not always in the cloud) But it isn't a general purpose "C++ in the browser".  Shit, we can barely get audio to run on linux, how are we going to get it to run in the browser ;)

What is the real purpose of running in a browser ? It has a DOM which you can use to make dynamic interfaces.
Actually the DOM is the biggest performance blocker and source of frustration. Plenty of people trying to get around the DOM.

WebGL is nice but then you can have real OpenGL if you program in OpenFrameworks or similar.

I do love javascript. It's a mess though. A lot of us are moving to pure functional programming. 
Facebook has an OCaml to javascript compiler that they use to write really solid js driven apps.

- felix (supercollider.js) 


On Tue, May 16, 2017 at 5:47 PM <[hidden email]> wrote:
The biggest holdup isn't efficiency, it's that JavaScript audio callbacks (via the ScriptProcessor node) run in the main thread (!!!) and incur an extra buffer of latency. Audio Worklets will help solve this problem when they finally see the light of day. - Charlie

On Tue, May 16, 2017 at 5:03 PM, <[hidden email]> wrote:
Java was definitely the right solution back then.

It would be a ton of work to port - maybe when WebAssembly will make that
easier, and more rewarding, but it's still going to take a combination of
skills, motivation, and time/money to make this happen that doesn't seem to
have been there. Surprising to me that the game companies haven't got into
this, but I guess they think they can get by with sampling and Web Audio.

Feels like a lack of vision though, or maybe there just aren't enough SC
developers to justify it.





--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Browser-based-SuperCollider-tp7632388p7632415.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

crucialfelix
You could compile scsynth to wasm, but how are you going to get sound data in and out ?
Filesystem access ? socket libraries ?

Every single interface and library that connects with the outside world has to be cut off. 

When embedded in the web, WebAssembly will enforce the same-origin and permissions security policies of the browser.

WebAssembly modules will be able to call into and out of the JavaScript context and access browser functionality through the same Web APIs accessible from JavaScript.

Are you going to copy a buffer into a javascript array 172 times a second ?  that isn't really going to be very efficient.
It is more likely that simpler things like c++ filters can be compiled to wasm js. But they are going to suck.

Running i/o intensive applications really isn't what webassembly is all about. 

Let me ask this: why would you want to run scsynth inside a browser ?


On Wed, May 17, 2017 at 12:52 PM <[hidden email]> wrote:
```
webassembly may be able to compile scsynth to run inside a browser at some point. There will be limitations though.
Timing and garbage collection issues.
Communicating back and forth with UI is harder. Realtime MIDI and OSC are going to require work. 

WASM will enable some specific high performance computing tasks like graphics and ML on the edge (in client machines, not always in the cloud) But it isn't a general purpose "C++ in the browser".  Shit, we can barely get audio to run on linux, how are we going to get it to run in the browser ;)

What is the real purpose of running in a browser ? It has a DOM which you can use to make dynamic interfaces.
Actually the DOM is the biggest performance blocker and source of frustration. Plenty of people trying to get around the DOM.

```

Do you know WASM ? What if we put SuperCollider code on it ??



2017-05-16 23:32 GMT+02:00 <[hidden email]>:

supercollider.js is an alternative to sclang. It controls scsynth in the exact same way as sclang does.
JavaScript aka ECMA script is now a very nice language.
Primarily it is for writing music applications that run on node.js on your computer.


examples:

When people hear "javascript" they assume that it must therefore run in the browser.  
It is at this point a general purpose programming language with a lot of nice language features.

Many things that were exciting about supercollider are now in javascript. I think it's a much nicer language than sclang now.

I have written Electron apps with it and some browser based apps that run on my local machine.
A few other people have built apps with it. React and Vue.

But still the bridging costs are high and trying to make this work adds to the complexity.
It's advanced, not suitable for beginners. It isn't easy yet.

webassembly may be able to compile scsynth to run inside a browser at some point. There will be limitations though.
Timing and garbage collection issues.
Communicating back and forth with UI is harder. Realtime MIDI and OSC are going to require work. 

WASM will enable some specific high performance computing tasks like graphics and ML on the edge (in client machines, not always in the cloud) But it isn't a general purpose "C++ in the browser".  Shit, we can barely get audio to run on linux, how are we going to get it to run in the browser ;)

What is the real purpose of running in a browser ? It has a DOM which you can use to make dynamic interfaces.
Actually the DOM is the biggest performance blocker and source of frustration. Plenty of people trying to get around the DOM.

WebGL is nice but then you can have real OpenGL if you program in OpenFrameworks or similar.

I do love javascript. It's a mess though. A lot of us are moving to pure functional programming. 
Facebook has an OCaml to javascript compiler that they use to write really solid js driven apps.

- felix (supercollider.js) 


On Tue, May 16, 2017 at 5:47 PM <[hidden email]> wrote:
The biggest holdup isn't efficiency, it's that JavaScript audio callbacks (via the ScriptProcessor node) run in the main thread (!!!) and incur an extra buffer of latency. Audio Worklets will help solve this problem when they finally see the light of day. - Charlie

On Tue, May 16, 2017 at 5:03 PM, <[hidden email]> wrote:
Java was definitely the right solution back then.

It would be a ton of work to port - maybe when WebAssembly will make that
easier, and more rewarding, but it's still going to take a combination of
skills, motivation, and time/money to make this happen that doesn't seem to
have been there. Surprising to me that the game companies haven't got into
this, but I guess they think they can get by with sampling and Web Audio.

Feels like a lack of vision though, or maybe there just aren't enough SC
developers to justify it.





--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Browser-based-SuperCollider-tp7632388p7632415.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

marc
WebAssembly can work with the WebAudio API,
in order to get sound data in and out. See:
https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
--
Marc

Le Wed, 17 May 2017 12:20:20 +0000
[hidden email] a écrit:

> You could compile scsynth to wasm, but how are you going to get sound
> data in and out ?
> Filesystem access ? socket libraries ?
>
> Every single interface and library that connects with the outside
> world has to be cut off.
>
> When embedded in the web <http://webassembly.org/docs/web/>,
> WebAssembly will enforce the same-origin and permissions security
> policies of the browser.
>
> WebAssembly modules will be able to call into and out of the
> JavaScript context and access browser functionality through the same
> Web APIs accessible from JavaScript.
>
> Are you going to copy a buffer into a javascript array 172 times a
> second ? that isn't really going to be very efficient.
> It is more likely that simpler things like c++ filters can be
> compiled to wasm js. But they are going to suck.
>
> Running i/o intensive applications really isn't what webassembly is
> all about.
>
> Let me ask this: why would you want to run scsynth inside a browser ?
>
>
> On Wed, May 17, 2017 at 12:52 PM <[hidden email]> wrote:
>
> > ```
> > webassembly may be able to compile scsynth to run inside a browser
> > at some point. There will be limitations though.
> > Timing and garbage collection issues.
> > Communicating back and forth with UI is harder. Realtime MIDI and
> > OSC are going to require work.
> >
> > WASM will enable some specific high performance computing tasks like
> > graphics and ML on the edge (in client machines, not always in the
> > cloud) But it isn't a general purpose "C++ in the browser".  Shit,
> > we can barely get audio to run on linux, how are we going to get it
> > to run in the browser ;)
> >
> > What is the real purpose of running in a browser ? It has a DOM
> > which you can use to make dynamic interfaces.
> > Actually the DOM is the biggest performance blocker and source of
> > frustration. Plenty of people trying to get around the DOM.
> >
> > ```
> >
> > Do you know WASM ? What if we put SuperCollider code on it ??
> >
> >
> >
> > 2017-05-16 23:32 GMT+02:00 <[hidden email]>:
> >
> >>
> >> supercollider.js is an alternative to sclang. It controls scsynth
> >> in the exact same way as sclang does.
> >> JavaScript aka ECMA script is now a very nice language.
> >> Primarily it is for writing music applications that run on node.js
> >> on your computer.
> >>
> >> https://crucialfelix.github.io/supercolliderjs/
> >>
> >> examples:
> >> https://github.com/crucialfelix/supercolliderjs-examples
> >>
> >> When people hear "javascript" they assume that it must therefore
> >> run in the browser.
> >> It is at this point a general purpose programming language with a
> >> lot of nice language features.
> >>
> >> Many things that were exciting about supercollider are now in
> >> javascript. I think it's a much nicer language than sclang now.
> >>
> >> I have written Electron apps with it and some browser based apps
> >> that run on my local machine.
> >> A few other people have built apps with it. React and Vue.
> >>
> >> But still the bridging costs are high and trying to make this work
> >> adds to the complexity.
> >> It's advanced, not suitable for beginners. It isn't easy yet.
> >>
> >> webassembly may be able to compile scsynth to run inside a browser
> >> at some point. There will be limitations though.
> >> Timing and garbage collection issues.
> >> Communicating back and forth with UI is harder. Realtime MIDI and
> >> OSC are going to require work.
> >>
> >> WASM will enable some specific high performance computing tasks
> >> like graphics and ML on the edge (in client machines, not always
> >> in the cloud) But it isn't a general purpose "C++ in the
> >> browser".  Shit, we can barely get audio to run on linux, how are
> >> we going to get it to run in the browser ;)
> >>
> >> What is the real purpose of running in a browser ? It has a DOM
> >> which you can use to make dynamic interfaces.
> >> Actually the DOM is the biggest performance blocker and source of
> >> frustration. Plenty of people trying to get around the DOM.
> >>
> >> WebGL is nice but then you can have real OpenGL if you program in
> >> OpenFrameworks or similar.
> >>
> >> I do love javascript. It's a mess though. A lot of us are moving
> >> to pure functional programming.
> >> Facebook has an OCaml to javascript compiler that they use to write
> >> really solid js driven apps.
> >>
> >> - felix (supercollider.js)
> >>
> >>
> >> On Tue, May 16, 2017 at 5:47 PM <[hidden email]> wrote:
> >>
> >>> The biggest holdup isn't efficiency, it's that JavaScript audio
> >>> callbacks (via the ScriptProcessor node) run in the main thread
> >>> (!!!) and incur an extra buffer of latency. Audio Worklets will
> >>> help solve this problem when they finally see the light of day. -
> >>> Charlie
> >>>
> >>> On Tue, May 16, 2017 at 5:03 PM, <[hidden email]> wrote:
> >>>
> >>>> Java was definitely the right solution back then.
> >>>>
> >>>> It would be a ton of work to port - maybe when WebAssembly will
> >>>> make that
> >>>> easier, and more rewarding, but it's still going to take a
> >>>> combination of
> >>>> skills, motivation, and time/money to make this happen that
> >>>> doesn't seem to
> >>>> have been there. Surprising to me that the game companies
> >>>> haven't got into
> >>>> this, but I guess they think they can get by with sampling and
> >>>> Web Audio.
> >>>>
> >>>> Feels like a lack of vision though, or maybe there just aren't
> >>>> enough SC developers to justify it.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>> http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Browser-based-SuperCollider-tp7632388p7632415.html
> >>>> Sent from the SuperCollider Users New (Use this!!!!) mailing list
> >>>> archive at Nabble.com.
> >>>>
> >>>> _______________________________________________
> >>>> sc-users mailing list
> >>>>
> >>>> info (subscription, etc.):
> >>>> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> >>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> >>>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
> >>>>
> >>>
> >>>
> >


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

amindfv
In reply to this post by crucialfelix


El 16 may 2017, a las 16:32, [hidden email] escribió:


supercollider.js is an alternative to sclang. It controls scsynth in the exact same way as sclang does.
JavaScript aka ECMA script is now a very nice language.
Primarily it is for writing music applications that run on node.js on your computer.


examples:

When people hear "javascript" they assume that it must therefore run in the browser.  
It is at this point a general purpose programming language with a lot of nice language features.

Many things that were exciting about supercollider are now in javascript. I think it's a much nicer language than sclang now.

I have written Electron apps with it and some browser based apps that run on my local machine.
A few other people have built apps with it. React and Vue.

But still the bridging costs are high and trying to make this work adds to the complexity.
It's advanced, not suitable for beginners. It isn't easy yet.

webassembly may be able to compile scsynth to run inside a browser at some point. There will be limitations though.
Timing and garbage collection issues.
Communicating back and forth with UI is harder. Realtime MIDI and OSC are going to require work. 

WASM will enable some specific high performance computing tasks like graphics and ML on the edge (in client machines, not always in the cloud) But it isn't a general purpose "C++ in the browser".  Shit, we can barely get audio to run on linux, how are we going to get it to run in the browser ;)

What is the real purpose of running in a browser ? It has a DOM which you can use to make dynamic interfaces.
Actually the DOM is the biggest performance blocker and source of frustration. Plenty of people trying to get around the DOM.

WebGL is nice but then you can have real OpenGL if you program in OpenFrameworks or similar.

I do love javascript. It's a mess though. A lot of us are moving to pure functional programming. 
Facebook has an OCaml to javascript compiler that they use to write really solid js driven apps.


...and if you do want to write purely functional supercollider, there's always my Vivid library :D



- felix (supercollider.js) 


On Tue, May 16, 2017 at 5:47 PM <[hidden email]> wrote:
The biggest holdup isn't efficiency, it's that JavaScript audio callbacks (via the ScriptProcessor node) run in the main thread (!!!) and incur an extra buffer of latency. Audio Worklets will help solve this problem when they finally see the light of day. - Charlie

On Tue, May 16, 2017 at 5:03 PM, <[hidden email]> wrote:
Java was definitely the right solution back then.

It would be a ton of work to port - maybe when WebAssembly will make that
easier, and more rewarding, but it's still going to take a combination of
skills, motivation, and time/money to make this happen that doesn't seem to
have been there. Surprising to me that the game companies haven't got into
this, but I guess they think they can get by with sampling and Web Audio.

Feels like a lack of vision though, or maybe there just aren't enough SC
developers to justify it.





--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Browser-based-SuperCollider-tp7632388p7632415.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

crucialfelix
In reply to this post by marc

Then scsynth would be rendering into a buffer and you would then have to continually copy that into something like an AudioBufferSourceNode to get it to play out.  There is a huge amount of overhead and complexity. That means worse performance.

Audio software is generally very efficient and avoids every bit of extra work or copying. You would have to rework scsynth to the point of it being a different beast altogether.

Why not just use webaudio directly ?

Rather than try to get all of scsynth running, it is smarter I think to just port filters and UGens and make them process audio with:


soon to be replaced by: 




On Wed, May 17, 2017 at 2:52 PM <[hidden email]> wrote:
WebAssembly can work with the WebAudio API,
in order to get sound data in and out. See:
https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
--
Marc

Le Wed, 17 May 2017 12:20:20 +0000
[hidden email] a écrit:

> You could compile scsynth to wasm, but how are you going to get sound
> data in and out ?
> Filesystem access ? socket libraries ?
>
> Every single interface and library that connects with the outside
> world has to be cut off.
>
> When embedded in the web <http://webassembly.org/docs/web/>,
> WebAssembly will enforce the same-origin and permissions security
> policies of the browser.
>
> WebAssembly modules will be able to call into and out of the
> JavaScript context and access browser functionality through the same
> Web APIs accessible from JavaScript.
>
> Are you going to copy a buffer into a javascript array 172 times a
> second ? that isn't really going to be very efficient.
> It is more likely that simpler things like c++ filters can be
> compiled to wasm js. But they are going to suck.
>
> Running i/o intensive applications really isn't what webassembly is
> all about.
>
> Let me ask this: why would you want to run scsynth inside a browser ?
>
>
> On Wed, May 17, 2017 at 12:52 PM <[hidden email]> wrote:
>
> > ```
> > webassembly may be able to compile scsynth to run inside a browser
> > at some point. There will be limitations though.
> > Timing and garbage collection issues.
> > Communicating back and forth with UI is harder. Realtime MIDI and
> > OSC are going to require work.
> >
> > WASM will enable some specific high performance computing tasks like
> > graphics and ML on the edge (in client machines, not always in the
> > cloud) But it isn't a general purpose "C++ in the browser".  Shit,
> > we can barely get audio to run on linux, how are we going to get it
> > to run in the browser ;)
> >
> > What is the real purpose of running in a browser ? It has a DOM
> > which you can use to make dynamic interfaces.
> > Actually the DOM is the biggest performance blocker and source of
> > frustration. Plenty of people trying to get around the DOM.
> >
> > ```
> >
> > Do you know WASM ? What if we put SuperCollider code on it ??
> >
> >
> >
> > 2017-05-16 23:32 GMT+02:00 <[hidden email]>:
> >
> >>
> >> supercollider.js is an alternative to sclang. It controls scsynth
> >> in the exact same way as sclang does.
> >> JavaScript aka ECMA script is now a very nice language.
> >> Primarily it is for writing music applications that run on node.js
> >> on your computer.
> >>
> >> https://crucialfelix.github.io/supercolliderjs/
> >>
> >> examples:
> >> https://github.com/crucialfelix/supercolliderjs-examples
> >>
> >> When people hear "javascript" they assume that it must therefore
> >> run in the browser.
> >> It is at this point a general purpose programming language with a
> >> lot of nice language features.
> >>
> >> Many things that were exciting about supercollider are now in
> >> javascript. I think it's a much nicer language than sclang now.
> >>
> >> I have written Electron apps with it and some browser based apps
> >> that run on my local machine.
> >> A few other people have built apps with it. React and Vue.
> >>
> >> But still the bridging costs are high and trying to make this work
> >> adds to the complexity.
> >> It's advanced, not suitable for beginners. It isn't easy yet.
> >>
> >> webassembly may be able to compile scsynth to run inside a browser
> >> at some point. There will be limitations though.
> >> Timing and garbage collection issues.
> >> Communicating back and forth with UI is harder. Realtime MIDI and
> >> OSC are going to require work.
> >>
> >> WASM will enable some specific high performance computing tasks
> >> like graphics and ML on the edge (in client machines, not always
> >> in the cloud) But it isn't a general purpose "C++ in the
> >> browser".  Shit, we can barely get audio to run on linux, how are
> >> we going to get it to run in the browser ;)
> >>
> >> What is the real purpose of running in a browser ? It has a DOM
> >> which you can use to make dynamic interfaces.
> >> Actually the DOM is the biggest performance blocker and source of
> >> frustration. Plenty of people trying to get around the DOM.
> >>
> >> WebGL is nice but then you can have real OpenGL if you program in
> >> OpenFrameworks or similar.
> >>
> >> I do love javascript. It's a mess though. A lot of us are moving
> >> to pure functional programming.
> >> Facebook has an OCaml to javascript compiler that they use to write
> >> really solid js driven apps.
> >>
> >> - felix (supercollider.js)
> >>
> >>
> >> On Tue, May 16, 2017 at 5:47 PM <[hidden email]> wrote:
> >>
> >>> The biggest holdup isn't efficiency, it's that JavaScript audio
> >>> callbacks (via the ScriptProcessor node) run in the main thread
> >>> (!!!) and incur an extra buffer of latency. Audio Worklets will
> >>> help solve this problem when they finally see the light of day. -
> >>> Charlie
> >>>
> >>> On Tue, May 16, 2017 at 5:03 PM, <[hidden email]> wrote:
> >>>
> >>>> Java was definitely the right solution back then.
> >>>>
> >>>> It would be a ton of work to port - maybe when WebAssembly will
> >>>> make that
> >>>> easier, and more rewarding, but it's still going to take a
> >>>> combination of
> >>>> skills, motivation, and time/money to make this happen that
> >>>> doesn't seem to
> >>>> have been there. Surprising to me that the game companies
> >>>> haven't got into
> >>>> this, but I guess they think they can get by with sampling and
> >>>> Web Audio.
> >>>>
> >>>> Feels like a lack of vision though, or maybe there just aren't
> >>>> enough SC developers to justify it.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>> http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Browser-based-SuperCollider-tp7632388p7632415.html
> >>>> Sent from the SuperCollider Users New (Use this!!!!) mailing list
> >>>> archive at Nabble.com.
> >>>>
> >>>> _______________________________________________
> >>>> sc-users mailing list
> >>>>
> >>>> info (subscription, etc.):
> >>>> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> >>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> >>>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
> >>>>
> >>>
> >>>
> >


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

crucialfelix
In reply to this post by amindfv
Definitely. I have been again warming up to the idea of haskell again. 
I've never given vivid a spin, but I definitely should !


On Wed, May 17, 2017 at 3:06 PM <[hidden email]> wrote:
...and if you do want to write purely functional supercollider, there's always my Vivid library :D


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

marc
In reply to this post by crucialfelix
I suspect that for simple cases, the overhead of copying to and
from WebAudio buffers would not be much of a problem. Of course, if the
goal is to work with native SC tools on a well configured and powerful
audio workstation, to get the best possible performance, then a WASM
port would be useless. SC on the web would be for projects that need
the web, not for projects that would suffers from the web.
--
Marc

On Wed, 17 May 2017 13:08:54 +0000
[hidden email] wrote:

> Then scsynth would be rendering into a buffer and you would then have
> to continually copy that into something like an AudioBufferSourceNode
> <https://developer.mozilla.org/en-US/docs/Web/API/AudioBufferSourceNode>
> to get it to play out.  There is a huge amount of overhead and
> complexity. That means worse performance.
>
> Audio software is generally very efficient and avoids every bit of
> extra work or copying. You would have to rework scsynth to the point
> of it being a different beast altogether.
>
> Why not just use webaudio directly ?
>
> Rather than try to get all of scsynth running, it is smarter I think
> to just port filters and UGens and make them process audio with:
>
> https://developer.mozilla.org/en-US/docs/Web/API/ScriptProcessorNode
>
> soon to be replaced by:
>
> https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API#Audio_Workers
> to process.
>
>
>
> On Wed, May 17, 2017 at 2:52 PM <[hidden email]> wrote:
>
> > WebAssembly can work with the WebAudio API,
> > in order to get sound data in and out. See:
> > https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
> > --
> > Marc
> >
> > Le Wed, 17 May 2017 12:20:20 +0000
> > [hidden email] a écrit:
> >
> > > You could compile scsynth to wasm, but how are you going to get
> > > sound data in and out ?
> > > Filesystem access ? socket libraries ?
> > >
> > > Every single interface and library that connects with the outside
> > > world has to be cut off.
> > >
> > > When embedded in the web <http://webassembly.org/docs/web/>,
> > > WebAssembly will enforce the same-origin and permissions security
> > > policies of the browser.
> > >
> > > WebAssembly modules will be able to call into and out of the
> > > JavaScript context and access browser functionality through the
> > > same Web APIs accessible from JavaScript.
> > >
> > > Are you going to copy a buffer into a javascript array 172 times a
> > > second ? that isn't really going to be very efficient.
> > > It is more likely that simpler things like c++ filters can be
> > > compiled to wasm js. But they are going to suck.
> > >
> > > Running i/o intensive applications really isn't what webassembly
> > > is all about.
> > >
> > > Let me ask this: why would you want to run scsynth inside a
> > > browser ?
> > >
> > >
> > > On Wed, May 17, 2017 at 12:52 PM <[hidden email]> wrote:
> > >
> > > > ```
> > > > webassembly may be able to compile scsynth to run inside a
> > > > browser at some point. There will be limitations though.
> > > > Timing and garbage collection issues.
> > > > Communicating back and forth with UI is harder. Realtime MIDI
> > > > and OSC are going to require work.
> > > >
> > > > WASM will enable some specific high performance computing tasks
> > > > like graphics and ML on the edge (in client machines, not
> > > > always in the cloud) But it isn't a general purpose "C++ in the
> > > > browser".  Shit, we can barely get audio to run on linux, how
> > > > are we going to get it to run in the browser ;)
> > > >
> > > > What is the real purpose of running in a browser ? It has a DOM
> > > > which you can use to make dynamic interfaces.
> > > > Actually the DOM is the biggest performance blocker and source
> > > > of frustration. Plenty of people trying to get around the DOM.
> > > >
> > > > ```
> > > >
> > > > Do you know WASM ? What if we put SuperCollider code on it ??
> > > >
> > > >
> > > >
> > > > 2017-05-16 23:32 GMT+02:00 <[hidden email]>:
> > > >
> > > >>
> > > >> supercollider.js is an alternative to sclang. It controls
> > > >> scsynth in the exact same way as sclang does.
> > > >> JavaScript aka ECMA script is now a very nice language.
> > > >> Primarily it is for writing music applications that run on
> > > >> node.js on your computer.
> > > >>
> > > >> https://crucialfelix.github.io/supercolliderjs/
> > > >>
> > > >> examples:
> > > >> https://github.com/crucialfelix/supercolliderjs-examples
> > > >>
> > > >> When people hear "javascript" they assume that it must
> > > >> therefore run in the browser.
> > > >> It is at this point a general purpose programming language
> > > >> with a lot of nice language features.
> > > >>
> > > >> Many things that were exciting about supercollider are now in
> > > >> javascript. I think it's a much nicer language than sclang now.
> > > >>
> > > >> I have written Electron apps with it and some browser based
> > > >> apps that run on my local machine.
> > > >> A few other people have built apps with it. React and Vue.
> > > >>
> > > >> But still the bridging costs are high and trying to make this
> > > >> work adds to the complexity.
> > > >> It's advanced, not suitable for beginners. It isn't easy yet.
> > > >>
> > > >> webassembly may be able to compile scsynth to run inside a
> > > >> browser at some point. There will be limitations though.
> > > >> Timing and garbage collection issues.
> > > >> Communicating back and forth with UI is harder. Realtime MIDI
> > > >> and OSC are going to require work.
> > > >>
> > > >> WASM will enable some specific high performance computing tasks
> > > >> like graphics and ML on the edge (in client machines, not
> > > >> always in the cloud) But it isn't a general purpose "C++ in the
> > > >> browser".  Shit, we can barely get audio to run on linux, how
> > > >> are we going to get it to run in the browser ;)
> > > >>
> > > >> What is the real purpose of running in a browser ? It has a DOM
> > > >> which you can use to make dynamic interfaces.
> > > >> Actually the DOM is the biggest performance blocker and source
> > > >> of frustration. Plenty of people trying to get around the DOM.
> > > >>
> > > >> WebGL is nice but then you can have real OpenGL if you program
> > > >> in OpenFrameworks or similar.
> > > >>
> > > >> I do love javascript. It's a mess though. A lot of us are
> > > >> moving to pure functional programming.
> > > >> Facebook has an OCaml to javascript compiler that they use to
> > > >> write really solid js driven apps.
> > > >>
> > > >> - felix (supercollider.js)
> > > >>
> > > >>
> > > >> On Tue, May 16, 2017 at 5:47 PM <[hidden email]> wrote:
> > > >>
> > > >>> The biggest holdup isn't efficiency, it's that JavaScript
> > > >>> audio callbacks (via the ScriptProcessor node) run in the
> > > >>> main thread (!!!) and incur an extra buffer of latency. Audio
> > > >>> Worklets will help solve this problem when they finally see
> > > >>> the light of day. - Charlie
> > > >>>
> > > >>> On Tue, May 16, 2017 at 5:03 PM, <[hidden email]> wrote:
> > > >>>
> > > >>>> Java was definitely the right solution back then.
> > > >>>>
> > > >>>> It would be a ton of work to port - maybe when WebAssembly
> > > >>>> will make that
> > > >>>> easier, and more rewarding, but it's still going to take a
> > > >>>> combination of
> > > >>>> skills, motivation, and time/money to make this happen that
> > > >>>> doesn't seem to
> > > >>>> have been there. Surprising to me that the game companies
> > > >>>> haven't got into
> > > >>>> this, but I guess they think they can get by with sampling
> > > >>>> and Web Audio.
> > > >>>>
> > > >>>> Feels like a lack of vision though, or maybe there just
> > > >>>> aren't enough SC developers to justify it.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> View this message in context:
> > > >>>>
> > http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Browser-based-SuperCollider-tp7632388p7632415.html
> > > >>>> Sent from the SuperCollider Users New (Use this!!!!) mailing
> > > >>>> list archive at Nabble.com.
> > > >>>>
> > > >>>> _______________________________________________
> > > >>>> sc-users mailing list
> > > >>>>
> > > >>>> info (subscription, etc.):
> > > >>>>
> > http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> > > >>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> > > >>>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
> > > >>>>
> > > >>>
> > > >>>
> > > >
> >
> >
> > _______________________________________________
> > sc-users mailing list
> >
> > info (subscription, etc.):
> > http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> > archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> > search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
> >


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Browser-based SuperCollider?

Nathan Ho
In reply to this post by grahamsw
grahamsw wrote
Given that SC is portable, and that a modern browsers' JS engine is easily as powerful as a 90's PC, is there a reason that there isn't a JavaScript port of Supercollider?

I've seen entire gaming engines run the Quake II in the brower, and I can't believe the computational demands of SC are higher than that. I've seen SCScript, but that hasn't been worked on for 3 years.

Is there simply no demand for this? Is seems to me that it would be a hell of a way of making SuperCollider skills more valuable, and of getting a much larger developer community involved.

What am I missing?
hi graham,

overall, considering the above discussion, i'd say that web audio + webassembly/asm.js is the immature intersection of immature technologies. scsynth takes pride in reliability and efficiency, and you throw that out the window when you run it on top of these things.

i do hope i'm wrong. (also, NRT mode could probably work.)

also check out flocking (http://flockingjs.org/) which is a supercollider-inspired audio environment written in JS. haven't used it but it looks cool.


nathan
12
Loading...