Pyramid's MIDI resolution (or ticks)

Hello. I’m new here and I hope this question is a reasonable thing to be asking on this forum. I have tried searching and have read some interesting stuff along the way (so thank you all) but I can’t find anything to confirm what the highest resolution, say in ticks, is for the Pyramid in step mode. I suppose I should add that I don’t yet have a Pyramid.

I see in the specs that the record resolution is 96ppqn, but I’m assuming that the resolution would be higher in step mode considering you can zoom in and use offsets to position a notes start point. If I’ve done my maths right it seems that it could be as much as 1600ppqn. That seems amazingly good. I’m used to 384ppqn. Could it be as high as 1600ppqn?

Does anyone know? Maybe it’s not as straight forward as just thinking that if you can zoom to 1/64th notes and they can be offset from 0-99% then that means 1 bar = 6400 ticks = 1600ppqn. If it was wouldn’t Squarp publish that in their specs? Perhaps it’s impossible to give a ppqn value when you are dealing with offset percentages and variable time signatures (my head is hurting just thinking about whether that would make any difference).

But if anyone can say, let’s just say in plain old 4/4 time, what they believe it to be that would be ace. Failing that, I wonder if anyone can say whether the offset amount moves in single figures or incrementally when you get to higher zoom resolutions.

Many thanks.

1 Like

Apologies, I can’t maths right now, but irrespective of what you can define in Step Mode, the reality is that the MIDI Standard, which the Pyramid must adhere to when sending data out, is 24ppqn I believe. The Pyramid records at 96ppqn, which is data coming in that it listens to and writes down - but sending out must conform to the MIDI standard. Sending out a higher resolution just tells synths down the line the BPM is higher (so, if you sent out 96ppqn, then resulting synths would sync their LFO’s and groove boxes would play 4x speed).

However, more directly to your question, in the highest Zoom, Step Mode will allow an offset of -50% to +83% in increments of something around 16% each…so: -50%, -33%, -16%, 0%, 16%, 33%, 50%, 66%, and 83%.

With regards to resolution changing in zoom mode, PPQN is based on Quarter Notes…Zoom does not change the duration of a quarter note - it changes the resolution of your view of the data - so ppqn is constant irrespective of Zoom level.

Thanks, CreepyPants.

I probably should have not said ppqn and gone with ‘ticks’. But I guess it would still need to be referenced to something to have any meaning. In any case I didn’t mean to ask about Pyramid’s MIDI clock, so sorry for the confusion.

I realise zoom doesn’t change the length of a quarter note. But from my understanding it would have an effect on the length of time each of the 16 step pads represented. So I thought if I were to increase the zoom level (from 1x to 2x) then the step pad would represent half the amount of time. Which I would have thought would have allowed me more precision (twice the resolution) when offsetting a note (as long as I was still able to move the note in 1% increments).

From your reply it appears that the offset at higher zoom levels becomes more incremented, and so it seems like that isn’t the case. I don’t fancy doing the maths now either but if the increments are around 16% at 16x zoom I guess that means there is no more resolution at higher zoom levels. Now I suppose my question is what is the highest zoom level where the offset (still) moves in 1% increments? I guess if it was 4x zoom that would equate to 400 ticks per beat, which for me, would be plenty. And I reckon if I had to guess 4x zoom is where I’d guess.

Yes.

● x1 zoom: 1 step = quarter note
● x2 zoom: 1 step = eighth note
● x4 zoom: 1 step = sixteenth note (default)
● x8 zoom: 1 step = thirty-second note
● x16 zoom: 1 step = sixty-four note (useful to surgically edit your track ).

Manual → Track Mode → Zoom

Okay, so now I’m feeling a bit more like doing the maths. From what CreepyPants has said about the increments in offset values at the highest zoom level it looks like that with x16 zoom you’d have 6 increments per step. And because 16 sixty-fourth note steps make up 1 quarter note that would mean 16 x 6 increments = 96 ‘ticks’ per quarter note. So we arrive at the same figure as the record resolution.

From that I’d now be guessing that at even the default zoom level of x4 that when adjusting offset values that they would move incrementally, probably by around 4% at a time (although the exact sequence for the increments may be designed so that you can land on 25%, 50% and 75% along the way). Can anyone confirm this?

Cheers.

At highest zoom, each Pad = 64th note.
There are sixteen 64th notes per one quarter note (16 ppqn).
Each step can be further subdivided to 6 via Offset (0, 16, 33, 50, 66, 83%).

16x6=96ppqn

