> This is ultimately more important to Piper than it may first appear. The > initial impression that most people may get of Piper is that it is a system > for /sequencial/ data flow (the data is passed to the next node only when the > current node is done). If we didn't have Overflow at the core of Piper, this > may be true. But Overflow is such a fast system that we want to include > /streaming/ data flow. Here's an excerpt from one of Jean-Marc's (Overflow > developer) recent e-mails: > > Jean-Marc wrote: > > I just thought this might be interesting to some of you, as a demo of what > > Overflow can do. I just "wrote" an Overflow program (.n) that performs real-time > > audio processing. It reads the soundcard input, normalized the volume (lowers > > louder sounds, amplifies lower sounds), and sends the result back to the > > soundcard output. It takes less than 5% CPU on my Athlon 500 at 44.1kHz/stereo > > (I use chunks of ~10 ms). Note, you need a full-duplex soundcard and the latest > > version in CVS to try it. Any electric guitar player here would like to help me > > write distortions and other effects? I'd just like to explain a bit more here. There is no special "streaming feature" in Overflow. What allows me to process sound in real-time is that Overflow, as any "language", allows loops (it takes a while to get used to loops -- we call them "Iterator" networks -- in a data-flow). If you want to do streaming, it's your responsability to cut down your nodes so they can work on a chunk of data. If you do that, then you can stream. As for the speed of the network, it won't give you CD quality in real-time, but it can allow you to split an hour-long processing in chunks of 1 minute. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01 at gel.usherb.ca