Github repository for patterns

Ideas and Tips
1

I just found myself fixing an array issue in a pattern I downloaded previously. The coder side of my brain wants to push that fix out to the rest of us as my virtual paying it forward.

So the thought/idea is to move/copy (existing patterns) and/or make a new github repo where we can submit new patterns, and subsequent improvements.

Could have some guidelines around only fixing/improving someone else’s pattern. Lest one should be creating their own. Throw in some folders for Test patterns / 1D / 2D / 3D / Sound / Other and the community can self manage their efforts for the most part. Sans some government over pull requests.

Bonus round: a PB could connect directly for finding new patterns (and possibly getting updates)

2 Likes
2

Yes, work on the pattern site has been coming up more lately! We’ve discussed it on the forum before, just hasn’t been top of the list yet.

The shipping patterns are here

@jeff was instrumental in cleaning up and curating the wonderful default pattern set, and has opened his repo for PRs.

If there’s an update to the patter site’s pattern I can do that, just shoot me an email with the .epe file to wizard@electromage.com

Eventually I want the pattern site backed by git. The pattern site repo will take a slightly different structure. Here’s what I had in mind:

Some background in this (long) thread

1 Like
3

Of course there are others out there already having the same idea and way ahead of me! Love this community!

2 Likes
4

[=opinionated=]

hi all!

yes. it aught be a repo.

it aught have branches or subdirs for maturity

the pr process aught be well defined

the PB web ui /api aught pull from the repo to get a list.
the repo should be configurable within pb (so one could host their own should they wish.

there aught be a way to identify pattern features ie 2d/3d/inputs/ (multi-pb-enabled pattern? reactive/environmentally responsive pattern?)

pattern authors

version authors

pattern flavors… ie how dynamic is it, across what axis? what kind of movement it facilitates, etc

applicability for a given use case (similar to tags below, could be tags, don’t really care, so long as there’s a consistent way of identifying them)

upstream pattern tags / badges (ie in-repo)

local tags/badges (ie on pbdevice)

some metric of complexity/difficulty ie: slope of max framerate as pixels increase

some measurement/indication of current best practices applied so one knows if this is a messy hack or an exemplar to replicate

ideally there’d also be automation to ensure all patterns load run exit properly etc so that auto downloading is possible.

users should be able to retain local/current version(s) of someSpecificPattern if they want, while updating the rest…… this could mean a ui knob to specify how to handle pattern updates (automatically overwrite, selective retention, selective updating, auto update (patch, minor, major) versions, manual updating/OCD mode) or something else

some mechanism of collecting rating might be neat

some mechanism of quantifying #s of pb’s using this version of this pattern…
( if every pattern is in its own directory, then the name-ver-git_hash_for_pattern_dir would prolly work as a unique-but-consistent id seed …. could hash that and prefix programmatically to avoid complications arising from weird names or hash collisions from other versions/files…… this would potentially give us a stable pattern identifier to uniquely identify this released version of this released pattern )

¯_(ツ)_/¯. i did say i had opinions :slight_smile: i didn’t say they were any good tho

4 Likes