# Self-reference and Alternatives to Blue Boxes

Hi,

I’m testing out a new implementation of sequences of neoriemannian PLR operations in OM. I already made the single operations, but in my previous implementation I was only able to compute sequences of such operations through self-referential blue boxes and dense,careful wiring. Here’s my question: are there any alternatives to blue boxes in order to achieve operations that compute (a finite sequence of) their own results? I was able to find a solution for a recent implementation of sequences of Tymoczko’s t and T transforms, but it all relied on hacking through their algebraic properties with `dx->x`. It wouldn’t work on PLR operations.

Any hints or insights on this issue would be much appreciated.

All the best,
António

Dear Antonio,

Your post is somehow obscure. Not everybody knows how to deal with neoriemanian “entities”

Can you break up your question into a “simpler” one? What about the blue patch issue?
Is it just a patch? is it recursive?

Best
K

Hi Karim,

Sorry about that. PLR operations are just the operations over the chord on a tonnetz. Yeah, I meant a recursive patch which calls on its own previous result (chord) in order to do the next P/L/R operation in a sequence. Just in case, here’s my previous implementation of a PLR sequencer with blue boxes:
plr-transform-chord.omp (111.1 KB)
plr-transform-seq.omp (124.2 KB)
plr-transform-suite.omp (5.2 KB)

`plr-transform-suite` is the full implementation of the PLR sequencer.

All the best,
António

PS: the way it works is quite simple. We only need to attach a triad like `((6400 6700 7100))` on the left inlet and a list of `0`s, `1`s and `2`s like `(0 1 (1 2))` on the right inlet (`0` stands for P, `1` L, `2` R.)

Hi Antonio!

Did you try omloop’s “accum” accumulator?

1 Like

Hi Anders,

Nah, I had never used `accum` before. Thank you so much, that nailed it.

All the best,
António