ovenwerks
commented
4 years ago You would use both. Any device would have it's own port but that device may have more than one virtual synth inside. I do not think anyone has floated the idea of using multicast or broadcast and I also don't think it would be that useful outside of a general panic message.
Edit: The other reason not to rely on ports is if the data is being stored in files. A port may not make sense there.
Does the spec assume that every synth (ie, sound module, device, whatever) is "listening" to every OSC message sent from any given device, much like daisy-chained MIDI devices? In other words, SYNoscopy assumes that there is one "bus", without any means of data routing in the "bus transport" itself, just like daisy-chained MIDI? And that's the reason why each synth must have a unique ID number? It's a very basic "routing number" built into the spec itself?
good thoughts. the answer is no. the (to discuss) reason for this was that it would be possible in this way that a synthesizer hosting program has one osc-listening port open and does the routing to the hosted destination IDs=synths (that are not all in the network!). otherwise when you play with your external osc keyboard, and want to control a different synth, you have to change that on the keyboard, and it's not direct possible from the synthesizer hosting program.
IDs would only have to be unique within the host, so no broadcasting.
ok, but the ID system could be replaced just by different ports (and if there's an application between, it could route to a wanted synth)
=> a method for switching to the right destiny synth is needed for the controller!
one thing that speaks against giving up on IDs are synth-generic methods. one would have to eg change the tuning for every ID separately. with the actual system, just a /SYN/ID*/TUNING... message has to get sent.