As I mentioned in another thread, I'm assembling a performance rig that includes (among other components) a (headless) Raspberry running Csound and an Android tablet. I'm now thinking about how I might control a Csound app running on the RPi (with the sound output issuing from the RPi) and using some sort of GUI on the tablet.

It struck me that one approach might be to use HTML5-based widgets ala Rory's RiB-Csound, but rather than running in front of PNACL-based Csound in the browser, somehow interact over wifi with the Csound instance on the RPi. This raises the question: is there currently any way to interact with Csound channels via a network connection, e.g., HTTP or TCP/IP? This could be very interesting, but probably non-trivial -- perhaps a node.js-based app the serves up the UI and uses the Cound API (there seems to be a node module called node-java that might do the trick). My main concern would be latency between the UI and the server, but in the case of a tablet connected to an RPi using ad-hoc wifi, it just might work.

(I like the PNACL stuff very much, but it doesn't seem suitable in this configuration -- not sure if PNACL is even available for Chrome on Android, and besides, ideally I'd like to be able to run independent instances of Csound on the tablet and the RPi simultaneously.) 

Alternatively, Tarmo's Csound server ought to work very nicely in this environment, but given that I'll be working with a small touch-screen rather than a laptop, I'd prefer to work with a widget-based UI.

Any thoughts? In the recent flurry of amazing way to interact with Csound, have I missed something that I could bend to this purpose?

- Dave

pnacl does not yet exist for Android. Android and iOS have a very different process architecture than Linux, Windows, or OS X. That means the C runtime library system calls are different.

I think Google would probably like to get pnacl working on Android, but I'm not sure if it's really practical. I hope it happens, though.

In the long run, everything will be more or less like Linux, and have a Posix style process architecture, and then pnacl becomes a compelling way to deliver one program to many hardware architectures.

Regards,

Mike

-----------------------------------------------------

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

On Fri, Nov 29, 2013 at 11:54 AM, Dave Seidel <dave.seidel@gmail.com> wrote:

As I mentioned in another thread, I'm assembling a performance rig that includes (among other components) a (headless) Raspberry running Csound and an Android tablet. I'm now thinking about how I might control a Csound app running on the RPi (with the sound output issuing from the RPi) and using some sort of GUI on the tablet.

It struck me that one approach might be to use HTML5-based widgets ala Rory's RiB-Csound, but rather than running in front of PNACL-based Csound in the browser, somehow interact over wifi with the Csound instance on the RPi. This raises the question: is there currently any way to interact with Csound channels via a network connection, e.g., HTTP or TCP/IP? This could be very interesting, but probably non-trivial -- perhaps a node.js-based app the serves up the UI and uses the Cound API (there seems to be a node module called node-java that might do the trick). My main concern would be latency between the UI and the server, but in the case of a tablet connected to an RPi using ad-hoc wifi, it just might work.

(I like the PNACL stuff very much, but it doesn't seem suitable in this configuration -- not sure if PNACL is even available for Chrome on Android, and besides, ideally I'd like to be able to run independent instances of Csound on the tablet and the RPi simultaneously.) 

Alternatively, Tarmo's Csound server ought to work very nicely in this environment, but given that I'll be working with a small touch-screen rather than a laptop, I'd prefer to work with a widget-based UI.

Any thoughts? In the recent flurry of amazing way to interact with Csound, have I missed something that I could bend to this purpose?

- Dave

Hi Dave,

I had put up my project OSCsound:

https://github.com/kunstmusik/OSCsound

That does direct mapping of OSC channel inputs to Csound channels.  I
haven't had a chance to look at it since I put it up, but it was meant
for this kind of situation.  Last I tried there seemed to be a bit of
latency though from the time of input to the time of change in Csound.
 I did not analyze though where the latency was though.  It could be
the python implementation (could change to Java or C fairly easily),
but it could have been something else.  Perhaps something to try?

steven

On Fri, Nov 29, 2013 at 11:54 AM, Dave Seidel <dave.seidel@gmail.com> wrote:

