Odd. It seems like having a bang underneath X freezes that row momentarily. Don’t know if it’s supposed to act like that or not.

I just tried a few variations, and in this example it’s clear. If you change the lower D-operator (1D1) to a faster value like 1D2 it becomes active. But as long as there’s a bang underneath the X it holds the E in place:

......D..
......*H.
.1D130xE.
..*Y*Y*..

So in your example you would have to jump the * down another row with J and Ys to get the bottom E to sync up.

More livecoding fun!

2 Likes

How do I get it to bang instead?

O’s input port is locking, you need to clone the cardinal with something like:

..27O...
.....FE.
........
D.H.....
.xE.....
.....E..
.......J
2 Likes

Wonder if anyone can recommend a good way to write to multiple locations without using variables.

Try this:

...H
D..E
.Y.j
J...
.Y.j
J...
.Y.j
J...
.Y.j
1 Like

i’ve seen that conveyor belt video before but after some time with the program now it is super head explode. sampling with the Js…chef’s kiss!

2 Likes

Interesting! Thanks for noticing that. Indeed, a bang under x bangs it one frame late, feels like a bug.

..........
......H...
.D.30xE...
.*Y*Y*J...
.J.30xE...
.*......E.
..........

..........
......H...
.D.30xE...
..Y.Y.J.E.
.J.30xE...
.........E
..........

Nice!

1 Like

That’s a really cool way of using J, thanks!
It’s a fairly bit more complicated solution than I imagined though, needing to use both F and J uses another three rows per W I want to send off… I’ll sleep on this and will try to make it a bit smaller vertically tomorrow :—)

Also, how does this example work? Here, the Ws simply seem to bang when reaching the read location…

been experimenting with orca on a Percussa SSP :slight_smile:

seems to work really nicely… as the ssp display is a good fit for the grid.
this is just built for ssp, and running on console (so ncurses?) as a test, but not really suitable for what I want…
so, now wondering if I can integrate this someway into a vst and add new operators too it. has anyone looked into this, or generally created a orca-c version with a new UI.
Ive had a quick look, and cli_main.c seems like a good place to start, as its fairly straightforward… and so then from there its a matter of rendering and filling the grid.
(not really sussed diff between the mark and glyph bufs yet… but sure i can grok that :slight_smile: )

7 Likes

Well, the real “solution” to do what you’re trying to do is this, but that’s a lot less exciting :wink:

..................4U9
................2I8.H
.................41gW
0........W...W.......
.:03F.W..............
0.W...W...........W..
.:03g.W..............
0..........W...W.....
.:03a.W..............
0*..W................
.:04d.W..............

The video you shared is from an older version of Orca where O and X ports were not locking. That was corrected in a later version. Every port to the right of an operator in orca is locking.

..D...D....
...H...H...
6.xS5.xS...
...........
........S..
..........O

Interesting! Thanks for noticing that. Indeed, a bang under x bangs it one frame late, feels like a bug.

It’s not a bug, Orca operates from top left to bottom right, a bang coming from after an operator will run that operator on the follow frame, a good way to explore this is by creating echoes with the O operator.

Thanks for explaining, that makes sense!

I see. I only concluded that because from the documentation the relationship between bangs and operators is unclear beyond “* bangs neighboring operands”. The “* bangs backwards on next frame” part was not immediately obvious.

I understand the evaluation order, it’s just not clear how that translates to the banging behavior. Conceptually, whose job is it to do the banging and how does it really work? I’m guessing it’s not the * that looks for nearby operators and evaluates them immediately, I see that all * does is erase itself. Does it defer the erasing until the end of current frame evaluation? Is it then the operator that looks for nearby bangs?

More interestingly, why does the right construct produce an E but not the left one?

..............
...*H......H..
.20xE...20xE..
..........*...
..............
<one frame later>
..............
....H......H..
.20xE...20xE..
............E.
..............

and why doesn’t this bang disappear?

..........
..D.......
...Y.Y.H..
..J.20x*..
...Y.Y..*.
..........

Is there a reason lowercase operators are not colored as operators?

I would guess the bang that refuses to disappear is being written each frame because the other bang being held there by the H is banging the lowercase x and writing it.

1 Like

It’s the operator that look for a bang, so if the bang doesn’t exist during the frame when the operator looks for one, then it gives the impressions that there’s a 1 frame delay. The bang doesn’t wait for the end of the frame, Orca is a very simple VM, I didn’t try to do anything fancy or unpredictable.

More interestingly, why does the right construct produce an E but not the left one?

Because the bang dies(erases itself) before the X has time to see it.

why doesn’t this bang disappear?

Because the X sees a bang to its right that doesn’t die, so it keeps on spawning a new * on every frame.

...H
22x*

For example, the previous snippet bangs on every frame.

Is there a reason lowercase operators are not colored as operators?

Because they are inert, they are not technically operators, as in they do not operate until a bang happens and turn them into operators.

2 Likes

Thanks! Now it makes sense, mostly. Is this accurate?

  • *-producing operators “hold” the bang in place long enough for other operators to “see” it
  • what an operator “sees” also depends on evaluation order (otherwise it should be able to see all the neighboring bangs within the same frame)

The part that’s confusing is that a bang after an operator is existing in the current frame and has not had time to erase itself while the operator is evaluating. Yet it bangs on the next frame, after the previous frame is finished and the bang is gone.

(smacks forehead) Operands can bang their operators — forgot about that and surprised by it again. What was the reason behind that design decision? Because IMHO it is a rather odd one, not seeing a use case for it. Rather, every time I run into this I wish operands were just operands, inert and waiting to be operated on (e.g. I’d like to be able to write a bang phrase like .4T*.*.).

But they’re special in that they will operate when banged, would be helpful to be able to visually identify them where possible.

1 Like

Is this accurate?

Yes, that’s a very good way to look at it. A lot of things that might feel like design decisions are actually side-effects that comes down from the system’s rules. The reason why the X bang when a * is in the input port, or why the O’s input is locking - they get this way from the system’s rules, like All right-side input ports are locking, that will affect the way the operators work, but there was a design decision that specifically targetted the operator itself.

The part that’s confusing is that a bang after an operator is existing in the current frame and has not had time to erase itself while the operator is evaluating. Yet it bangs on the next frame, after the previous frame is finished and the bang is gone.

It erases itself on its next evaluation so it will exist when the operator above sees it. I’ve been working on a super simple Orca VM implementation right now, designed to kind of explore and debug each frame. That should help :slight_smile:

But they’re special in that they will operate when banged, would be helpful to be able to visually identify them where possible.

They should look muted, or grayed out in the default orca theme. How do you think they should look?

1 Like

Erm yeah ok what‽ :ping_pong:

4 Likes

That’s a great explanation. Orca is in fact a living art piece and I do enjoy it as such, but sometimes I also want to make music with it as a tool and the two natures can be in conflict.

I like emergent properties as much as the next agent-based modelling guy, but we also know they’re not always evolutionary beneficial. If you’re saying this “banged by own operand” behavior is solely an emergent trait and no one specifically wanted this, then it’s worth to either question the rules or handle an exception.

Looking forward to that VM!

Also, I feel stupid asking this, but what does it mean for ports to be locking?

Look muted they do, that’s why I cannot see them. I think they should look somewhere between regular operators and operands in relative brightness, highlighted with the operator color (but no inverse) would work, a different color would be fine too.

But how do you catch that? There’s no sense of self who has made the bang. What you mean is instead is, bangs in input ports should be skipped when an operator is looking for a bang? Is that what you have in mind, because this comes with a lot of repercussions.

I just means it stops an operator from operating, for examplem like the H operator is just a single locking output port.