Hi folks,
I was playing a bit with csound in the last days and - with the help of a nice italian multimedia artist Cesare Marilungo - got some first success producing some csound events from squeak using OSC (Open Sound Control). OSC is a light way protocol with which one can send messages to an ip/port combo including some strings, floats or blobs. It exists for csound, python, squeak and lots of other systems, usually works on top of udp, but can be changed to work on tcp/ip too.
http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec.html
Until now we are using the sound bank from Tamtam, so no real soft synthesis but sampling. It's fun to create and listen to sounds via scripts a la
frequency := 200. velocity := 30000. start := 0. instrument := 12. duration := 11. (OSCMessage for: {'/squeak/osc'. frequency. velocity. start. instrument. duration}) sendTo: (NetNameResolver localHostAddress) port: 1122.
Nothing fency yet, but much more synchronized tunes are possible, as you can tell csound when to trigger the events, within Squeak I encountered some problems there... http://www.squeakland.org/project.jsp?http://www.emergent.de/pub/ smalltalk/squeak/projects/musinum.pr (first start the midi service with the button on the left top, this is _not_ using csound...yet)
The tamtam people are using csound by sending python scripts through the ether - hoping that they will do no harm. As far as I understand some sandboxing is on the way for python but I wonder when it will arrive...
I asked Bert off list how to start another app from squeak, he told me that neither FFI nor OSProcess will be included for security reasons. Makes sense. But then we need another solution to start and talk to other apps, ideally also fruitful for inter-app communication between python apps - or between Etoy Apps.
SO: I wonder what you folks think about using OSC as a general inter- application protocol for the OLPC? For starting another app I'd suggest to have a server which knows (white lists) all securely executable apps and provides an OSC interface. This server (like all OSCed Apps should) can also display all its executable services/apps.
Then apps like Etoys needing to start other apps (like Etoys needed to start csound) could ask this server to start their needed client apps. Each app can be reached via OSC on a different port, as soon as the server started the other app, it tells the starting app the port number of the started app so that they can talk directly to each other. Again no further security measures needed, as each app whitelists its available services.
If you have a hammer the whole world looks like a nail? Or could Open Sound Control fit to the "Instrument whose music is ideas"? ;-)
Very curios about your views on that.
Cheers,
Markus
Markus Gaelli wrote:
If you have a hammer the whole world looks like a nail? Or could Open Sound Control fit to the "Instrument whose music is ideas"? ;-)
I had understood that dbus was supposed to be the universal communication system for OLPC. But I don't know anything about it other than that the latest version of Skype needs it but the dbus build in Gentoo is broken so I can't install it on this machine :-(
-- Jecel
On Sep 29, 2006, at 7:09 PM, Jecel Assumpcao Jr wrote:
Markus Gaelli wrote:
If you have a hammer the whole world looks like a nail? Or could Open Sound Control fit to the "Instrument whose music is ideas"? ;-)
I had understood that dbus was supposed to be the universal communication system for OLPC. But I don't know anything about it other than that the latest version of Skype needs it but the dbus build in Gentoo is broken so I can't install it on this machine :-(
Ah, ok. I am also ignorant about dbus too. This one helps: http://www.linuxjournal.com/article/7744 Interesting. Though hard to get hands on dbus with the OS-X I am using also: http://lists.freedesktop.org/archives/dbus/2006-September/005844.html
There is a dbus squeak implementation done by Daniel Faken: http://www.visoracle.com/squeakfaq/dbus-inter.html http://lists.freedesktop.org/archives/dbus/2005-May/002673.html I haven't tried it
I have not found an "application starter service" though this should not be too hard to implement - or exists already probably.
But: One cannot directly send messages to other computers via dbus, nor does it work for interfacing apps like csound. So it's a solution to talk to (and maybe start) other applications - but not for everything. Grrr, no silver bullet again... ;-)
So, shall the csound experience of Squeak be based on the services TamTam already might provide (if it was connected to the bus) or do we want/need a direct csound interface?
And: Anyone up for trying the dbus implementation of Daniel in Sugar?
Cheers,
Markus
.
-- Jecel _______________________________________________ Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
Am 29.09.2006 um 20:43 schrieb Markus Gaelli:
There is a dbus squeak implementation done by Daniel Faken: http://www.visoracle.com/squeakfaq/dbus-inter.html http://lists.freedesktop.org/archives/dbus/2005-May/002673.html
This is based on FFI, so no real option for us. Also, it requires a patch to libdbus.
Right now we're still using Python's dbus bindings, forwarding messages via a pipe into Squeak. This was the simplest to get working.
And: Anyone up for trying the dbus implementation of Daniel in Sugar?
We need a different binding anyway, either by interfacing to libdbus or by implementing the dbus wire-protocol.
- Bert -
Bert Freudenberg wrote:
Right now we're still using Python's dbus bindings, forwarding messages via a pipe into Squeak. This was the simplest to get working.
And also by far the safest bet since the Python bindings will be updated for sure so we only have to care about the part that we want to care about (how to get the messages from/to the image). Generally, my feeling is that for our needs (make eToys run robustly) this is all we should be doing - I don't see the need to write our own bindings if all we need is to exchanges a few messages back and forth.
Cheers, - Andreas
On Sep 29, 2006, at 10:05 PM, Andreas Raab wrote:
Bert Freudenberg wrote:
Right now we're still using Python's dbus bindings, forwarding messages via a pipe into Squeak. This was the simplest to get working.
And also by far the safest bet since the Python bindings will be updated for sure so we only have to care about the part that we want to care about (how to get the messages from/to the image). Generally, my feeling is that for our needs (make eToys run robustly) this is all we should be doing - I don't see the need to write our own bindings if all we need is to exchanges a few messages back and forth.
Makes sense. But piping needs OS-Process, no? And OS-Process is not save/secure so it will have to go, no? If so, how will Squeak communicate with other processes?
Cheers,
Markus
Am 29.09.2006 um 22:21 schrieb Markus Gaelli:
On Sep 29, 2006, at 10:05 PM, Andreas Raab wrote:
Bert Freudenberg wrote:
Right now we're still using Python's dbus bindings, forwarding messages via a pipe into Squeak. This was the simplest to get working.
And also by far the safest bet since the Python bindings will be updated for sure so we only have to care about the part that we want to care about (how to get the messages from/to the image). Generally, my feeling is that for our needs (make eToys run robustly) this is all we should be doing - I don't see the need to write our own bindings if all we need is to exchanges a few messages back and forth.
Makes sense. But piping needs OS-Process, no? And OS-Process is not save/secure so it will have to go, no? If so, how will Squeak communicate with other processes?
Look at the implementation ;-)
No, I create a named pipe on the python side (mkfifo), hand that name as cmd line argument to the image, and open the pipe in Squeak using the AsyncFile plugin. The normal FilePlugin would block the whole VM, but AsyncFile works.
- Bert -
On Fri, Sep 29, 2006 at 11:05:11PM +0200, Bert Freudenberg wrote:
Am 29.09.2006 um 22:21 schrieb Markus Gaelli:
On Sep 29, 2006, at 10:05 PM, Andreas Raab wrote:
Bert Freudenberg wrote:
Right now we're still using Python's dbus bindings, forwarding messages via a pipe into Squeak. This was the simplest to get working.
And also by far the safest bet since the Python bindings will be updated for sure so we only have to care about the part that we want to care about (how to get the messages from/to the image). Generally, my feeling is that for our needs (make eToys run robustly) this is all we should be doing - I don't see the need to write our own bindings if all we need is to exchanges a few messages back and forth.
Makes sense. But piping needs OS-Process, no? And OS-Process is not save/secure so it will have to go, no? If so, how will Squeak communicate with other processes?
Look at the implementation ;-)
No, I create a named pipe on the python side (mkfifo), hand that name as cmd line argument to the image, and open the pipe in Squeak using the AsyncFile plugin. The normal FilePlugin would block the whole VM, but AsyncFile works.
Bert,
I don't know the background of this discussion, but I'll mention that it would be possible to make a less-insecure, stripped-down version of a few OSProcess functions. For example, if you just need a way to run programs with popen() from Squeak such that you can read and write to a non-blocking pipe, that could be done with modest effort.
Depending on how strict the security concerns are, it might be necessary to move the primitives out of OSPP and into the FilePlugin. Aside from this it would be mainly a matter of stripping out all the junk you don't need from OSProcess and repackaging the remainder as e.g. "POpen".
I'd be happy to do this if (and only if) there is a real need for it.
Dave
Am 30.09.2006 um 16:26 schrieb David T. Lewis:
On Fri, Sep 29, 2006 at 11:05:11PM +0200, Bert Freudenberg wrote:
I create a named pipe on the python side (mkfifo), hand that name as cmd line argument to the image, and open the pipe in Squeak using the AsyncFile plugin. The normal FilePlugin would block the whole VM, but AsyncFile works.
Bert,
I don't know the background of this discussion, but I'll mention that it would be possible to make a less-insecure, stripped-down version of a few OSProcess functions. For example, if you just need a way to run programs with popen() from Squeak such that you can read and write to a non-blocking pipe, that could be done with modest effort.
Depending on how strict the security concerns are, it might be necessary to move the primitives out of OSPP and into the FilePlugin. Aside from this it would be mainly a matter of stripping out all the junk you don't need from OSProcess and repackaging the remainder as e.g. "POpen".
I'd be happy to do this if (and only if) there is a real need for it.
Thanks :) But related to the OLPC development there is no need for popen() which I could foresee now. Besides, the ability to execute arbitrary programs does not exactly sound secure, does it?
Back on topic, the sole reason for having native DBUS bindings would be efficiency. We would spare us the python launcher that creates a GTK window into which the Squeak VM embeds its window (very similar to how npsqueak works).
- Bert -
Am 29.09.2006 um 20:43 schrieb Markus Gaelli:
On Sep 29, 2006, at 7:09 PM, Jecel Assumpcao Jr wrote:
Markus Gaelli wrote:
If you have a hammer the whole world looks like a nail? Or could Open Sound Control fit to the "Instrument whose music is ideas"? ;-)
I had understood that dbus was supposed to be the universal communication system for OLPC. But I don't know anything about it other than that the latest version of Skype needs it but the dbus build in Gentoo is broken so I can't install it on this machine :-(
But: One cannot directly send messages to other computers via dbus, nor does it work for interfacing apps like csound. So it's a solution to talk to (and maybe start) other applications
- but not for everything. Grrr, no silver bullet again... ;-)
Sugar uses zeroconf for broadcasting (a.k.a. Bonjour).
So, shall the csound experience of Squeak be based on the services TamTam already might provide (if it was connected to the bus) or do we want/need a direct csound interface?
I don't know. We should discuss this with the csound folks, on the Sugar mailing list.
- Bert -
etoys-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
David T. Lewis -
Jecel Assumpcao Jr -
Markus Gaelli