> As I mentioned in another thread, I'm assembling a performance rig that
> includes (among other components) a (headless) Raspberry running Csound and
> an Android tablet. I'm now thinking about how I might control a Csound app
> running on the RPi (with the sound output issuing from the RPi) and using
> some sort of GUI on the tablet.
>
> It struck me that one approach might be to use HTML5-based widgets ala
> Rory's RiB-Csound, but rather than running in front of PNACL-based Csound in
> the browser, somehow interact over wifi with the Csound instance on the RPi.
> This raises the question: is there currently any way to interact with Csound
> channels via a network connection, e.g., HTTP or TCP/IP? This could be very
> interesting, but probably non-trivial -- perhaps a node.js-based app the
> serves up the UI and uses the Cound API (there seems to be a node module
> called node-java that might do the trick). My main concern would be latency
> between the UI and the server, but in the case of a tablet connected to an
> RPi using ad-hoc wifi, it just might work.
>
> (I like the PNACL stuff very much, but it doesn't seem suitable in this
> configuration -- not sure if PNACL is even available for Chrome on Android,
> and besides, ideally I'd like to be able to run independent instances of
> Csound on the tablet and the RPi simultaneously.)
>
> Alternatively, Tarmo's Csound server ought to work very nicely in this
> environment, but given that I'll be working with a small touch-screen rather
> than a laptop, I'd prefer to work with a widget-based UI.
>
> Any thoughts? In the recent flurry of amazing way to interact with Csound,
> have I missed something that I could bend to this purpose?
>
> - Dave
>

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"

Hi,

 

I have done by now quite some interactive procject using android devices as controllers and using OSC as the connection protocol to computer (or PI on your case). Espexially, if you use wired internet, I think OSC is really the easiest way to communicate.

 

From the other hand - android devices (especially with weaker cpu) have quite some latency and if you concern in to avoid it as much as possible, perhaps some physical widgets (buttons, sliders/potentiometers or something like tha) attached directly to the IO ports would be the shortest way.

 

Also you mentioned arduino in one email. I am not an expert but if you dont need very many input/outputs, I would go for PI's own IO instead and avoid one step behind (although they say it is easy to brick you PI, if you are not careful).

 

But of course- using tablet and OSC would be probably the most comfortable solution.

 

I have used javaOSC library and have written my own user interfaces on android (or once used touchOSC). And there is also Processing (open video/graphics) rendering software that has good android support.

 

So -- there are too many options, use what seems easiest and most comfortable for you.

 

best!

tarmo

 

On Friday 29 November 2013 12:34:23 Dave Seidel wrote:

Excellent, Steven, I'd forgotten about this one! I think this approach would make perfect sense for my scenario. And it looks like there's at least one implementation of a JS-based OSC client: http://kievii.net, which would be another part of the puzzle.

Cool!

- Dave

On Fri, Nov 29, 2013 at 12:24 PM, Steven Yi <stevenyi@gmail.com> wrote:

Hi Dave,

I had put up my project OSCsound:

https://github.com/kunstmusik/OSCsound

That does direct mapping of OSC channel inputs to Csound channels.  I
haven't had a chance to look at it since I put it up, but it was meant
for this kind of situation.  Last I tried there seemed to be a bit of
latency though from the time of input to the time of change in Csound.
 I did not analyze though where the latency was though.  It could be
the python implementation (could change to Java or C fairly easily),
but it could have been something else.  Perhaps something to try?

steven

On Fri, Nov 29, 2013 at 11:54 AM, Dave Seidel <dave.seidel@gmail.com> wrote:

> As I mentioned in another thread, I'm assembling a performance rig that
> includes (among other components) a (headless) Raspberry running Csound and
> an Android tablet. I'm now thinking about how I might control a Csound app
> running on the RPi (with the sound output issuing from the RPi) and using
> some sort of GUI on the tablet.
>
> It struck me that one approach might be to use HTML5-based widgets ala
> Rory's RiB-Csound, but rather than running in front of PNACL-based Csound in
> the browser, somehow interact over wifi with the Csound instance on the RPi.
> This raises the question: is there currently any way to interact with Csound
> channels via a network connection, e.g., HTTP or TCP/IP? This could be very
> interesting, but probably non-trivial -- perhaps a node.js-based app the
> serves up the UI and uses the Cound API (there seems to be a node module
> called node-java that might do the trick). My main concern would be latency
> between the UI and the server, but in the case of a tablet connected to an
> RPi using ad-hoc wifi, it just might work.
>
> (I like the PNACL stuff very much, but it doesn't seem suitable in this
> configuration -- not sure if PNACL is even available for Chrome on Android,
> and besides, ideally I'd like to be able to run independent instances of
> Csound on the tablet and the RPi simultaneously.)
>
> Alternatively, Tarmo's Csound server ought to work very nicely in this
> environment, but given that I'll be working with a small touch-screen rather
> than a laptop, I'd prefer to work with a widget-based UI.
>
> Any thoughts? In the recent flurry of amazing way to interact with Csound,
> have I missed something that I could bend to this purpose?
>
> - Dave
>

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, Tarmo, this is good information. I'm going to try using a web-based UI that sends OSC to the Pi. I'll probably use Steven's CsoundOSC on the Pi, but I'm also considering writing a node.js module module that receives OSC and talks to the Csound API. I want to take this route so that I can run the Pi headless and talk to it from my tablet using HTTP and SSH. And I'd prefer to use a browser UI instead of writing an Android app, because it would be more portable and reusable in other contexts.

