It is not currently possible. Part of the problem is that static OSC port numbers are in direct conflict with session management, multiple client instances, etc., similar to command-line arguments (and in fact, these often are also encoded as command-line arguments). Because of this, I'm reluctant to contribute to making the situation worse by encouraging more use of static OSC port numbers. If the other program were to use Non's OSC::Signal layer, then they could communicate with the dynamic port numbers and the cushy discoverability features seen with Non-Mixer's OSC control endpoints. One could also write an NSM client which speaks OSC::Signal and translates that to whatever (which is how non-midi-mapper works).
However, Non's OSC::Signal protocol is not formally documented (although it's plug and play for anyone to just use the C++ class without necessarily understanding the protocol). I had hoped to finalize it and standardize between what Non and ZynAddSubFX were doing, but development of RTOSC proceeded quicker than I could keep up and I missed the boat on unifying everything. I will say, though, that OSC::Signal is a very simple pure OSC procotol (i.e. no XML, JSON or other unrelated crap shoved down your throat), and shouldn't be difficult to reimplement in another language if C++ is out of the question. On Mon, Feb 3, 2020 at 1:19 AM rosea.grammostola < [email protected]> wrote: > Hi, > > How do I sent OSC messages (automation) from non-timeline to a other > application? Is it possible to set a osc address/port to sent to? > > Regards, > > \r > >
