# Design advice for interchangeable modules of various algorithms?

I’ll explain what I mean by that.

Rambling ahead, sorry. Prefer to err on the side of too much context rather than not enough. Shorter summary of question at the end of the post.

One of my favorite aspects of creating generative art as opposed to more traditional media is that discrete chunks of code are much easier to reproduce and recycle between projects than, say, a specific brushstroke a painter is particularly fond of or a combination of time of day and weather conditions that make for beautiful lighting for a photographer.

To me, it makes the time spent implementing an algorithm (for example, writing code that generates a set of points/values according to specific rules and inputs a la noise) feel much more productive and fulfilling knowing that I can reuse that code in future projects and gradually building a collection of code that exponentially increases the variety of end results I can achieve just by mixing and matching individual modules.

As much as I generally have a “STEM-oriented brain” which has an easier time understanding computer science concepts and principles compared to a lot of my peers (I go to an art school), I am not a computer scientist. Of the ~4-5 separate formal computer science classes I have taken, none of them have gotten more advanced than, at best, exploring basic elements of object-oriented programming including classes and a cursory introduction to interfaces that flew right over my head.

I have recently been getting back into Processing after not touching it for a while because of COVID-related life changes and, after a few short experiments with visualizing strange attractors and systems of parametric equations, I have begun working with flow fields by following an introduction to/tutorial for them by Tyler Hobbs. The quick rundown of the concept is as follows:

1. Generate a set of points in 2D space, I’ll call that set `field`.
2. Assign a value or values, lets call these `contents` to each point in `field`
3. Generate another set of points in 2D space, `starts`
4. Select a point `current` in `starts`, find the nearest (or otherwise corresponding) point `nearest` in `field`
5. Modify `current` (step a certain distance in a certain direction) according to the `contents` of `nearest`
6. Draw a line between the previous value of `current` and the new value of `current`.
7. Return to step 3 and repeat until every point in `starts` has had a turn to reach some terminating condition.

I tried to make that explanation as explicit as I could while still keeping it relatively simple but I’d be hard-pressed to overstate the flexibility of this process. `field` and `starts` can be generated any number of ways. `contents` is usually just a floating point value that represents an angle but at its most abstract it’s simply any type of variable whose value factors into how `current` changes. I could literally go on forever about this but you get the point.

Thanks for getting this far! Sorry the post is so long, brevity was never my strong suit. Here’s where I actually start asking the question because I realize I have to wrap this up ^^".

I want to build a codebase of implementations of various algorithms and processes that I can incorporate modularly across various projects that simply produce an output according to some given inputs and some rule/algorithm. I have begun by separating my first attempt at flow fields into separate discrete classes and I have no doubt that it’s riddled with bad practices and a lot of it doesn’t even make sense because I have yet to reach a final version but I was able to get it to function after more work than it probably should have taken.

The new and “improved” version of my code is also on my github (I’m aware of all the consequences of making this stuff public but I don’t mind) but really I just copy and pasted the code into separate files. Didn’t concern myself with scope or best practices but I want to take a similar approach to, just a few examples, circle/polygon packing, voronoi noise, parametric equations, poisson disc, raycasting, nearest neighbor detection, etc. Obviously these are not going to be super easy to learn and implement on the fly but some confidence that I have even a half-decent approach would go a long way and, quite frankly, I don’t really want to have to go the whole distance of learning everything about software engineering since art is really all I want to do.

I’d like to learn some basic best practices, structural templates, if this is even a sensical use of classes, etc. but particularly as they pertain to Processing. I’ve tried searching for this information on my own but the amount of information I would need to learn to make enough sense of 98% of StackOverflow posts to even know where to start makes my head spin. No harm in asking, right?

TL;DR: What are the best practices for class structure/design and approaches to implementing algorithms in Processing for use in other Processing projects, i.e. modules that don’t have innately visual outputs?

1 Like

`:)`