4 ms·

Neat. I have seen a few talks about pure data, but they tend to mention transmission of data across the network, but not how they do it. In terms of message com

Neat. I have seen a few talks about pure data, but they tend to mention transmission of data across the network, but not how they do it. In terms of message communications for audio tools (beyond just MIDI) I've heard OSC discussed a fair bit, LV2 atoms somewhat, and then a good variety of custom protocols used by a single application. I'm biased towards OSC however since the binary serialization is very easy to manipulate in a realtime context (i.e. no locks, no dynamic memory). In fact I was biased enough that I ended up giving a talk at the linux audio conference about realtime safe OSC http://lac.linuxaudio.org/2018/pages/event/39/ http://lac.linuxaudio.org/2018/pages/event/39/ (with some nice performance figures to boot). It's cool to know what puredata is actually using under the hood.

monetus 8y ago
Oh, thanks for the link. I'm about to read your paper. I should clarify that when I said FUDI is faster, I was repeating the grumblings I've heard on pd's email list, despite not having benchmarked anything myself. With tcl's "everything is a string" (0) format, I could imagine this being contextual. But I am really curious. (0) - https://wiki.tcl.tk/3018 https://wiki.tcl.tk/3018 You might find this kinda funny, a piece of pd's documentation regarding the osc objects: "OSC is a complicated networking protocol (FUDI, as used in netsend/netreceive is simpler and better but less widely used). oscparse and oscformat make no attempt to deal with timetags or aggregates of packets, nor with streaming OSC. Also, no attempt is made here to clearly distinguish between the OSC address (symbols) and the following data, nor between blobs and lists of numbers - it is assumed that you know what types the message should contain. You can alternatively use the OSC objects from mrpeach which have more features than these."
- fundamental 8y ago
  I can't really blame them for their position. OSC has some really cool ideas, but the standards organization that was shaping the protocol ended up dissolving (somewhat) before all the rough edges could be sorted. I personally find it to be a nice serialization format with enough complexity to do what you need without it becoming all consuming.

monetus 8y ago

Oh, thanks for the link. I'm about to read your paper. I should clarify that when I said FUDI is faster, I was repeating the grumblings I've heard on pd's email list, despite not having benchmarked anything myself. With tcl's "everything is a string" (0) format, I could imagine this being contextual. But I am really curious. (0) - https://wiki.tcl.tk/3018 https://wiki.tcl.tk/3018 You might find this kinda funny, a piece of pd's documentation regarding the osc objects: "OSC is a complicated networking protocol (FUDI, as used in netsend/netreceive is simpler and better but less widely used). oscparse and oscformat make no attempt to deal with timetags or aggregates of packets, nor with streaming OSC. Also, no attempt is made here to clearly distinguish between the OSC address (symbols) and the following data, nor between blobs and lists of numbers - it is assumed that you know what types the message should contain. You can alternatively use the OSC objects from mrpeach which have more features than these."

fundamental 8y ago
I can't really blame them for their position. OSC has some really cool ideas, but the standards organization that was shaping the protocol ended up dissolving (somewhat) before all the rough edges could be sorted. I personally find it to be a nice serialization format with enough complexity to do what you need without it becoming all consuming.