Norns: scripting

jasonw22 · 2019-03-27T19:04:48.088Z

If I wanted to write a supercollider engine for midi processing (because SC has some cool midi tricks up its sleeve) and then use it along with an existing synth engine (such as molly_the_poly) can I do that? Multiple interacting engines from one lua script?

markeats · 2019-03-28T00:10:18.125Z

What kind of MIDI tricks are you after? Just wondering if it might make sense to build out more libs on the Lua side for this…

jasonw22 · 2019-03-28T00:14:23.973Z

well, i’m aware of your musicutils.lua lib, and it’s really nice. But I’m thinking about scala support, chord inversion, voice leading…

Maybe it makes sense for lua, but doesn’t this stuff already exist for supercollider?

markeats · 2019-03-28T00:48:51.101Z

I’m just thinking with the structure of norns it might be useful on the Lua side and probably not too difficult to port across - definitely agree that chord generation etc would be great to have

zebra · 2019-03-28T01:25:18.861Z

jasonw22:

scala support, chord inversion, voice leading…

agree with @markeats - none of these things are particularly difficult to build out in a different environment. to speak to the examples:

supporting scala (the tuning format) is simple either through existing C libraries or directly in lua. i would like to see this supported and can put in some time.
chord inversions
voice leading
… i’m actually unsure as to what either of these means. “voice leading” usually describes a stylistic convention (avoid hidden 5ths, &c) - maybe there is some SC lib to implement specific rules, but if so it seems more edifying to identify the actual rules you wanna work with, and implement them directly (shouldn’t be hard.)

same for inversions, but more so and more simple. (chord inversions aren’t even composition/performance devices so much as analysis constructs. but i guess you mean: a library that takes chord+inversion symbols and spits out MIDI notes. that abstract function is quite naturally decoupled from MIDI hardware glue.)

