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


#1

It so much more intuitive to have the notes offset +/- 50% relative to a step, than 0 - 100%. The latter case means that in STEP mode a lit pad can be a note the should in fact belong to the next pad, which makes it harder to work on and fine tune the sequence.

Is it possible to implement in the current architecture?


Track delay shift - possible?
Performing on the beat with quantise but it records out of time
#2

Just a suggestion that may or may not be a workaround for you - you can rotate/shift an individual note (or all notes on a step) foreward or backwards, then use offset to get it where you want it.


#3

you are damn right! it leads to a lot of mistakes on the steps and so makes live recording almost unusable
for this very reason I don’t use the LIVE mode anymore on the Pyramid (which is really problematic for a MIDI sequencer) just programming notes in step by step.
I kept my Pyramid so long in the hope that this problem would be solved


#4

it does not solve the problem at all, firstly because you may want to keep your recording “human” and not quantify (besides the quantification does not solve the problem either) but it’s a real mess on the steps
so on pretty dense patterns, you don’t want to look for the notes that are on the wrong steps, and to shift them one by one

even within the same chord, there may be notes that are not found on the same step! if only one or a few of them have been played only 1% too early!


#5

Well I did say it may or may not.

For me I just quantise everything, and now with consolidate if I want I can home in on individual notes and move them, so it isn’t an issue, for me.

I guess I find it pretty easy and painless to do.


#6

Because of the way the Pyramid works, the entires concept of steps and offset is entirely done at the UI level. So it would not actually be that hard to change how that works.

Internally note events are very likely stored as a raw midi event with a timecode in ppqn for its note on and off event. The actual values for the step, duration and offset can only be calculated once you know the current zoom.

At the default zoom level of 5 ( 16 steps per measure ) a 16th note on step 4 with a 50% offset has a duration of 1
At the previous zoom level, that same note is now on step 2 with an 25% offset and a duration of 1/2

So it would be easy to simply change the rule. Right now the math is: If a note falls between 2 steps, assign it to the previous step, and set a positive offset from 0% to 100%. You can shift the note to a negative offset, but when you release, the calculation happens again and he note is shifted to the previous step with a positive offset.

In math terms: the assignment uses a FLOOR function: 1.9 becomes step 1 +90% offset, 2.1 becomes step 2 + 10%
What we want is a to use a ROUND function: 1.9 becomes step 2 -10% offset, and 2.1 is step 2 + 10% more logical to us poor humans ( I don’t think the machine cares )

So instead of having notes that only have a positive offset from 0% to 100% we have notes that have a negative -50% to positive 50% offset.

But internally nothing changes, except the little piece of note display code that compute which pad to light up, and how to express the offset between that step position and the real note timing.


#7

I’m really happy to hear that!

and your explanation is (as usual) very clear.

Thx!


#8

I thought Squarp said that they will not change it, in one of the other threads. Do you not find that using filter and zoom helps to find the notes you want to move?

Personally I would also like to see a +/- offset, but since I can work around it and Squarp said they won’t/can’t change it I won’t worry too much.


#9

Yay! @o_0 does it again! Amazing!

My small and totally pointless comment:

Should it be -49% to 50% instead?


#10

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


#11

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.


#12

my biggest issue with the Pyramid so far


#13

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.


#14

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
#15

@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: )


#16

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)


#17

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


#18

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).


#19

I agree on this one!

@squarpadmin any thoughts on this?


#20

+1

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.