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


it is!

if you add to that the use of a metric other than 4/4 where you don’t have the first beat at the beginning of a page (and whose place changes on each page). It’s even more difficult to find your first beats if they are misplaced

but most of all, I think you missed the most important point of this feature
we can be in the case where we WANT to advance a note slightly before the beat but we don’t want it to be indicated on the step before.

tell me, what is this function for? (even with a range of 0-100%)
it’s not used to move the notes horizontally across the steps, right? (since we already have the left / right arrows for that)
we’re talking about micro-timing here so it makes sense to want to use this function to the right but also to the left
I think you would not be happy to only have the function of the right arrow? … :wink:

above, we also talked about the problem with chords whose the notes are not necessarily on the same step

believe me, when you start to have very dense patterns harmonically, it becomes a hell…

again…I think you missed the point here.


I must have, because I thought earlier you was talking about your difficulty of correcting live played notes, which I think is simple to do.


I don’t even understand how a developer can think to keep the things like that tbh
I mean if you change the values on the right it stays on the right step until 99% or whatever and in the other direction even with little values it changes the step???
again it cant be serious.

About PyraOS future

Hi there,

This thread is more than alive and we want to understand well what is happening.

  1. Where notes are displayed on the pads. Most of you seem to agree that you would like to have a pad lit if the beginning of the note is between -49% and +50% of the current step. So slight negatives offsets would remains on the leading step even if the Note On event happens before.

We can understand this, actually it’s a good idea, but now we have to stay focus to give you a perfect - bug free - pyraOs version.

Changing things at this time is always a risk to create new bugs and all we want is to give you a pyraOs version you can rely on. We don’t want Pyramid users to have fear while performing live, that is why we focus only on bug resolution right now.

  1. Notes at the end of the track. I am assuming you are looping in overdub mode, waiting for the next loop start to begin to play. You start to play a little bit earlier than 0 position. So your note is slightly offset before 0 (so lit at the track end).
    Even if we lit the first pad (meaning we “read the whole list of notes to check where is the last one”), what do we do when you press stop and then play ?
    Do we skip it (this is how it works now) because Note On occurs before the very beginning of the loop and it’s not accurate if we play it at position 0 ?
    Do we play it ? We take all notes between half a step from the end and the end and we play them at once. In this case, note off should occur at the same place than before (if we actually play them at the right moment before the very beginning).

Thanks all for your ideas and feedbacks. Please be kind, try to give us short answers to let us free time to actually work on the code :). We are at the Superbooth Fest (Berlin) this week, so we don’t have a lot of time for this right now. We will read your answers next week !


How about having a pre zero position buffer? So any note which was played earlier than step 1 on a loop but which is intended to be the first note, is played when the user presses start in the pre zero position buffer then at zero all the other events on or after zero play. So essentially it is like a small delay on start to allow pre zero events. The good thing about this approach is that it will also allow users of synths with midi latency to offset them back a bit to compensate.

It could be a pref in settings whether to enable it or not.


Hey @squarpadmin,

let’s not mix up the two topics about
A) which steps to light up in relation to note offset and
B) how to record when looping (overshoot/early playing)

I’d love to see you tackle both, as they are all important for a sequencer. But one at a time and maybe note offset (A) first. @darenager’s idea about a constantly recording ringbuffer is pretty good. I guess this buffer has to listen whenever you are in live mode. In regard to multitrack A/multitrack B I’m guessing this might be a big task, performance wise.

I hope you have a successful Superbooth and make a lot of new friends! :slight_smile:


I would like to voice my support for addressing the issue of the step light changing when there is a negative note offset. It’s extremely confusing to those of us who play our parts in live. Unworkable, sometimes. I understand that the new OS needs to be perfected first, but please please address this issue in the future.
Have fun at Superbooth, safe travels!


Perfectly understandable! Take all the time you need for this!

I think you perfectly understood this first point which seems to be the most important
and not only for live recording actually…
besides I think I find another utility every day for that…
e.g when we have to deal with some synth sounds with very slow attack but we want the notes be heard perfectly on the beat (and the proper steps be lit of course…)

for this second point it is more tricky…
I think the notes that occur slightly before the beat make sense only during a pattern, not on the begining

but I guess I would be fine with the two solutions you proposed: the notes after 50% at the end of the loop could be indicated on the very first step with 0% offset (quantification of the note starts)
or with a negative offset and not be heard on the first pass (in which case I think we would start to reset the offset to zero on these notes, 9 times out of 10
but…I don’t know…this solution could have an advantage in some particular cases where we want “add” some notes on the second pass, and like you said : it would be more “accurate” (no quantification)…so I think I would vote for this second solution personally

that being said, I don’t know if this will lead you to review how the Pyramid core player works…
but if so, maybe it would be nice to recall some of the most requested features that may be all related to how the current architecture works:

  • offset range on -49 / + 50%
  • disambiguation between bars and pages (first steps on the beginning of a page)
  • a visual indicator for the number of the BAR currently being played (this assumes that the sequencer identify which is the first step of each bar, whatever the TimeSignature is)
  • ability to apply delay on some tracks (to help to compensate some latency problems)

  1. +1000! I’m so glad you are still considering implementing this!

  2. In my opinion a note recorded just before the end of a loop that is left unquantized should not be played the first time the loop plays, only when the loop reaches the end. Just like it works in the current PyraOs. BUT if the quantize FX is used then the note should be played on the first beat even the first time the loop is played. And consequently, if the quantize FX is consolidated the note should be forced to the first beat of the loop. In any case, no matter if the note is quantized or not, I think it should be displayed on the pad it is closest to (which will depend on zoom level of course).


I couldn’t agree more!


Good summary @modularmind. +1


@modularmind +1
I agree


The Pyramid does a lot of things really well. But the note display for early notes could be so much better.

The method -50% / +50% idea is the way to go. It’s already proven in the Elektron boxes (OT and upwards).



Completely agree with the +/-50% display on the lightning pads.
The actual display is really the only thing i really regret on the Pyramid.


Yes! We still need this :frowning:


If you want this (or anything else) you need to submit a request to Squarp via their website - they have said this is how they are tracking / prioritizing issues/features.


Yes, please submit this request to Squarp directly. It’s clear that squarp rarely peeks in at this forum, so anyone who’s interested in this, send this feature request directly to Squarp.

Squarp has done a fantastic job with their updates. They clearly do listen to their customers. This one clearly is a big one and likely a big undertaking to fix… But it needs to happen. I find it to be the biggest hurdle I encounter when working with the Pyramid.


I just sent an email to Squarp.
Hope this feature will finally be possible.