#1303

@unthankable

What you mean by VM is what I call a client, a way to interface with the interpreter(server). I don’t have a clear roadmap, but this is kind of where I’m going:

  • Build a strong orca benchmark file, and test the current implementations of the alphanumeric operators against it.
  • Complete the super simple frame interpreter, so this little server spits out the next frame and the associated IO messages.
  • Build a small SDL client that handles syntax highlight, input, timing talking to the interpreter(server).
  • Use this for my next livecoding gig.

The orca alphabetic operators should be the “spec” and not change from one implementation to the next, anything that would fail the benchmarks is not orca compatible, and that’s fine, there can be other versions too if someone doesn’t like one operator or another.

Typically, if someone finds a problem with the 26 core operators, they’ll raise an issue on here, but that hardly ever happens. Typically, it’s people who misunderstand their usage.

While the letters are interpreted normally, the special characters(IO operators) should each send their values across so the client can handle the messages as they like.

For example, the C89 server outputs the messages in a separate buffer, so something like :03C3. is not interpreted but instead sent to the IO buffer so the client can have access to it and choose to do whatever is needed with that.

Modules, IO, etc should be done with special characters. So for instance, my 6502 implementation doesn’t use any of the midi/osc operators, since their usage is different and specific for the NES platform.

3 Likes
#1304

Interesting! I admit to not fully understanding the intended use case (is it to perform on NES?), but I see that we’re talking about the same concept and goal of separating the interpreter, albeit somewhat inverted and different. My pitch was a solid Orca “platform” that opens up the language spec while taking care of the low level basics, and in your case that platform is the client and the server could be swappable. It is a different grouping of components, (grid model, lang)+(UI, IO, clock) vs (grid model, IO, UI, clock)+(lang).

At first glance having a compiled “spec” on a server makes it less hackable/portable than I was imagining, but at the same time this could be flexible in other interesting ways. Are server and client separate processes communicating over network or is it all one runtime?

I’m okay with being atypical. There is no problem with the operators per se, it’s rather that the current Orca language spec is just one of the possible Orca-like languages with that exact paradigm. This is more about the freedom to explore them experimentally without the friction of worrying about compatibility (of both the language and the platform) or the implementation details of the VM — that’s my use case. Adding multiple implementations could also include prior versions of the language, big help for those with older compositions.

I think what I’m describing is fairly feasible with Electron Orca by having a map of swappable library modules.

1 Like
#1305

Hi. I’m the person who implemented the C version of Orca.

It’s already built as a separated VM, and meant to be easily hackable. The frontend and VM behavior are already separated, to a reasonable extent. If you want to change the way the language works, you can edit sim.c, which has all of the definitions for the opcodes in it, with each one in a separate block, carefully designed to be hackable. (I hope.)

If you want to change the existing livecoding IDE, you can edit tui_main.c. (There are also some helper files with it.)

If you want to make a new frontend, it’s straightforward. Someone has already done it – there is a Plan 9 frontend for Orca that lives alongside the TTY TUI frontend. The TTY TUI frontend is the livecoding IDE that you normally use with the C version of Orca.

If you think you’re unable to do something or something seems harder than it should be with regards to changing the C implementation of Orca, please let me know! I tried pretty hard to make it hackable. If you find some defect, I’ll try to fix it. Or maybe I should write a guide?

The existing implementation already works like this.

edit: I have been informed the neauoire’s version won’t be exactly the same with the VM IO buffers :slight_smile: looking forward to it…

7 Likes
#1306

I’m wondering how the MIDI Input Device can be used?

I’ve seen in threads that ORCA can’t easily receive a MIDI clock, nor can I figure out how to get any note info from my controller. I’d like to use ORCA to generatively respond to notes played on a MIDI controller. I understand if ORCA is a sequencer meant to be manually programmed and meant to serve as the “brain”, but then I’m wondering what the MIDI Input Device selection is for.

I’m brand new to this program, so I appreciate any MIDI guidance! I’m enamored with it otherwise.

#1307

Its main use is to capture the midi clock.

I use the midi in implementation to run two custom operators that prints the key I’m pressing on the midi keyboard, or the value of the knob I’m turning. The implementation is there so anyone can use it to build custom things if they need to and don’t want to use UDP.

#1308

Hi! :slight_smile:

Nope, I really don’t! That was the whole point of trusting someone much more capable than myself to maintain a working frontend while someone like myself hacks away at the language.