I have two Arduino--based devices, an Auduino and a rePatcher. The Auduino is an Arduino synth, but it can be used as a programmable hardware controller, and I've used it with realtime Csound via csoundapi~ on my laptop. I'd like to learn how to directly talk to Csound using the serial opcodes to eliminate the extra pd layer, which should make it more efficient for the Pi. The rePatcher is another interesting programmable Auduino-based interface that was originally designed for use with Max and pd, but I hope to get it working directly with Csound as well. Both of these devices communicate with the Pi over USB.

- Dave

On Fri, Nov 29, 2013 at 4:01 PM, Tarmo Johannes <tarmo.johannes@otsakool.edu.ee> wrote:

Hi,

 

I have done by now quite some interactive procject using android devices as controllers and using OSC as the connection protocol to computer (or PI on your case). Espexially, if you use wired internet, I think OSC is really the easiest way to communicate.

 

From the other hand - android devices (especially with weaker cpu) have quite some latency and if you concern in to avoid it as much as possible, perhaps some physical widgets (buttons, sliders/potentiometers or something like tha) attached directly to the IO ports would be the shortest way.

 

Also you mentioned arduino in one email. I am not an expert but if you dont need very many input/outputs, I would go for PI's own IO instead and avoid one step behind (although they say it is easy to brick you PI, if you are not careful).

 

But of course- using tablet and OSC would be probably the most comfortable solution.

 

I have used javaOSC library and have written my own user interfaces on android (or once used touchOSC). And there is also Processing (open video/graphics) rendering software that has good android support.

 

So -- there are too many options, use what seems easiest and most comfortable for you.

 

best!

tarmo

 

On Friday 29 November 2013 12:34:23 Dave Seidel wrote:

Excellent, Steven, I'd forgotten about this one! I think this approach would make perfect sense for my scenario. And it looks like there's at least one implementation of a JS-based OSC client: http://kievii.net, which would be another part of the puzzle.

Cool!

- Dave

On Fri, Nov 29, 2013 at 12:24 PM, Steven Yi <stevenyi@gmail.com> wrote:

Hi Dave,

I had put up my project OSCsound:

https://github.com/kunstmusik/OSCsound

That does direct mapping of OSC channel inputs to Csound channels.  I
haven't had a chance to look at it since I put it up, but it was meant
for this kind of situation.  Last I tried there seemed to be a bit of
latency though from the time of input to the time of change in Csound.
 I did not analyze though where the latency was though.  It could be
the python implementation (could change to Java or C fairly easily),
but it could have been something else.  Perhaps something to try?

steven

On Fri, Nov 29, 2013 at 11:54 AM, Dave Seidel <dave.seidel@gmail.com> wrote:

> As I mentioned in another thread, I'm assembling a performance rig that
> includes (among other components) a (headless) Raspberry running Csound and
> an Android tablet. I'm now thinking about how I might control a Csound app
> running on the RPi (with the sound output issuing from the RPi) and using
> some sort of GUI on the tablet.
>
> It struck me that one approach might be to use HTML5-based widgets ala
> Rory's RiB-Csound, but rather than running in front of PNACL-based Csound in
> the browser, somehow interact over wifi with the Csound instance on the RPi.
> This raises the question: is there currently any way to interact with Csound
> channels via a network connection, e.g., HTTP or TCP/IP? This could be very
> interesting, but probably non-trivial -- perhaps a node.js-based app the
> serves up the UI and uses the Cound API (there seems to be a node module
> called node-java that might do the trick). My main concern would be latency
> between the UI and the server, but in the case of a tablet connected to an
> RPi using ad-hoc wifi, it just might work.
>
> (I like the PNACL stuff very much, but it doesn't seem suitable in this
> configuration -- not sure if PNACL is even available for Chrome on Android,
> and besides, ideally I'd like to be able to run independent instances of
> Csound on the tablet and the RPi simultaneously.)
>
> Alternatively, Tarmo's Csound server ought to work very nicely in this
> environment, but given that I'll be working with a small touch-screen rather
> than a laptop, I'd prefer to work with a widget-based UI.
>
> Any thoughts? In the recent flurry of amazing way to interact with Csound,
> have I missed something that I could bend to this purpose?
>
> - Dave
>

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"