FR/suggestion: connecting jumpers and forks #237
Comments
|
These are pretty cool, I especially like the concept of wires with J and Y, I'll play around with that idea to see if that's a possibility. In Orca, every non alphanumeric operator is a I/O operator, that means they're platform specific operators that sends or recieves data from/to outside the program. Adding new operations that do not involve I/O means replacing some of the current operators, and I think all of the suggestions can be implemented with a combination of 2 current operators. It's funny to see the fork operator since it was in the first draft of Orca many years ago. Here are some examples demonstrating how to implement forks with orca's operators: Orca typically doesn't write backward, so writing north in the fork example is not recommended. That being said, orca is meant to be customized and remixed so if you want these operators, while they would not find themselves in the main branch of Orca, I can help you implement them in your own version if you need. |
:)
Right, my example writes only east and south.
Thank you for the offer to help! Lone-wolfing it with no hope of merging back is a disheartening at first glance, but it's something to think about.
Right, that was just an example, without a clear idea of what those operators might be in accordance with Orca language design philosophy. Speaking of which, what is it? Seeing the namespace of single-character operators is very tight and already full, the only remaining way to extend is by redefining existing operators or their semantics. At the same time, literally anything is possible in Orca already, it is a complete assembly language. Does it even need extending? What was the original thinking around this hard limit of extensibility? What about 2-character operators? Would extending help or hurt (by adding unnecessary complexity)? I'm asking semi-rhetorically, the design is not documented and is fully known only to the language creators, for me it's a Zen-like experience of discovery. Or is it that we're all discovering that together? :) I think in the end it all comes down to convenience — it is what makes Orca so engaging, the sheer ease of constructing these little machines that do interesting stuff. Some instructions are very powerful (like Some additional actionable ideas that may or may not be new:
I can sense that one of the design principles is not to overthink it and I'm doing the opposite, it's just the concept of Orca language is so interesting it's hard not to. P.S. The above may come off as a bit ungrateful, that was not the intent! The original suggestions stemmed from wanting a little more geometric freedom, but in truth I'm happy using Orca as is, it's already fantastic. Thank you for putting the time and the effort into its development, and especially into dealing with issues like this one. |
You should see the Orca version I use to play shows, it has all sorts of custom things that would not make sense in the master branch, but that I still wanted to have around.
The syntax grew somewhat organically, I created a handful of what I considered the most important operators(cardinals and so on), and people filled in the blanks as we went along. The idea is that space is the most expensive resource in Orca, so everything is 1 letter, if something can be easily re-created with 2 standard operators then it should probably be replaced with something unique. A good way to see the relationship and design of OTQ/XPG(ReadWrite operators) is to look at them like this:
It's meant to be a playground, the 26 operators are just a suggestion in term of specs. Right now I'm implementing Orca on the classic NES, and the core operators are the same, but the I/O operators are all different so they are designed for the platform explicitly. I'd like for someone coming from OrcaJS or OrcaC or OrcaNorns to use Orca6502 and not be totally lost and have to release the core operands. I'd like for Orca to remain simple, and at this point the specs is sort of "freezed" since from trial-n-error we can see that most things can be built simply with the current operators, and it has been a long time since someone presented a breaking pattern issue in the syntax. But where it can be improved is how this can be extended. I'm currently working on a new C version that is a bit more like a collection of UNIX blocks to assemble Orca-like things, so it's even more extensible, but that's still on the drawingboard, I'm not certain where I want to take this just yet. I'd love to help you build this more geometric Orca, geometry is part of the aesthetics I was going for - I did as good a job as I could, but I'm sure it could be improved up even further. :) |
I would actually love to see it. It's one of the branches, I'm assuming?
Thank you for adding the color! I also poked around that mad place and your site and the bigger picture is coming into view, I think I get it now. I admittedly have PTSD from things like working on Bitwig controller scripts and navigating the multiple disjoint forks floating out there in the permanent state of I may take a swing at connecting jumpers, but first I'll need to figure out how to benignly break one of ("an input is just a value", "an output is just a place to write a value") design assumptions, or maybe even "non-alphas are always IO" if I feel sufficiently pirate-like (because An interesting combined operator comes to mind after all this thinking: something that takes the last updated input from any direction and writes it to all other directions. In cases of multiple inputs the last one wins according to evaluation order. A more benign version would take inputs from N or W and write to S and E. Could call them unholy and holy crosses. |
|
I had to dig this out, this is an old version of Orca that had the special characters all over, it was a silly design but it shows where it came from, you should have a look |
|
I think I'm willing to implement the immediate connecting J and Y. I've been messing with these for a few days and it works pretty well with basically no side-effect. |
|
That's awesome news, thank you! |
|
Thank YOU <3 |
Connecting things with
JandYrequires things to be an odd number of cells apart, leaving many simple connections impossible. Wouldn't it be great if jumpers could be connected to themselves?I don't know how well these fit into Orca design philosophy (it seems to be consciously avoiding the concept of wires, which is exactly what these suggestions amount to), but I think it would be awesome to see the following features.
Connecting jumpers
If an input to a (j/y)umper is a (j/y)umper itself, use its value as the input.
..1YY1..Bend and fork
Add bend and fork operators, for example,
\and+.Bend writes north operand eastward:
Being smart about the movers:
Fork writes north operand both eastward and northward:
West-looking versions of these could also be useful for completeness (bending west to north, forking from west). Alternatively, a fork could simply react to being banged and always output
SandEinstead of propagating values.Connecting jumpers could be used to construct a bend, e.g.
.JY., with the expense of more occupied cells (this is also a fork, which could be useful or not). Transforming movers could be done as a special case (if reading input value from another jumper,YtransformsStoEandJtransformsEtoS). A lot of coulds.Instant fire
Add a "shooter" operator to instantly propagate a mover (I know
>ls already bound to tempo, but will use it for illustration).Example: both notes get banged on the next frame:
This one is the most optimistic and least thought through or necessary suggestion of all :) Same could be had with lines of connected
Js andYs, but a "shooter" could also work forWandN.The text was updated successfully, but these errors were encountered: