I’ll check midi in (i was sure that handled by beatclock lib itself).
You can hold shift+arrow for fast scroll to the bottom

Did some testing… Beatclock was not getting passed the midi data so it was not handling clock.

I was also seeing a nil table error on orca.vars.midi[m.ch] = m.note so I made the following changes.

This works with external clock OK

  orca.midi_out_device.event = function(data)
    local m = midi.to_msg(data)
    if m.type == 'cc' then
      orca.vars.midi_cc[m.cc] = m.val
    elseif m.type == 'note_on' then
      orca.vars.midi[m.ch] = m.note 

NOTE: bpm counter in params will not update with the incoming clock bpm. Still not sure how to make that work properly


I tested the midi CC in with a faderfox and it works great. It makes the sequencer a lot more playable with some user interaction. If bpm was assigned in some way you could go a little crazy with fast/slow transitions.


i believe you can map bpm to cc from params menu

No, BPM, is not one of the assignable options in parameters. Its there in the list, but can’t assign. Theres a script to increase the BPM i saw somewhere in the computer version, so might be able to use that plus this Midi CC to control it.

BPM is a number type and not assignable with cc (yet) :frowning_face:

@its_your_bedtime @okyeron
Within the computer version Orca there is this line to control the BPM

But I don’t think it’s compatible with Norns Orca.
Something like that, and I can then assign the CC op to it?

I’ll think how to implement that, for now you can use shift +/- shorcut to change bpm

1 Like

I recommend something like:

  • + bpm up 1
  • - bpm down 1
  • cmd + animate bpm up 10
  • cmd - animate bpm down 10

FWIW - on the norns end bpm is handled by this “beatclock” library and it’s tied to params system in a way that makes it hard to midi-map bpm.

As a test I tried to work around this by hacking beatclock, but it does not work very well.

An intermediate solution could be to add a hardcoded midi CC event mapped to orca tempo, but then you’d have to edit the script to set the CC you want to use.


I was wondering about something, it’s note entirely clear how this would work tho, but I was thinking, could it be possible to have an operator that just sends to any audio engine?

Like we could select a parameter named engine, FM7, for example, and use $3C or whatever, and trigger the right engine with something like engine.hz(note_to_hz(name_to_note('3C')))? I’ve been collecting all these different interesting audio engines and I would love to be able to interface with them freely with orca without having to change the code itself.


afaik, at this point, multi-engine stuff isn’t really supported by the norns architecture.

Would happy to be wrong about that, but alas.

I think we could support softcut + x engine, because they’re fundamentally different, but that’s another matter.

Would it be possible within a single sc engine script to get a list of all available engines and route the signal to the proper one on the fly?

Need to look at the R engine which is supposed to be modular.

Aside from that I don’t think there’s currently a way to have multiple engines available at once.


no, only one engine instantiated at once. the engine command methods are static and they are rebuilt when an engine is loaded.

this is kinda a limitation by design. if engines were modular they would be called “modules” :slight_smile:

(e.g., issue with controlling CPU usage for multiple polyphonic things, no plumbing for routing, commnand list is monolithic.)

that said: you can in fact get a list of available engines and hot-swap them within a script.

it’s also a pretty straightforward exercise to make an engine that wraps multiple engines.


If you made an example of this I would implement it to orca. :heart:


  • Polls for available engine and makes them available in lua space.
  • Have a method that changes from one engine to the next.


currently, engines are supercollider classes. the list of available engines is never changed except by adding SC clasess and restarting sclang process. (i.e., rebooting norns)

function engineLoadedCallback() 

engine.load('EngineName', engineLoadedCallback)

Seriously?! That is amazing, I had no clue it was already present. And I’ve looked!

I will make an example tutorial, because this is… this could be huge for norns.

— And then I will implement to orca.


That’s exciting! The primary limitation is how to communicate with the engines, as there is no norns-wide standard for what types of messages an engine should expect. So, a synth focused engine might have “pitch” while a sampler might have “speed,” even though they’re roughly the same parameter that you would want to target from the governing Lua script.

It might make the most sense to have multiple Orca-customized engines with standardized parameters. These could be existing engines but ported to the Orca repo and renamed (which is critical! You’ll get tons of bugs/failures/hair loss if you have two engines with the same name on your norns after rebooting). Then, Orca doesn’t need to search. Instead, it can have the list baked in.


I saw a lot of engines had the .hz() method for example, so I could maintain a list of interesting engines that are supported in Orca and that might even begin to steer the community to create standards-compliant engines.