Hello All,
somewhat excited about Kita and Tarmo experiment, and now also this pnacl
thing by 
Victor, i would need some help in understand how are those working.
I mean, i guess that Tarmo has a physical server located somewhere that is
running 
a Csound instance receiving messages from over internet. So i would need a
server 
in my home, to be visible for the rest of the world, etc.
In Victor pnacl example i see something similar, except that every user use
a single 
Csound instance not shared with others. In this case i would need a service
like 
dropbox where i install Csound and again that will be public to others.
Am i right? Could someone explain or point me to some resources how all this
things
works?

Thanks for anything or nothing,
ciao,
francesco.






--
View this message in context: http://csound.1045644.n5.nabble.com/OT-Csound-on-servers-web-servers-tp5729912.html
Sent from the Csound - General mailing list archive at Nabble.com.

Not sure this is OT. 
Anyway here are some answers:

1. Kita & Tarmo’s server: yes, it’s running on a machine which has a port that allows
open access via TCP/IP.  In addition to allowing you to make a custom frontend like this, 
Csound now allows you to run such a server without having to write a program for it.
For instance, from the command-line (or with other frontends),

$ csound -odac —port=N

will run Csound as a UDP server, receiving orchestra code in port N. You can use
jack and streaming software as Talmo is doing to stream the data out to listeners.

2. Csound for pNaCl uses the Native Client technology to deliver a module that
runs locally in the user's machine (inside the browser) and can be controlled via 
Javascript/HTML5 code. In this case, two things are important: 

a. pages can only be served through http (or https), you can’t run the module from
a file:// protocol. You can run a minimal local server to allow the module to run, though.

b. with the compiled module, which runs in Chrome under any platform, you can create
GUI frontends just by writing HTML5 code, which should be handy for composers,
installation artists, etc.

I hope this answers your queries.

Victor


On 21 Nov 2013, at 09:03, francesco  wrote:

> Hello All,
> somewhat excited about Kita and Tarmo experiment, and now also this pnacl
> thing by 
> Victor, i would need some help in understand how are those working.
> I mean, i guess that Tarmo has a physical server located somewhere that is
> running 
> a Csound instance receiving messages from over internet. So i would need a
> server 
> in my home, to be visible for the rest of the world, etc.
> In Victor pnacl example i see something similar, except that every user use
> a single 
> Csound instance not shared with others. In this case i would need a service
> like 
> dropbox where i install Csound and again that will be public to others.
> Am i right? Could someone explain or point me to some resources how all this
> things
> works?
> 
> Thanks for anything or nothing,
> ciao,
> francesco.
> 
> 
> 
> 
> 
> 
> --
> View this message in context: http://csound.1045644.n5.nabble.com/OT-Csound-on-servers-web-servers-tp5729912.html
> Sent from the Csound - General mailing list archive at Nabble.com.
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>            https://sourceforge.net/p/csound/tickets/
> csound5:
>            https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

Thanks Victor,
understood. Just another question:)
In Your pnacl examples is Csound running on dropbox server, not
in Your local machine, right?

Thank You
ciao,
francesco.






--
View this message in context: http://csound.1045644.n5.nabble.com/OT-Csound-on-servers-web-servers-tp5729912p5729918.html
Sent from the Csound - General mailing list archive at Nabble.com.

It is run on the local machine. The server is only there to serve the page and the module.

Victor
On 21 Nov 2013, at 12:00, francesco  wrote:

> Thanks Victor,
> understood. Just another question:)
> In Your pnacl examples is Csound running on dropbox server, not
> in Your local machine, right?
> 
> Thank You
> ciao,
> francesco.
> 
> 
> 
> 
> 
> 
> --
> View this message in context: http://csound.1045644.n5.nabble.com/OT-Csound-on-servers-web-servers-tp5729912p5729918.html
> Sent from the Csound - General mailing list archive at Nabble.com.
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>            https://sourceforge.net/p/csound/tickets/
> csound5:
>            https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

Indeed,

this works very well (after so,e small testing) and it could replace my csound-server so easily. The only main change is I used TCP messages to be sure the messages don't get lost (and give some feedback fro clients), but for wired internet the risc is probably not so big...

Also I find it is great when csound is used via API in another application - it can be so handy to send some new code, change insruments or constants.

great idea!

tarmo

On Wednesday 27 November 2013 18:02:59 Andres Cabrera wrote:

On Thu, Nov 21, 2013 at 3:49 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:

$ csound -odac —port=N

This is fun, I missed it somehow...

Maybe I should allow a server instance within CsoundQt...

Cheers,
Andrés

It might be possible to offer a TCP alternative. At the time, it appeared simpler and more convenient to offer UDP.
My idea was also that an emacs frontend could be created, sending instruments through UDP (and linevents, also, through a pipe).

Victor
On 28 Nov 2013, at 11:40, Tarmo Johannes  wrote:

> Indeed,
>  
> this works very well (after so,e small testing) and it could  replace my csound-server so easily. The only main change is I used TCP messages to be sure the messages don't get lost (and give some feedback fro clients), but for wired internet the risc is probably not so big...
>  
> Also I find it is great when csound is used via API in another application - it can be so handy to send some new code, change insruments or constants.
>  
> great idea!
>  
> tarmo
>  
> On Wednesday 27 November 2013 18:02:59 Andres Cabrera wrote:
> 
> On Thu, Nov 21, 2013 at 3:49 AM, Victor Lazzarini  wrote:
> $ csound -odac —port=N
> 
> 
> This is fun, I missed it somehow...
> Maybe I should allow a server instance within CsoundQt...
> 
> Cheers,
> Andrés