You could build it yourself using vgetty
(http://alpha.greenie.net/vgetty/ ) and an old voice modem, which you
can get cheap off of ebay.

Another approach is to collect everyone's phone number and play their
ringers:

http://www.flong.com/telesymphony/

.hc

On Sep 4, 2004, at 10:04 AM, shreeswifty wrote:

Hi

i am beginning a project that deals with cell phone communication and
i am soliciting ideas for a way to include pd into the performance. What i would like to do is have visitors or
audience members turn on their cell phones before the performance instead of the traditional "please turn off all cell-phones..blah blah" The audience would then be given a phone number on screen to dial and
call into a voice system that would turn the cell phone message into
mp3s (OGGS)?

Which would/could stream using shoutcast~ back into the space.

Does anyone know of any services that do this online. I know of a
blogger site that does something like translating the call into an
audio file then i guess shoutcast it from there?

any ideas

i realise this is embryonic but i am wondering if this is possible
with pd in the mix

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://iem.at/cgi-bin/mailman/listinfo/pd-list

"Information wants to be free." -Stewart Brand

I realised a webproject last year with the still more common (hope it changes soon) J2ME midp1 so it runs on more phones. It connects to a server and let interact people in graphical ways. There is also a webversion for it. PD is not involved yet but maybe in the future...

http://www.mobileart.org/netart.html

Cheers,

Malte

At 23:35 04-09-2004, you wrote:

Jorge Cardoso wrote:

...

Hi all,

I have been playing around with [oggcast~ ]plus Icecast2 and a question has arised: What is the effect of changing the buffer size in [oggcast~]?

It would seem to me that using a bigger buffer would mean having a higher delay in the stream from to Icecast, but it seems to work the other way round! When I lower the buffer size in [oggcast~] I get higher delays in the sound stream...

Can anyone explain how this works?

The audio gets copied into the buffer and a second thread encodes and sends it. Since encoding and sending might take some time to complete the buffer needs a minimum size that depends on the speed of your machine (encoding) and the speed of the network connection (sending). Using larger buffer on a fast machine with high-speed connection should not change anything (apart from memory usage, of course). Olaf

My problem is that I want to have the minimum delay possible, because I'm using this in a remote, collaborative, interactive, event system (ufh). Basically, several users will be able to connect to a server and control visual events, on a local application, that are sent to that server. Those events are translated into sound events, that are streamed back to the user.

So, the larger the delay in the stream, the less obvious it will be for the users to relate the visual event to the sound event...

Right now, I'm getting delays in the order of 5/6 seconds, which is alot to me (I'm testing this in a local network). I'm using [oggcast~], Icecast2 and JOrbisPlayer as the streaming client.

I guess this is all a buffers problem: Icecast2 source encoder buffer [oggcast~], Icecast2 buffer, plus streaming client buffer [JOrbis]...

I can control the client buffer size, and probably the [oggcast~] buffer (if I recompile it). The Icecast2 buffer is more troublesome...besides, there are certainly efficiency problems in reducing the buffer sizes...

Has anyone tried to do something like this before? Any advice?

jc