Recent Changes

  • A: Side-by-side ports design like C and D.
  • B: Replaced for a clock-synced pingpong operator, similar to C and D, now that F fulfilled B old purpose.
  • C: Default value was changed from 10, to 8.
  • D: Default value was changed from 10, to 8.
  • F: Won’t bang if empty. Side-by-side ports design.
  • L: Added rate port, allowing for the loop to go backward.
  • M: Side-by-side ports design too.
  • R: Default value is now 36. Side-by-side ports design.

8 Likes

Does ORCA save a version number with a file? or have you considered adding this? Given these changes are breaking, I could see it making some sense, especially since the code is small enough to do so reasonably as is to ship any past functionality as version dependent functions.

Loving the active development with community feedback! Thanks for making such a great tool

1 Like

We will start versioning now. We’ve wanted to get these changes in before it was too late, but it’s definitely needed now. Hopefully we don’t have to make large changes to the spec again. :slight_smile:

Given some other 100r tools I’ve looked at use other special characters maybe future functionality could also be implemented that way? I haven’t looked at the code though and don’t know how feasible utf8+ is.

Edit: This could be particularity helpful in providing extra variables, depending on what characters are used. The biggest issue I see here is one of added complexity to type. I’m on a laptop right now, hence I didn’t type a lamda or somethnig as an example; however, on my main rig I have an Ergodone with plenty of layers to get any key I want, but I know not every setup supports that- hence a-zA-Z0-9 as is. I don’t know what the right answer is.

A few people were talking about this just this morning on the chatroom. There’s a lot of alternative operators floating around, it might be possible to customize the loadout at some point in the future :slight_smile:

I have my personal custom operators that I don’t think should be in the master, but are fun to use only once in a while, without them taking that expensive namespace.

I wonder if a 3rd typeable layer could be added easily, say making holding alt or ctrl with a key provides a key map in the application, giving this namespace to anyone regardless of the keyboard/layout.

1 Like

It could be easily added, but do we really want that kind of power…

It has a bit of an alienating effect at first for sure, adding yet more complexity to an already complex looking piece of software. I’d argue though that those that would object from the added complexity are also disuaded from using ORCA in the first place. That is, ORCA’s user base and target audience is already willing to use a tool that has an (arguably) steep learning curve to the point I don’t think it’s a bad idea.

Feature creep is a real thing, and I understand it’s pitfalls, but I don’t see this as a destructive addition/change, as it’s not like it’s putting something beneath a pile of drop downs.

EDIT: Maybe make it a twitter/strawpoll vote?

There’s still estate available in the current namespace, there are 2-3 parking operators right now that are mostly unused. Like the B until just yesterday.

Maybe once we have 2-3 killer operators in the queue with the namespace gridlocked, we can add this extra layer. One operator I would like to squeeze into the specs now is the indexOf operator.

  this.name = 'index'
  this.info = 'Outputs the index of the first instance of a character.'

  this.ports.haste.len = { x: -1, y: 0 }
  this.ports.haste.key = { x: -2, y: 0 }
  this.ports.output = { x: 0, y: 1 }

  this.haste = function () {
    const len = this.listen(this.ports.haste.len, true, 1, 36)
    for (let x = 1; x <= len; x++) {
      orca.lock(this.x + x, this.y)
    }
  }

  this.run = function () {
    const len = this.listen(this.ports.haste.len, true, 1, 36)
    const key = this.listen(this.ports.haste.key)
    const a = []
    for (let x = 1; x <= len; x++) {
      a.push(orca.glyphAt(this.x + x, this.y))
    }
    const index = a.join('').indexOf(key)
    const res = key !== '.' && index > -1 ? orca.keyOf(index) : '.'
    this.output(`${res}`)
  }

Just took a look at the source code, and noticed how modular it is (So nice to not see crappy code for once…) that it brings up the idea of community supported operators, similar to VCV’s plugins, making a drag-and-drop install a new operator? That would mean the base install could be kept minimal and plenty of namespace would immediately be available to the community around ORCA. Obviously this comes with other questions about the direction or ORCA tho

3 Likes

Or maybe an ORCA fork with arbitrary layer count… we’re going to need a new pathfinding helper function to carry those bangs around a patch.
image

1 Like

I don’t really wanna see (much less maintain) a fork. I can only imagine the mess if core operators functions change and patches are floating around that depend on one fork or another. I’m already concerned about this compatibility breakage resulting in old, broken files floating around causing users to give up. Ideally the examples folder will prevent this, and as @neauoire said, this was done “before it’s too late”

2 Likes

Sorry if this is a common question… I’m not too familiar with node-based stuff. When I npm install Orca, I’m getting a “high severity vulnerability” reported with the version of tar it depends on. Anyone know how to update the dependencies to a version that doesn’t the bug?

I hadn’t noticed this report, pull again and npm install should now be safe! Thank you.

1 Like

@Allieway_Audio We weren’t sure if it could be done!
But someone has cracked it. Behold, self-replicating composition.

Credit goes to @nobodycarestrue.

:partying_face:

28 Likes

so, off topic (on topic) question. Is it ORCA, orca, Orca, or ORCΛ?

Seems like it might be beneficial to settle on some formatting, and also standardizing a different formatting may help differentiate between the Orca alternative firmware for White Whale and this live coding tool. That is, unless the desired formatting is Orca.

not affiliated with the project but afaik ORCΛ; however, typing the Λ can be a pain, so I think ORCA is equally valid. orca and Orca could be ‘reserved’ by said White Whale interface, but realistically context should be more than enough to differentiate between the two, so I’m not sure it matters?

I like the Λ; there’s a “nowness” to it (and the tool) which is incredibly refreshing.

It’s a super small thing (and more traditional spellings should continue to be supported), but these narratives matter.

1 Like

oh 100% agreed. I use a lot of special characters when on my desktop with my Ergodone keyboard which has any key I could want, but if just talking about the cool typing it each time can be annoying- it’s a branding thing, I completely agree ORCΛ is better, but when just discussing it there’s a point where going out of the way to type it can be exhausting

1 Like

now this is a grey goo i can get into