Molly the Poly

It seems to happen when new notes are started. I haven’t tried to reproduce it in your Molly the Polly lua script, though. It’s possible I’m doing something else funky in my script that’s causing performance issues.

Totally understood if you’d prefer to keep it a fixed constant. My first instinct was to put this in the engine, but I would probably have an easier time implementing it in Lua anyway :slight_smile:

I’m just thinking if the clicks are to do with voice start / stop then reducing the count won’t fix it – it may need a little investigating. If you can reproduce it in a simple script or the included one then I can look into it.

This looks so cool! Do you have any videos of this being used?

1 Like

Just the one at the top from me, you might find some from others on Instagram though.

For anyone looking how to save: Press the first button then PSET menu.


Love playing Molly and was hoping to integrate a keymap to ease things up. I got the keymap up and running separate from Molly itself, but when I tried integrating that code into Molly, I ran into a few issues. I changed g:led to grid_device:led, and then I got ‘a nil value’ error and confirmed via a print that grid_device was reading a nil value despite having my grid attached and using it that very moment to play notes back…

Any thoughts on what idiosyncrasies within the script may have brought me to this place // how I may resolve them?

I’m also encountering a slight issue re an expression pedal I’ve wired up for per-note velocity to accommodate for my physical limitations. I created a variable to stand in for the .8 velocity value and then divided the input of the pedal by 127. Unfortunately, when I hit 0 velocity (no pressure on pedal), it doesn’t go to 0 but instead to the last value it was at when I pressed a note (since 0 is a nil value, so the variable fails to update). Any thoughts on how I might change the math there? When I tried adding 1 to the value of the pedal before the / 127, the script failed to load altogether D=

EDIT: This is really my first shot at Norns things – hopefully not overly-silly questions. Going to keep working at it and see if I can figure something out…

it’s been too long for me to remember specific idiosyncrasies with this, but it definitely has some––this was one of the first big new synth engines that norns got, i remember having issues trying to go from the tutorial commands to actually making the same things work with this one. it doesn’t take the same values as the synth engine used in the tutorials. when i was hitting walls it was almost always because i hadn’t followed the variable all the way through the various functions that needed to hit to call the note.

i have probably forgotten too much to be able to help answer your questions but i can maybe get you asking better questions, can you paste the keymap code that is running separately which works?

for the expression pedal, there are a million ways to do this and i am an amateur, but it sounds like you could probably just set the velocity value to 0 by default, something like

    if expPedalValue ~= 0 then 
        velocity = expPedalvalue 
        velocity = 0 

but this is a complete guess and is basically the first line of norns code i’ve written in half a year. so it’s probably not what you want.

