Ofx osc tweaks [needs #7620]

[artificiel]

A collection of accumulated tweaks (tested in projects across macOS, iOS and linux), crossed with an audit of what was lying in GitHub issues.

I am submitting this as a "discussion PR" and am happy to chop it up as needed, but it seems more productive to present as a whole than a trickle of updates.

An example demonstrates most features: the constructors, the new friend std::optional, as well as method chains + overloaded-and-variadic add(). None of the changes involve "new design"; most of these changes are simply exposing latent C++ expressivity. No changes to current behaviour/performance. To be clear I am not advocating any of these "alternative" idioms as strictly better than the old school ones, but often they save lines of code, reduce redundancy, simplify usage, and enhance readability. All that translates to efficiency both in production or workshop contexts.

ofxOscSender:

• (feature) new method isReady() (dynamic test) closes suggestion: ofxOsc .isSetup() function or equivalent #5186

• (fix) changed return from void to bool for send() methods to report success of sending.

• (feature) new flag to silence the error messages when invalid socket. Defaults to false (not silent) for backwards-compat. Added to Settings. With the bool flag on send(), this allows one to build a more adaptive harness around ofxOscSender without polluting the console, for instance in cases were it might be "not an error" for the receiver not to be available.

• (feature) new ofxOscSender{string, int} to setup address:port; defaults to localhost:7970

• (feature) new overloaded method send() accepts Messages and Bundles and ofParameters

ofxOscReceiver:

• (feature) new ofxOscReceiver{int} to specify port at construction site; defaults to 7970

• (feature) new method getMessage() that returns std::optional<ofxOscMessage> for "cleaner" while (const auto m = receiver.getMessage()) {…} syntax.

ofxOscMessage:

• (feature) new ofxOscMessage{string} to specify address at construction site; no default

• (feature) ofxOscMessage::add*arg methods returns &*this for method chaining

• (feature) overloaded add() for unambiguous types, including variadic

ofxOscBundle:

• (fix) return std::size_t (addresses element of Warnings general #6929)

ofxOscSync

• (fix) enables sending and receiving ofParameter as OFXOSC_TYPE_TRIGGER (closes oscParameters Receiver + Sender not working with ofParameter<void> #7284)

oscpack:

• (fix) C++17 warnings on sprintf() now considered unsafe -> requires snprintf() (the correctly defined required sizes were already lying around)

[help needed] Issues cleanup:

• feature request: allow ofxOscReceiver to send messages (from the same port it receives) #2696 ofxOsc: provide access to an ofxOscSender's local port #3173: should be merged as it's good work (probably needs touch ups), but requires a PR maturing in Provide access to the local port used by a connected UdpSocket arturoc/oscpack#23, which should be merged too

• fixes for ofxOsc #5026 @tpltnt made all the converters explicit, as well as C++ casts. If it's still relevant, tests that fail on the previous behaviour should be added, and then the fix merged (will need a bit of work, perhaps enthusiasm has deflated...?) or else closed?

• error: please edit OSCHostEndianness.h or define one of {OSC_HOST_LITTLE_ENDIAN, OSC_HOST_BIG_ENDIAN} to configure endianness  #6588 someone could peruse and close? (Not sure how to repeat the error; perhaps it became a non-issue?)

• ofxOsc examples are outdated #4571 should be closed

• suggestion: ofxOsc .isSetup() function or equivalent #5186 closed by this

• oscParameters Receiver + Sender not working with ofParameter<void> #7284 closed by this

[artificiel]

tests are failing because this is relying on #7620

[ofTheo]

@artificiel thanks for this!
Are there any regressions in this PR that you can think of, or should existing code continue to work as expected?

[artificiel]

@ofTheo: the changes are mostly syntax additions (constructors, upgrade return types from void, some variadic methods), so the current behaviour (apart from adjusting the return type of ofxOscBundle) should not be modified -- it's one of the reasons I did not dig too deep in #5026 as it's touching the current processing. "anectodically" I've been using this branch for >12 months in 4-5 projects.

I realize there are many commits — it is OK to get them all squashed? for instance the oscpack changes are pretty specific and might warrant a more specific commit? perhaps also the return type changes? I don't know what kind of control GitHub provides on the granularity, and maybe it does not matter so much. As I mentioned above they're lumped in as single PR as they cover a coherent "topic" and can be reviewed as such.

[ofTheo]

Thanks @artificiel
Would be great if the oscOptionalExample could have all the standard ofApp functions and decoration.

But apart from that, I think this all looks good to merge as a mega commit :)
I think it's basically all or nothing with the squash options.

[artificiel]

@ofTheo to be sure, what do you mean by "all the standard ofApp functions and decoration"?

I took the habit of commenting out the unused parts of the interface as it makes it clearer for beginners to focus on what actually does something in a source code file. having the unused ofBaseApp methods greyed-out (but ready to be activated without fishing them "out of nowhere" (again, beginner p.o.v)) is a good compromise as far as implicit documentation goes, and a good way to introduce the concept of interface — "if you want to handle the mouse events... blahblah".

(on the topic in my own workshop files in a similar vein I generally use the single-file main.cpp approach as not having to navigate between windows/files when explaining/demonstrating makes things much more fluid, and for those coming from python or javascript it postpones a bit the requirement of learning about separating interface from implementation).

[ofTheo]

@artificiel In general we keep all the functions that are in emptyExample.

While I get your point, we've found it's helpful to have the empty functions so beginners can quickly add functionality to an example ( often times people modify the examples as a step towards making something new ).

For example: If you want to add a key press to trigger something, a beginner then has to uncomment it in the .h and then add it in the .ccp which is extra friction.

Anyway, good to match the general practice if possible. :)

[ofTheo]

Also I would say changing the style/format of all the examples is definitely a discussion that can be had.
There are probably better approaches.

It's just better to do that after a discussion and then PR all in one go instead of each example being in a completely different approach.

[ofTheo]

woohoooo! 🎉