Sorry for the noob question, I’m new to ORCA. I see tutorials where they enter chars to be treated as letters rather then operators (e.g. “D”). I thought Ctrl+I was meant for this but, at least on Windows 10, this shortcut doesn’t seem to do that (apparently it doesn’t do anything).

well sometimes operators want letter input, sometimes numbers, sometimes both and to make it more confusing, lowercase letters act as conditional operators when banged but look as if they’re not doing anything when they aren’t. but capital letters are operators and need no special command or ctrl key action.

see the base 36 table for input values.

1 Like

ctrl+i is for insert mode, that should let you type in a series of letters.
If you just want to make inhert letters, write them within #, like # INACTIVE #.

Letters to the right and under of an operators are locked.
For example, 03TCAFE CAFE are locked since they are to the right of the T operator.

1 Like

ooooh that’s why you can’t capitalize that left field for R.

1 Like

Regards to all!
I just want to share my first jam in Orca & Pilot & Cassetter:

Bye :slight_smile:

6 Likes

Firstly I just want to say that after following curiously for a few months I’ve recently started using Orca regularly and its just awesome. Seriously one of the coolest bits of software I’ve used in some time.

I’m interested in following the development of Orca-toy and I can get it up and running, but have to make adjustments to avoid compile errors on macOS (not sure if the same happens on other OS’s) which is fine, but gets a bit tedious when I have to do it each time I pull the latest changeset :sweat_smile:

Just wondering if you’re seeing the errors I’m seeing (& if so how to avoid them?). Its all due to conflicting type definitions: random, move, setmode & select and gives an error like this:

orca.c:223:1: error: conflicting types for 'random'
random(Grid *g)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/stdlib.h:228:7: note:
      previous declaration is here
long     random(void) __swift_unavailable("Use arc4random instead.");
         ^
orca.c:533:36: error: too many arguments to function call, expected 0, have 1
        setport(g, x, y + 1, cchr((random(g) % ((cb36(max_) - min_) || 1)) + min_, ciuc(max)));

Inspecting that output it looks like random is already defined in stdlib.h (at least in the MacOSX10.14.sdk). For now my solution is just to add an _o to the end of the conflicting function defs

Maybe its just a case of forcing xcode / clang to use a specific (older) SDK without those definitions, but I haven’t figured out a way to do that

1 Like

Oh! I will rename it! I’m not seeing this on OSX, you can just remove it for now, the R operator is the only only operator I haven’t implemented yet.

Edit: @mdh: I’ve pushed an update that implemented the R operator and should fix the OSX error :slight_smile:

https://git.sr.ht/~rabbits/orca-toy

4 Likes

Hey Hey! new to the forum, I looked around and searched to see if an answer already existed but i didn’t see much. My question is about a eurorack module and Orca on raspberry-pi. Orca on MacOS recognized this plug and play MIDI-to-CV module but Orca on Pi does not respond when the module is connected. I have PortMIDI installed, but is there some other library that can recognize random MIDI devices? My ORCA-PI automatically recognized my Behringer Neutron but is not responding to 2HP MIDI.

Read up on the aconnect command (from the command line)

You probably just need to route the midi devices to each other (in the system software - using aconnect).

1 Like

After a quick glance, this looks like it could be promising. Thanks a ton!

1 Like

Two newb questions after watching some example videos.

I see the D operator being used with a midi control change. In the video I see D1. If I use D1 it kills the operator. If I use D2 or leave the numeral blank it works. It does the same thing with a midi note. Has this behavior been changed since the making of the video?

In the same video I see “. B z” producing a changing value to modulate the third midi control change value. But B always produces a fixed value for me. There is nothing above or near the B to explain the changing value. I’m thinking I must be missing some fundamental aspect of Orca that isn’t mentioned in the newbie videos.

the way that B is changing in this video is mysterious to me too. if there was some sort of variable changing on the ‘a’ input I would understand but the way that it’s behaving here seems more like the R operator below it.

I’m not sure what you mean by kill the operator?

Ah yes, that’s an old video, before, the B operator contained a clock, you can replicate this same behavior now with:

C..
1B4

Where the second port of B is half the length of the clock.

What I meant by kills the operator is the “!” or the “:” turn grey and the midi stops sending if you put a 1 after the “D”. You can put another integer there, but a 1 kills it. I presume this is because having a 1 there is the same as having nothing there? But in the video this seems to be allowed behavior.

I had already added the clock to B. I was looking for a reason why I had to :wink:

can you take a picture or video of your patch? .D1 should give you a midi note on every click, it basically just holds the gate open.

Here’s what D1 does for me, it plays a note every frame:

1 Like

I looked at the midi channel in VCV Rack. With D1 you get a constant stream of gates (clicks), and a very unpredictable occasional heard note. Making it essentially useless. I just don’t know if this is the expected behavior or not. Looking at it in Orca it’s definitely hard to see what is actually going on. And my screen definitely looks nothing like the one in the video I’m watching. He is using D1 with a midi control change, and his “!” remains lit up (highlighted). On mine the “!” dims as if nothing is happening. The same way “:” does. There is a clear reaction if you add the “1” after the D, different from any other integer. And the midi operators don’t go dim until you have a midi channel, octave and note.

Hi friends - been playing around with Orca and just wanted to share a cool construct.

I wanted to create an oscillating clock (e.g. 0 to z back to 0 and so on), but it looks like the suggested approach is to now use the following construct:

Cy.
1Bh

However, the largest period we can get from this is only 2*h ticks, because the second operand of B has to be half our clock:

Here’s what I came up with instead:

.25O.....
...00O0z.
....Z0B..
....0F0..
.....*i2.
......1..

Despite its messiness, I’m quite proud of this iteration as my previous attempts at such a clock broke if you tried to change the range halfway through the period, but this one seems pretty solid. It works by comparing Z's output to its target such that when the two are equal, we switch Z's target to the next endpoint of our oscillation.

The above snippet oscillates within [0,z], but we can specify the lower-bound too, e.g. the following would oscillate within [2,7].

...00O27.

You can get pretty crazy and form some elaborate oscillations by changing the pattern length too. The following goes from 2 to a, down to 7, up to g, and back down to 2:

.25O.......
...00O2a7g.
....Z0B....
....1F0....
......i4...
......0....

Orca is really cool and I’m having a lot of fun with it. Thanks for this awesome language!

6 Likes

One way I like to do this is:

4 Likes

Orca has been basically everything I wanted in a generative sequencer, but I found myself wanting to create longer song arcs w/o live-coding.

One way of injecting potentially a ton of variation into patches without having to live-edit might be dynamic commenting. I initially struggled a lot moving #s around, so I thought I’d share just a few constructions to dynamically mute/unmute channels, a common performance gesture.

(These examples flip every couple frames, but of course could be extended to cue after arbitrarily long times!)

3 Likes