If you would like verification and/or more technical data, since this is a user forum I would suggest contacting Squarp at squarp.net/contact

1 Like

Thanks for your help, CreepyPants. I tried contacting Squarp but no reply yet. It seemed likely 96ppqn was going to be the maximum resolution although on close inspection of the Loopop tutorial video it appeared that with x4 zoom on the note stepmode screen (not the piano roll display screen) he was landing on a few odd numbers between 0 and 10 when he turned encoder number 5. This made me wonder. When he turned the same encoder when on the piano roll display the offset value seemed to jump in increments of 4 or more (as you’d expect for 96ppqn at x4 zoom). I realise now the difference was that he was setting a ‘default’ offset on the note stepmode screen prior to a step pad being pressed, which is not quite the same as editing an existing note’s offset.

Anyway, I decided to assume a maximum resolution of 96ppqn and see how that sat with me. I would have been happy with 192ppqn (sometimes I find the 384 I’m accustomed to leads me to pointlessly moving notes about by a tick or two here and there to see if a chopped up drum loop or something will scan just that little bit better). Back in my Atari STe/Cubase 2.0 days 192ppqn was fine, maybe better even, or was I just more decisive then? I don’t know. Could I live with half that resolution?

After a bit of weighing up the pros and cons I suddenly became decisive, or rather there was a moment of decisiveness that was preceeded by a fairly lengthy period of indecision. And… ummm… BOOM! There it was - I became a Pyramid owner.

It’s not clear to me yet whether a note created with a default offset of 1% (say, with x16 zoom) is actually at 1%. Once you go to edit it, say, by pressing it’s step pad it shows up as 16%. So I suppose not. In any case the resolution seems to be enough for anything I’ve tried yet (which isn’t much so far). And if I really have to I suppose I can set the Pyramid at twice the tempo. The note width (length) might be more of an issue but there are workarounds.

The features and dawlessness were enough to win me over and there’s just something about the way the (only) 16 step pads represent the ‘grid’ (at various zoom levels) that appeals to me. Early days yet but I’m really liking it so far.

its 96ppqn

zoom does not change this, it only alters the ‘view’ on to the midi data.

as @CreepyPants already pointed out…
at 1x zoom (which is quarter notes) , you get 1% offsets , at 2x you get 2% steps etc.
… so you’re not getting any more ‘resolution’ , since the offsets steps increase proportionally to the zoom.

ok, these numbers are ‘rounded up’ to be a nicer user experience.
but basically 1x = quarters notes, so 96ppqn , means you have 1/96 resolution on that … hence why you can shift 1%, or more accurately this would be 96/100

Thanks, @thetechnobear.

Yeah, if the Pyramid had 192ppqn resolution I wouldn’t have had any quarms in buying one whatsoever. 96ppqn will no doubt be enough for most things. It’s just sometimes I like to surgically chop up drum loops (using my Emu ESi’s) and stitch the samples back together in different orders and sometimes nudging a few of the samples start times by a tick or two (with 384 or 192 ppqn resolution) can make the difference in making the stitched together drum phrase flow nicely.

A resolution of 96ppqn caused me some concern but didn’t completely put me off. It does seem a bit low for such a good sequencer to me though, and because of what Squarp say about zooming in to ‘surgically edit’ your track I thought that maybe that would allow for greater resolution when in step mode. Having it clarified that it doesn’t meant I could weigh up my options better (dismiss any false hope of higher resolution). And the Pyramid still came out on top. Greater resolution (for both note offset and note width/length) would be at the top of my wishlist for improving the Pyramid (although I doubt it would be a likely upgrade). Anyhow, after consideration I felt I should be able to find reasonable workarounds if the resolution was ever an issue for me. What the Pyramid offers my set up should more than compensate. So I went ahead and took the plunge. After the little test plays I’ve had so far it looks like it will be a good move. The UI and MIDI effects seem better than I’d dare hope. I can’t wait to get it plumbed in properly.

yeah,96 ppqn (rounded to 100ppqn for nice numbers :wink: ) is around 5mSec or musically a 1/400th note… so yes, for most musical needs its fine.
for sample level manipulation, I dont think id use midi offsets to handle the issue … rather get the notes aligned to where they should be musically, then delay the sample to handle sync issues.
but we all have different workflows/requirements and tools available.

bear in my increasing resolution is not just a UI thing, it comes down to ensuring you can send out the midi at that higher rate… so its clocked higher.
given limits already on the pyramid cpu, I suspect thats not going to be possible.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.