Note offset +/- 50% - is it ever going to happen?


Yay! @o_0 does it again! Amazing!

My small and totally pointless comment:

Should it be -49% to 50% instead?


Yes, it should be like that :wink:

(or even with ppqn unit! I don’t care! but it is really important to understand that, in music, a note can happen a bit later but also a bit earlier…)


Sure you can shif the notes one by one, but that is quite time consuming, even more so when the recorded notes are placed on the wrong pad when you look at them in STEP mode.

This offset issue might just seem like a small niggle, but in practice it’s quite frustrating and irritating when working on dense tracks.

I wish they would also implement a strength factor to the quantizer fx, so you can tighten up a live recording without completely removing the live feel… There is the humanizer function, but the use case for that seems to be more for the opposite workflow, when you add notes manually and want them to sound as if they were recorded live.


my biggest issue with the Pyramid so far


The most obvious problem with the current visualization mode is the following:

record a chord, and your timing is pretty tight so you have a note exactly on the beat, 1 note slightly early and another one slightly late. all of them are within 2% of each other.

With the current scheme your chord looks super sloppy because it displays on 2 separate steps. but when you look at it, you notice the following:

  • first note is on step 4, with a 99% offset.
  • second note is on step 5 with a 0% offset
  • third note is also on step 5 with a 1% offset

This no longer looks like a chord, or can’t be edited easily as a chord anymore.

BTW: this is not an editing problem we already have the option to apply a negative offset. so it is always possible to edit notes and nudge them forward and back and the offset encoder allows you to send a note forward by 100% or all the way back to 100%.

This is a display (UI) problem. notes are always displayed on the previous step with a positive offset, never on the following step with a negative offset. We would like notes to always be anchored to the closest step, and the offset be relative ±50% ( -49.999999% to + 50% ) from that closest step.


Not only an UI discomfort actually.

What happens to me most of the time:
While sequencer is running, press REQ to record in a synth line. Very often I hit the first note on the first bar a little early. This means the note is actually on the last bars last step. And no matter how you quantize it, when I start the sequencer, the first note is not played, because its on the other end of the pattern. It gets played the first time after the first loop.

Problem: Pyramid skips first step in sequence

@joosep that one is even weirder. if the note was recorded, it means it was within the record window, because you didn’t play it at the end of the pattern. There must be special wraparound code to send notes across the loop boundary, because simple mapping of the note to step doesn’t explain that.

( I agree that this is even more confusing, and therefore NOT SIMPLE :sunglasses: )


it happens to me all the time as well

since then I have unfortunately abandoned live recordings

(we are talking about really basic actions for a midi sequencer here)


me too. first beats on the wrong steps… this is even worst! all begin to be chaotic very quickly on dense patterns, and if our only solution is to nudge these wrong steps by hand, I think it is better to program directly in step mode and ditch the live mode on this machine


Yes, I agree too. This is I believe the main problem. It is really key to correct this point.
Please squarp team … at least correct this point for live recording (first note on the last bars/step).


I agree on this one!

@squarpadmin any thoughts on this?



as someone who does most input in live mode, I couldn’t agree more… this can be a huge headache and really throw a wrench into something that shouldn’t be so confusing.

I know squarp said no more fixes on this update, but if there were one thing they could address, this would be it for me.


I can’t really speak for the „quiet“ user base but it seems like it’s a big one for most of us who contribute here. It sure is for me, I can’t count how many times I had to manually fix my steps because of that 2% early hitting. (It especially happens when I play with others. I guess it’s like the drummer‘s syndrome.)

The solve with Math.round instead of Math.floor almost sounds too easy to be true. But only Squarp knows…


whaaat??? when I wanted to put a sliiiightly negative offset and the note landed on the step on the left I thought it was a bug! I was going to report it. This is not a bug??!
youre kidding
it cant be like that. this is not serious.
what is the point having a sequencer designed for musicians (real time signatures, polymeters etc.) but can’t be reliable on the very basic stuff (namely the position of the notes)?
you have to admit: this is a joke


yeah I forgot that it is also a problem in step-by-step anyway
since we want to be able to slightly advance a note, even in the editing proces

it’s a fact: in music, a note that occurs a little before the beat is as common as a note that occurs a little after.


Fortunately with v3 it is very simple to correct, have you guys fully explored yet? I did a test where I purposely played in a beat with bad timing in live mode, sure enough a beat that I wanted on the 1 landed on the 16, it took less than 1 second to get it where I wanted it, by using rotate and offset. Quantize also seems to be improved and in my brief tests also often brought the note to where I wanted it.

You can select multiple notes or multiple steps in step mode and move them easily, you can filter, zoom and view easily, I do not know of any other hardware sequencer which makes it so easy to do this, and I’ve been using midi sequencers for 30 years.

I agree that the current note display position behaviour is not ideal, but as it has been stated a few times by Squarp now it won’t be changing. I feel your frustrations at this but sometimes you just have to accept it and get on with it or decide that you can’t live with it and find another device that works how you want it to.

Gear is always a compromise there isn’t and never will be one box that does everything you want, I am not trying to stir the pot here, but hoping that rather than focusing on what it doesn’t do we focus on what it does do, and does very well, and discuss workarounds, tips, share definitions and still continue to suggest features and improvements but not keep flogging a dead horse.


great news!
what is your workaround if we want a note stays on the correct step (normal) but be heard a little earlier?


Use -offset.


I guess you are talking about the step display?


Why didn’t we think of that?

yes I was talking about the step display
on the pads AND on the screen

the thing is, there is no workaround
that’s the problem