0

I have a Processing program which derives a string of information which will eventually be turned into sound. This is similar to how photo sounder works, or metasynth, where pixels are turned into sound. I am hoping to be able to stream a portion of this information to ChucK or Pure Data.

For now I do not want to actually process the audio within Processing. That program is being used only to generate the information from a touch interface and series of images.

I know that I can send data type b (for blob) from Processing (I think, I cannot find any examples) using OSC.

I cannot find any examples on how to receive such information in ChucK or Pure Data and then use it for generating sound.

I admit I may not be searching for the correct terms on some of these processes so any help would be appreciated.

Max N
  • 1,134
  • 11
  • 23
nosarious
  • 309
  • 1
  • 12

2 Answers2

4

All though it might be possible, OSC is designed for control values, not audio. To receive those OSC messages there are methods in each program to do so. In Pd you can choose from a few libraries which provide OSC functionality, for example mrpeach, or pd-osc and pd-iemnet libraries in the Debian repositories.

Max N
  • 1,134
  • 11
  • 23
  • I have been trying PureData and the MrPeach library. I have also found the information for ChucK and osc. The unpackOSCStream for mr.peach looks like it might work. Chuck doesn't seem to work with osc blob data. 8^( I've been trying to rework this project as sending two pieces of data at a time instead of the entire string. Basically count through the line and send the remapped log value for the number of the item on the line, and then the item itself. (log value seems easier to calculate in Processing) – nosarious May 29 '13 at 22:35
  • The hard part now is just trying to figure out how to recombine this into either program (PD/ChucK)so that there is identifiable sound changes from what is found in the image. – nosarious May 29 '13 at 22:38
  • please note that the "stream" in [unpackOSCstream] refers to the *underlying* transport protocol (TCP/IP is a stream-based protocol like a serial connection; this is opposed to UDP, which is a packet-based protocol), not to the higher-level application data (your audio "stream"); unless you are transmitting data over a serial protocol like tcp, this object is most likely *not* what you want. – umläute Jun 03 '13 at 12:26
  • @Max_N please note that "you can't send audio over OSC because it is made for control values" is plain wrong. the problem is how (as with all things OSC) to make sure that the receiving side knows how to play back those numbers (well mainly how to reassemble an audio stream from packets of numbers) – umläute Jun 13 '13 at 10:03
  • 1
    @umläute: Can you provide any examples or documentation on sending audio over OSC? Maybe it *might* be possible but as I understand it OSC hasn't be designed for transmitting audio. – Shannon Matthews Aug 20 '13 at 03:05
  • @Shannon, you are right that OSC hasn't been *designed* for transmitting audio. but then the internet/arpanet has not been designed for transmitting http (webpages) either. since OSC is really only a thin layer on top of UDP (or whatever transport protocol you are using) that makes sure that *bytes* are interpreted correctly (e.g. as *numbers*, which could be samples), it's actually quite simple to build an audio transmitter on top of OSC: you basically only need to transmit a "timestamp" and an array of numbers, which you then reassemble into an audio stream. i'll try to cook up a real answer – umläute Aug 21 '13 at 07:58
1

On the Processing side, you should have a look on oscP5 contributed library that works very well for me. Link : http://www.sojamo.de/libraries/oscP5/ I don't remember which library i used within pd to handle osc, but i think it has been made easier directly through [netreceive] on most recent versions (0.46). At least i can say that I could do the reverse (realtime graphing spectra in Processing from pd analysis). Hope this helps,

hhphaeh
  • 11
  • 1