Future compatibility, processing vanilla

Hi everyone! Questions from a new processing user, hope someone might point me towards docs, info etc.

I’m involved with keeping some old pieces for live-electronics audio+video alive. Typically they’re laid out in software like Max/MSP, Tom Demeyers Image/ine software or similar.

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.

My question is whether similar considerations are part of the processing 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!

1 Like

My question is whether similar considerations are part of the processing development

By “similar considerations”, are you referring to removing proprietary dependencies? AFAIK everything Processing uses is open source.

1 Like

And you can download any version ever released form GitHub.

1 Like

Yes, guess OpenSource is most important towards future compatibility. However, lots of FLOSS-ware die, even after years of widespread use. Issues might be relying heavily on a few core developers, employees doing dev as part of their job, 3rd-party libraries etc.

Possibly there’s a trade-off between convenience now, and reliability in the long run?

Is there a test suite set up and maintained anywhere to check new releases towards old stuff?

On the processing 4 GitHub repository, there’s no CI/CD actions and it doesn’t seem to have some unit tests, maybe a feature to add!