Feature Idea: Handling increased complexity through multidimensionality / portals

[eethann]

Thinking about how something like subroutines / sub-patches etc. could be implemented in Orca I thought that supporting some sort of dimensionality could be a route to this. This could be either through lines of intersection or "portals":

• intersecting planes: key combo would "rotate" the current row you are on. The row from the parent would become the top row in the descendant plane. This would not be truly "3d" in that you could not intersect with the parent plan again after 3 rotations. I think that would be too hard to keep a mental model of. Further, descendants would not transmit triggers between themselves, each is still a self-contained 2d space. But descendants and parents could communicate through their one shared row.

• portals: instead of lines of intersection, a new operator could be used for a portal. A portal is a new plane that starts with only the portal operator in the center. The portal operator takes a length parameter, and copies an input of that length to the alternate dimension. The portal jumps the cell above it into the space below it in both the parent plane and the alternate dimension plane.

I'm curious your thoughts on either of these. As I write them the portal seems most easy to reason about and work with. I suspect you've thought of these and similar before, but thought to propose them just in case.

Thanks!

[eethann]

Updated portal operator proposal.

\: dive(length,name,inputs): passes top input and eastward string of length length to another plane, identified by name.

This would allow for easy re-use of some planes, and could also have some interesting explorations if the state of a plane is changed over the course of a frame. E.g. planes would be evaluated in full each time a dive operator is encountered, following the standard evaluation direction.

[eethann]

Complementary operator:

/: surface(offset,length,inputs) update the state of the dive operator in the surface plane. Northward input to surface is emitted south of the parent dive, westward input of length length is copied to the input string of dive in the parent plane.

I'll try to sketch an example.

Surface Plane:

..*..
2a\C1
.....

Plane a (the dive operator in a lower plane copies the inputs from the dive operator in the surface plan):

\xy..
*11QE
.12/E

Would update the surface plane to:

.....
2a\CE
.....

In essense: \ is the input to the subroutine, / is the output.

Does that make any sense?

PS. pardon all the surface/dive/etc., couldn't resist.

[neauoire]

This is a fun idea, there's an old commit in which I had implement it, it was called rooms operator. It's fun, but it raises the complexity of the implementation and fileformat too much, so I took it out. It was also obfuscating some of the running code making it less interesting for livecoding shows where people can't really see what is happening in these different layers.

That being said, I suggest you try both implementation in your orca fork :) I found that /roomname where roomname is a separate orca file that runs in sync with the master file, the dive plane idea is hard to use because the steps in there are triggering on transfer.

In these extra rooms, I had 2 inputs and one output, the room exists only for the length of a frame, so everything has to use Y/J operators. It allows to create custom opcodes from the orca primitives. I never found a good way to create custom ports on the fly, I'd love to see your experiments with that :)