#416

line 82 sets up the polls on init
local phase_poll = poll.set('phase_' .. v, function(pos) positions[v] = pos end)

then I look up study 5 about polls:
https://monome.org/docs/norns/study-5/

Aha - In the Glut engine, the phase and levels polls are created.

Engine_Glut.sc line 212

			this.addPoll(("phase_" ++ (i+1)).asSymbol, {
				var val = phases[i].getSynchronous;
				val
			});

			this.addPoll(("level_" ++ (i+1)).asSymbol, {
				var val = levels[i].getSynchronous;
				val
			});
		});

but… if VOICES is 4 why are there 7 phase polls created? Or is 7 the default in the engine, and angl is just setting 4 of those?

Seems like the polls get updated by the callback function every time iteration?

EDIT - Aha the engine defines 7 voices classvar nvoices = 7;

3 Likes
#417

Thanks. This makes sense. I had a long discussion with a friend about how this implementation of an oscillating circle is based on the length of the sample. I forgot about the SC layer exporting polls from engines.

1 Like
#418

So are you running the REPL at the command line on the Norns, and typing “norns.script.load()…” to reload? Right now I’m doing this mix of VS code, rsync, and hitting the play button in Maiden that gets pretty old.

I’d love to automate reloading the script on the Norns side and keep the console/REPL up for errors

1 Like
#419

Yeah - that’s what I was doing for a bit. I keep going back and forth on using my text editor and maiden.

#420

Considerably quicker than reopening the script and ‘playing’ it. :+1:

#421

Not sure if it’s the right place to ask, but there is a way to control internal tempo via cc? It might seem stupid, I know :slight_smile:

Maybe with crow I will be able to change tempo via cv from the modular? That would be awesome, but I’d like to do it also in stand-alone mode via a fader on my nanokontrol. No, uh?

1 Like
Norns: ideas
#422

I think you can expose tempo controls to params menu, and map it to cc from there

#423

A lot of apps have tempo in the params menu, but AFAIK it’s NEVER cc-controllable, so I thought it was not possible. If it is please tell me how to mod the scripts and I’d be grateful! :pray:

2 Likes
#424

you can certainly write your own midi cc map to tempo. see the norns study on midi as a start.

I am intending to expand the parameters cc system to cover Number types in addition to Control types, so soon no extra scripting will be needed

3 Likes
#425

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?

1 Like
#426

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…

2 Likes
#427

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?

2 Likes
#428

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 :+1:

6 Likes
#429

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.

3 Likes
#430

anyway, to speak to the actual question:

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.

2 Likes
#431

“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…)

sweet!

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?

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

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…

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.

This will absolutely be a good learning exercise for me.

#432

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:

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>

4 Likes
#434

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 :slight_smile:

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.

#435

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.

3 Likes
#436

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:

3 Likes