Multiple OSC [netreceive]rs (or, sharing data between instances?)

[jamshark70]

For an electronic ensemble course, one idea was to allow students to use their DAW (for comfort). So they would have multiple tracks, of which only one or two would be playing at a time. We also wanted to get control data from mobile devices (OSC over WLAN) and route to VST parameters.

Multiple instances of [netreceive] do not cooperate. To test this, I set up a Reaper project with two tracks, each with its own instance of plugdata, running the same patch where [netreceive -u -b (port)] goes --> [oscparse] --> [route] etc. When I send OSC to the right port, the second track's plugdata responds to the message, but the first one does nothing.

Mobile device OSC apps usually can't send to multiple ports -- so it's necessary to have multiple [netreceive]s with the same port -- but this is usually not allowed ("netreceive: listen failed: Address already in use (98)").

I also thought to work around this in the Max4Live way, by exploiting the shared namespace for [send] / [receive] pairs. I was pretty sure this wouldn't work -- I'd have been very surprised if multiple libpds shared namespaces -- and indeed it didn't. (This test was: Track 1 has the [netreceive], and uses [send cutoff] for the control value. Track 2 omits [netreceive] but has [r cutoff]. Track 1 responds; track 2 does not.)

For this use case, then, it seems like my best option would be to have a standalone Max or Pd process that sends MIDI CCs to a loopback interface. Probably OK in the short term (so, no expectation of any near-term work on this) but it does make me wonder -- where there are use cases for multiple plug-in instances having access to the same external control stream, what would be a good way for plugdata to support that?