What addons to drop?

[dimitre]

Just converting this to issue so we can discuss

[dimitre]

I like the idea of having openCV and Kinect not built in. maybe even ofxAssimpModelLoader maybe having a script to install or clone them all if needed? would love ofxMidi as a built in.

[smeyfroi]

Why ofxMidi but not openCV? I guess the quesiton is "what are the criteria for an addon to be shipped by default?"

[ofZach]

I think some ways to think about core addons are:

(a) does this add-on help other people who are making addons (ie, can you build off of it?).
(b) does it help do something that feels essential (ie, helping OF cover 90% usage case) for the core audience (c) does this add-on help show others how to construct or make addons

obviously this is a judgement call about things like openCV / Kinect / midi / etc. I personally use CV / GUI / OSC almost daily in my work but I rarely use ofxAssimp -- but maybe for someone who does more 3d work, that's really important.

[dimitre]

Nice, in fact I'm pretty indiferent to which addons will be kept or removed @smeyfroi. For me personally the best thing will be having the same addons for the next release. But I liked the call "what addons to drop" which it means openness to change.

I use assimp too, but it is the heaviest addon. as I now have like four installs of OF in my computer I start to see filesize as a parameter :) I think midi and artnet are just too good not to be there. I mean, you can output to synthesizers, modular systems, input from midi controllers, have physical sliders controlling your things in no time, lock physical sliders to your GUI, position your moving heads, move your motors :) it is a toy!

[smeyfroi]

The addons are very well separated so there's little disadvantage to shipping with stuff to cover the most common use-cases. Except filesize, yes! 😀

@ofZach criteria seems good in that context.

Personally I'd vote for the OpenCV APIs because they provide some fairly core image processing functionality out of the box.

And I need to look at MIDI controllers, @dimitre, because I think you just solved a problem I have with controlling interactive work. Thanks! 👍

[dimitre]

Are you still using ofxXmlSettings? I've ported everything to ofXml and never used it anymore.

[smeyfroi]

What does https://openframeworks.cc/documentation/ofxGui/ofxBaseGui/#show_saveToFile use? I only use that.

If I wanted to save something custom I'd be looking for a JSON or YAML serializer.

[artificiel]

looking through the 0.12 checklist https://github.com/openframeworks/openFrameworks/issues/6692 led me here maybe a bit late... but I'd like to contribute some thoughts which are not directly responding to the question of "what addons to drop" but more to the ecosystem of addons:

discovery

https://ofxaddons.com is now daunting. it is great that so many addons exist; less great for navigation and discovery (/freshest helps a bit, but you still need to be familiar with the landscape). moving things out of OF means dropping them in that sea.

Could there be a kind of intermediary "supported addons" category that would diminish the pressure on the core, yet augment the value of that intermediary layer by being more inclusive? An example: Csound does this with plugins -- which are a bit different in form (they are to be compiled in libraries that show up as opcodes in the Csound language, not small source trees to be #included) but similar in function: enable operations that are important but not central to the language, yet well-designed and maintained under the /csound organization. that means that plugin authors sort of relinquish their "author identity", but at the same time, more eyes are on the code. Then at release (or submodule) time, they can be pulled in.

[edited to add: having a larger set of "supported addons" within the of GitHub organization would facilitate the evolution of the core as a potential breaking change (for instance, refactoring return types) could be propagated coherently through a larger subset of addons (vs waiting for all the individual developers to adapt their interface -- even if the change is simply to go from a specific type to auto, there may be considerable latency before the addons are normalized).]

[edited to add: providing a larger set of addons also goes in the direction of simplifying "getting up and running", both for solo artists and in the context of workshops/classes]

maintainability / testability

Is the addon a piece of succinct, stable code? (as opposed to a wrapper for a fast-moving library, or a sprawling "toolkit") -- this has to do with the long term commitment to maintain. ofxFastFboReader comes to mind [tidbit: no later than last week [20230210] in a single line it upgraded an app from wobbly ~40 fps to solid 60 on a M1 Mac mini].

interface design

Does the addon benefit from a normalisation of its interface? I'm thinking for instance about ofxMidiInput, which is not thread-safe (the README instructs about using mutexes in case of crashes; whilst sound, that advice puts one in front of a difficult problem). as an example, ofxOscReceiver is ofThreadChannel'led. Integrating ofxMidi by homogenizing its input pattern with a getNext() loop augments the value of all, both technically and operationally (a single pattern to learn)

[edap]

I think that there are many tools/software/libraries that compete with openFramework out there, and in certain areas maybe OF is not the most advanced solution. But when it comes to computer vision, I think it is still pretty easy to prototype something fast AND robust with OF, due to its integration with openCV. Having the openCV addon shipped with every new version of OF is a guarantee that the openCV functionalities in OF has been tested. I have been using different tools/software in the last years, but if I have to do some computer vision stuff, I usually pick OF because I know it is robust and it works out of the box with openCV. I am wondering if part of this robustness is not going to disappear once the openCV addon has been stripped out from the release.