Openrndr 'vanilla'?

[same message sent to processing forum, someone suggested coming here :slight_smile: ]

Hi everyone! Questions from a probably-be openrndr user, hope someone might point me towards docs, info, exchanges etc.

I’m involved with keeping a repertory of old pieces for live-electronics audio+video alive. Typically they’re laid out in software like SuperCollider, Max/MSP, Tom Demeyers Image/ine and Gem software for live-el video.

An important aim is to get rid of as much as possible of hard/software dependencies, esp. proprietary stuff. Hopefully this will be an once-and-for-all job, where a chosen solution will last for a long time.

In the audio world, Pure-data vanilla, together with Miller Puckette and others 'pdrp-project: pdrp project addresses these issues explicitly, and already gets a long way towards minimizing such problems. Some aims: minimizing difficult-to-maintain deps. (maintainance-stop of 3rd-pary libs, core developers changing job…), setting up a comprehensive test-suite to check new builds, and others.

Are similar considerations are part of the openrndr development, if there are development branches focusing specially on such issues etc. Any pointers to discussions etc., or perhaps other forums where such issues may be more relevant, are much welcomed.

Thanks!

OPENRNDR programs are usually written against specific versions of the OR libraries. These versions are specified in the programs Gradle file (the de facto build tool for Kotlin).

OR’s releases are tagged in git (hosted on Github), so finding the source for a specific OR release is easy. We also maintain a version matrix to keep track of internal library compatibilities.

OR itself depends on libraries in the same way, with unambiguous library identifiers and version numbers. OR depends on libraries that are retrieved from the Maven Central repository. Maven Central appears to be reliable and to be around for a while.

One of OR’s development goals is to be very easy to build. Which means that you should be able to pull from our main branch and build it with either the Gradle CLI tooling or from the IntelliJ IDEA IDE. Manually chasing dependencies is absolutely out of the question as dependencies are pulled in from Maven Central.

Now the unfortunate part: OR itself is not on Maven Central (yet) and the service that currently hosts our libraries (Bintray) announced they will abandon their service by May this year. We are working to publish all prior released libraries on Maven Central to provide the best in terms of longevity we realistically can.

We strongly depend on LWJGL and JavaCPP and have no plans prepared to anticipate for a scenario in which either of the two would be abandoned. (I hope I don’t jinx anything here).

There is one big versioning hole in our documentation efforts though. Getting documentation that fits earlier versions of OR may be tricky.

Happy to answer your questions and advice

Learning by the minute! Thanks for clarifying some important issues related to OR and forward compatibility.

To be clear, i have no reason to beleive OR will not deliver vs. compatibility issues. But i’d be very interested in refs to discussions, standards, test suites etc. addressing such issues.

Open Source, version control, broad user base - seem pertinent towards future compatibility.
However, there are examples of broadly used software-projects which for various reasons die after some years.

Stand-alones loaded into hardware, or alternatives such as storing vintage hard/software, running old OS’es and libs in VMs etc, may do some good, but seem to me to be fragile solutions in the long run.

-anders