FYI: you can paste code with syntax highlighting on lines if you wrap it in triple backticks (```)

1 Like

Taking the long view, this is even better.

Upon reflection, by work I mean “the things I want to have light up light up” – since it’s in isolation, I have no way to test things like “persistence after a note press” etc. But here is:

g:led(1, 1, 4)
g:led(1, 7, 4)
g:led(1, 8, 15)

g:led(2, 1, 15)
g:led(2, 2, 4)
g:led(2, 3, 4)
g:led(2, 4, 4)
g:led(2, 5, 4)
g:led(2, 6, 4)

g:led(3, 5, 4)
g:led(3, 6, 15)
g:led(3, 7, 4)
g:led(3, 8, 4)

g:led(4, 1, 4)
g:led(4, 2, 4)
g:led(4, 3, 4)
g:led(4, 4, 4)

g:led(5, 3, 4)
g:led(5, 4, 15)
g:led(5, 5, 4)
g:led(5, 6, 4)
g:led(5, 7, 4)
g:led(5, 8, 4)

g:led(6, 1, 4)
g:led(6, 2, 4)
g:led(6, 8, 4)

g:led(7, 1, 4)
g:led(7, 2, 15)
g:led(7, 3, 4)
g:led(7, 4, 4)
g:led(7, 5, 4)
g:led(7, 6, 4)
g:led(7, 7, 4)

g:led(8, 6, 4)
g:led(8, 7, 15)
g:led(8, 8, 4)

g:led(9, 1, 4)
g:led(9, 2, 4)
g:led(9, 3, 4)
g:led(9, 4, 4)
g:led(9, 5, 4)

g:led(10, 4, 4)
g:led(10, 5, 15)
g:led(10, 6, 4)
g:led(10, 7, 4)
g:led(10, 8, 4)

g:led(11, 1, 4)
g:led(11, 2, 4)
g:led(11, 3, 4)

g:led(12, 2, 4)
g:led(12, 3, 15)
g:led(12, 4, 4)
g:led(12, 5, 4)
g:led(12, 6, 4)
g:led(12, 7, 4)
g:led(12, 8, 4)

g:led(13, 1, 4)
g:led(13, 7, 4)
g:led(13, 8, 15)

g:led(14, 1, 15)
g:led(14, 2, 4)
g:led(14, 3, 4)
g:led(14, 4, 4)
g:led(14, 5, 4)
g:led(14, 6, 4)

g:led(15, 5, 4)
g:led(15, 6, 15)
g:led(15, 7, 4)
g:led(15, 8, 4)

g:led(16, 1, 4)
g:led(16, 2, 4)
g:led(16, 3, 4)
g:led(16, 4, 4)


really very simple.

I’m going to try that elseif solution tomorrow; intuitively, it seems like it’ll work, and, as silly as this’ll sound: I’m stoked that I understand it…

so i just did this and it worked. i’m guessing that you may have placed your lights in the wrong spot of the code. typically scripts for grids will have two functions that determine 1) how norns should respond when it feels you push a button and 2) how the grid should look at any given time.

this specific script actually combines those two things into one function (grid_key at line 197). if you put the LED instructions in there (you were right to change it to grid_device btw, that also needs to happen), and eliminate the redundant grid_device:refresh(), it should work after that function is called (meaning after you press a grid button once to trigger this function for the first time).*

if you put this somewhere else or with a different name than grid_device, it seems like it might look for some other grid to refresh/light up or just not know what you’re talking about.

*you might notice that technically this is telling the grid to light up all those lights every time you press a button, which is not super efficient. doesn’t seem to make a difference in this context but this is why most scripts with big grid interfaces separate drawing and interacting functions.

hope that makes some sense!


Makes perfect sense!

keymap established! Thanks also for the ancillary instruction in how to talk about these things – I’ve been around a while, but haven’t engaged in much technical discourse, and this part is essential to growth.

The velocity bit, though, is still operating under the old behavior (even after integrating your suggested 0 elseif fix, assuming I’ve done it correctly below):

    -- CC
    elseif msg.type == "cc" then
      -- Mod wheel
      if == 1 then
        set_timbre_all(msg.val / 127)
      elseif == 7 then
        if msg.val ~= 0 then
           note_v = (msg.val / 127)
          note_v = 0

should mention I’ve replaced the 0.8 in the note_on line with note_v to make all this work (around line 300 in my version – probably earlier in yours due to my mods). (should credit @dan_derks for getting me this far)

1 Like

can’t actually test this one so i will be less helpful on it this. seems like it could be a lot of things. some guesses/things to try:

—is the expression pedal itself sending anything at all on 0? (try verifying note_v using print statements to see if it actually hits zero)
—should note ons with zero velocity actually be note offs? (does note on with vel 0 mean anything if the message is following the same note with a different velocity)
—should vel=0 actually be killing all notes, not just the most recently triggered note? (would need to keep track of active note_on messages in a list and send corresponding note offs or something, hopefully not how this would work)

the way this is currently set up, the expression pedal sets the velocity of the note, then grid press sends a value with that velocity, and there’s no way to update that value in real time—maybe this is obviously how midi is supposed to work, i don’t know much with midi. but if velocity is a stand in for volume it probably makes more sense to control the volume via cc and not confine it to note on messages?

New version 1.2.0 up with MPE support from @scazan :pray:


Hey mark,
I included Molly as an engine in my sequencer script for norns. Now I’d like to add some kind of ‘accent’ functionality. I noticed no difference in volume (or anything else), whatever I set the velocity to on the noteOn command. I tried several values between 0-1, 0-100, 0-127. What range should the velocity be in? Plz help! :slight_smile:

Velocity is 0-1 (you can see here it is defined as a float).


Thanks, it’s working now. :slight_smile:
It’s quite hard to recognize the difference in volume, if you’re having not enough difference in velocity. I had to increase the difference to about 0.5 to have an audible effect.

Picked up the Linnstrument today after a long break. Was desperate to find good sound sources as I’m not using computer for music anymore, and don’t really have too much gear around either. Then realized I do have a Fates.

Hmm. Let’s see if any scripts already have support for MPE.

Oh yes.

Molly is a super fun MPE synth as is. Thanks. :slight_smile:

(Anyone want to sell me a factory built Norns? I think I need two now.)


I asked a question about Molly and Midigrid in the Midigrd thread, in case you feel like contributing to it:

Is anyone using Molly with one or two Launchpads as Grid replacement here?

I recently made a PR that aded dynamic grid support but it broke non grid usage. my mistake. I’m currently fixing the issue and submitting new PRs to several scripts.

PR should be submitted within the hour

1 Like

just a small correction for the beginning. it seems to me that E1 doesnt do anything so instead it should say E2 selecting the planet and then E3 twist creates the sound.
am I misunderstanding these controls?

thanks for this awesome sounding script

Ah yep good catch, should be E2 & E3

1 Like