but point out some specific libs / quarks and we can think about them. for example the TuningLib/Scala class is quite simple (https://github.com/supercollider-quarks/TuningLib/blob/master/Scala.sc)

(… though it does depend on the Tuning class.) in any case, the whole of supercollider is available on norns. any decently-designed library for implementing stylistic rules should be able to handle abstract note numbers (from engine commands) as well as bytes from an honest-to-goodness MIDI device… right? (e.g., there is nothing preventing you from using Tuning and Scala in a supercollider engine on norns. you would just take input values from a command instead of from MIDIResponder or whatever.)

i’d just recommend leaving heavy lifting of device/midi routing to matron/lua - there are holes in the current implementation, but they are identifiable, and they are small in comparison to the parts that work - i’d rather fill the remaining gaps than throw out the baby+bathwater.

zebra · 2019-03-28T01:32:10.116Z

anyway, to speak to the actual question:

jasonw22:

If I wanted to write a supercollider engine for midi processing (because SC has some cool midi tricks up its sleeve) and then use it along with an existing synth engine (such as molly_the_poly) can I do that?

well, no; not right now. (we are thinking about alternate architectures maybe for 3.0 - premature, yeah - that can more arbitrarily combine large parts of functionality written in SC.)

in the meantime, extending Molly with a voicing or tuning module would be an excellent exercise in working with SuperCollider classes, and should not break or struggle with the norns engine system in any way.

IOW: you can make use of reusable abstractions in SC on norns, to good effect.

jasonw22 · 2019-03-28T02:48:13.567Z

zebra:

none of these things are particularly difficult to build out in a different environment

“A simple matter of programming” sure, but your value for simple may vary, depending not just on the task, but also on many extenuating circumstances (as we all can attest to…)

zebra:

supporting scala (the tuning format) is simple either through existing C libraries or directly in lua. i would like to see this supported and can put in some time.

sweet!

zebra:

but i guess you mean: a library that takes chord+inversion symbols and spits out MIDI notes.

Yeah, that’s the idea. Check out NDLR or Kordbot for a couple of examples of a theory-aware arpeggiator (in both cases) or sequencer (in the case of NDLR).

So, you know those show how you can noodle around in western common practice by twiddling a couple of knobs and get some pretty pleasing results.

I think it gets even more interesting if you start thinking about applying this approach to other styles. A 12-tone serialism capable sequencer? How about balinese gamelan scales and rhythms? If you can express it as theory, you can decompose into rules, and use rules to generate sequences.

Almost makes me wonder if I’m looking for a way of expressing rules of tonality, harmony, and rhythm in a DSL and/or file format, possibly similar to what scala does for scales?

zebra:

the TuningLib/Scala class is quite simple

Wow, yes! Surprisingly simple.

Similar: https://github.com/supercollider-quarks/ScalaTunings

Interesting: https://github.com/musikinformatik/GamelanPatterns
(Part of a VirtualGamelan Quark that includes synthesis classes)

Percussion, notes, chords, progressions: https://github.com/lvm/MusicalNotation

zebra:

e.g., there is nothing preventing you from using Tuning and Scala in a supercollider engine on norns. you would just take input values from a command instead of from MIDIResponder or whatever.

But I’d need to be tightly bound to whatever synthesis I also wanted to do in Supercollider? I’d prefer to find a way to separate these concerns, if possible. Seems like the way to do this in norns is to do it in lua. (Whereas if I were doing this with, say, a Pisound, I’d probably write a Quark?) Sort of wish I didn’t need to make that decision…

zebra:

we are thinking about alternate architectures maybe for 3.0

OK. I can wait. And make peace with lua in the meantime, though I may not pursue my full ambition in the 2.0 timeframe.

zebra:

in the meantime, extending Molly with a voicing or tuning module would be an excellent exercise in working with SuperCollider classes, and should not break or struggle with the norns engine system in any way.

IOW: you can make use of reusable abstractions in SC on norns, to good effect.

This will absolutely be a good learning exercise for me.

zebra · 2019-03-28T02:59:23.361Z

jasonw22:

So, you know those show how you can noodle around in western common practice by twiddling a couple of knobs and get some pretty pleasing results.

I think it gets even more interesting if you start thinking about applying this approach to other styles. A 12-tone serialism capable sequencer? How about balinese gamelan scales and rhythms? If you

right, well… that speaks to my exact opinion on theory-aware algorithms. the rules for those styles are totally, totally different - they don’t work along the same axes at all. formulating the rules is the interesting part; the implementation is not actually such a big deal. IOW i think if you use SC for generating 12t serial melodies, you will find it is nearly much work as doing it in lua.

(though, it would be nice to get utilties like the SC methods for Collection and SequenceableCollection - that would be a compelling reason to pull in something from luarocks in the standard install - assuming performance is reasonable…)

and where we are really really trying to get to with norns, is to move away from SC as a requirement. it’s great to support it but there are a significant number of people who want to use other environments for synthesis.

but with both points as caveats:

jasonw22:

I’d need to be tightly bound to whatever synthesis I also wanted to do in Supercollider?

well yeah, but only to the extent that engines are truly monolithic. so far, most of them are - but R is an extreme exception (it is totally modular) and i think it always makes sense to build out useful abstractions for engines, whether they are dynamic or not. (this circles back to e.g. standards for polysynths - i like to use [voice id, hz] as voice creation arguments, and do non-standard tuning/voicing in lua; others want to just sent straight midi notes to the engine, directly from controller. adding tuning and voicing abstractions to SC would help us both, but i think adding them to lua would help everyone.

</soapbox>

noiserock · 2019-03-29T08:54:39.149Z

This might be a redundant question, but I was wondering if there are any good scripting tools to port scripts to older 64 grids(non varibright). If someone could just point me to a coding reference on how to define grids and handle LEDs that would be awesome

Since I am a 64 user, and will kost likely continue to be one(I adore the form factor) I will need to grasp how to try and port stuff for my 64.

GoneCaving · 2019-03-29T09:05:01.978Z

I suppose it would probably make sense to start with Study 4. After that it’s just a matter of working the code to look for use of varibright LEDs (i.e. the third argument to grid.led being set values in between 0,15), and also where the code is setting/handling button presses outside of the range that would be defined for a 64. just how much work that’s going to be is likely to depend on the script. There isn’t AFAIK, a generic way of handling the grid that abstracts away the physical capabilities.

jah · 2019-03-29T09:33:41.470Z

Re: 64 grids. I use these too. You can get column width from a device. This is from the step script updated for norns 2.0:

github.com

antonhornquist/step/blob/master/step.lua#L123


  if grid.device then
    for x=1,MAXWIDTH do
      refresh_grid_column(x, false)
    end
    grid:refresh()
  end
end


local function refresh_ui()
  if grid.device then
    if gridwidth ~= grid.cols then
      gridwidth = grid.cols
      grid_dirty = true
    end
  end


  local grid_check = grid.device ~= nil
  if grid_connected ~= grid_check then
    grid_connected = grid_check
    grid_dirty = true
  end

markeats · 2019-03-30T23:55:28.132Z

I took a first pass at adding some chord functions to musicutil, should be landing in 2.0

There’s now a simple function to generate chords that should be self-explanatory:
generate_chord(root_num, chord_type, inversion)

And another that returns a list of chord types that fit a given root note and key:
chord_types_for_note(note_num, key_root, key_type)
(I think this one is useful?!)

Anyway hopefully that’s something to get going on some algorithmic chord scripts and we can work out what else might be useful in the library from there

jasonw22 · 2019-03-31T00:04:08.246Z

Woo! Thanks for doing that!

carvingcode · 2019-03-31T01:41:48.942Z

Can you double check the octave returned from note_num_to_name? I’m getting an octave lower than what I think should be. Ex: midi note number 60 is C4 in all charts I can find, yet the routine returns C3.

markeats · 2019-03-31T02:15:43.176Z

This is the source of much debate (amongst those who like to debate MIDI specs…)
For what it’s worth 60 = C3 matches Ableton amongst others.

carvingcode · 2019-03-31T02:20:12.974Z

Ah… I see now. I see 60 = C3 is actually in the MIDI specs. Thanks.

lazzarello · 2019-04-01T22:31:41.446Z

Today I Learned

In Lua the relational operator for “not equal to” is spelled ~=

This is different than most languages, who spell it !=

carvingcode · 2019-04-02T13:58:26.789Z

Just realized I’m using tab.contains() and don’t have the tabutils library set as required. The function works fine. Is tabutils auto-included, or should I explicitly require it?

zebra · 2019-04-02T13:59:19.041Z

it’s a global include

github.com

monome/norns/blob/dev/lua/core/startup.lua#L3


-- STARTUP


tab = require 'tabutil'
util = require 'util'


require 'math'
math.randomseed(os.time()) -- more random


-- globals
audio = require 'core/audio'
screen = require 'core/screen'
monome = require 'core/monome'
grid = require 'core/grid'

audionerd · 2019-04-06T18:18:15.660Z

Is there a way to run a function whenever any grid is connected and on disconnect, after the script has started? (I’m on norns 2.0)