Haven’t spent any meaningful time with orca-c yet. The concept and the feel are attractive, but a JS interpreter just seems more conducive to dynamically swapping interpreter libraries and debugging. Maybe once new language versions are discovered they can then be ported to orca-c.

#1309

Thanks! Are those custom operators printing MIDI info in ORCA, or are you talking about implementations outside the program? How do you capture input MIDI clock or note info inside ORCA? I was hoping to use : in reverse

#1310

Wanted to highlight an idea behind my last few posts: modularity and making the language part of a composition.

For example, in SuperCollider I can define new functions. This effectively extends or replaces some parts of the standard library, but it’s still a part of my composition and is distributable as such. What’s more, I don’t have to deeply understand how the underlying library does its thing. I can define a whole new DSL just for that one composition and it will play the same on pretty much any other SC instance.

In contrast, Orca doesn’t really have a user-facing language component, there is the Orca language baked into the implementation. The concept of an interactive text buffer as a livecoding interface is fantastic in itself, I’ve dreamt of something like that for years. The current language is very effective at expressing many constructs and compositional ideas, but there are others that are less achievable due to inherent language limitations. It’s hard to make a small language with the right balance of constraints for all possible cases.

The implementation is hackable and that’s great, though it seems most people opt for a “compiled app”. The experimental nature of Orca manifests itself quite differently in different domains, experimenting within a composition is very much not the same as meddling with the implementation, of which the language is an integral part.

This disparity between free composition and fixed language yields a single consensus-driven language and time spent on cordial arguments why something should or shouldn’t be implemented. Why not instead treat the language as an extendable nonsingular object and allow one of several to be chosen per composition? For example, maybe you want to make something without NWSE and now you have 4 free operators to redefine, or maybe you like the old behavior of L, or maybe a time-based Z, etc…

Orca could come with a canonical language loaded by default and a set of altered languages loadable via a command. An .orca file could be accompanied by a library.js file (this is where JS gets a plus for being an interpreted language). Language selection could be automated by preprocessing #! commands when reading a file.

Just laying some groundwork while contemplating a PR. :slight_smile:

#1311

sometimes limitations are a good thing.

2 Likes
#1312

I often have volume problems with Linux. You could try using SunVox as a software MIDI device rather than Pilot and see if the problem persists.

#1313

No real manual. I would look at the main Orca site for an “examples folder”. The “basics” folder in examples contains definitions of each command. I have created definitions for letters that are missing and added minimal documentation. Here it is : https://drive.google.com/file/d/1fOvnSzq4QlMiZmofCYZt9LDOfo69_KXV/view?usp=sharing

2 Likes
#1314

Moved from contemplating to prototyping: https://github.com/hundredrabbits/Orca/pull/248 :boom:

Comments, critique and testdrivings welcome. No alternative languages yet, planning to do that next.

1 Like
#1315

I’d defintely check out the Polyend Poly 2

#1316

Added a couple of loadable libraries to my branch and PR, sbz with duration-based Z and… orca157, the pre-BFL Orca! :wink:

I don’t have any .orca files using old B/F/L operators to test that with. If you do, you could test it by loading your file and either CmdOrAlt-K or $ this command: lang:orca157 (and then lang:default to get the original Orca back).

#1317

Hello,

Having some issues connecting to VCV Rack and Logic Pro from Orca.

Looks amazing but when how do I set up midi if I am using a virtual instrument IE VCV Rack and Logic?

I know [command .] cycles through selection but im getting nothing?

Do you need to create a virtual midi channel? If so how would you recommend for mac?

Thanks again in advance!

#1318

These instructions are for/from Ableton, but they should get you most of the way there https://help.ableton.com/hc/en-us/articles/209774225-How-to-setup-a-virtual-MIDI-bus

2 Likes
#1319

Orca Update!

There hasn’t been a change of behavior in a long long time, but this is to standardize the behavior of cardinals between OrcaC and OrcaJS. The new builds available on Itchio will also now include the Midi Clock sync from @unthankable!

324298af0b928e05
324298af0b928e05540×720 65.6 KB

Before this update, a colliding W and E would most likely go through each other, but from now on, they will create a bang:

This will create a chain-reaction effect when two cardinals are following each other closely:

This was already the behavior of OrcaC, but it is now also the behavior of OrcaJS.

Orca x Sunvox

18 Likes
#1320

welcome aboard @cancel!

4 Likes
#1321

I love Orca - getting the kids into it!

2 Likes
#1322

Great news! :slight_smile: