i know that … what has this to do with my issue?
yes nice, i love that i don’t have stop pyramid … but it doesn’t change my problem
I guess it has nothing to do with your pyramid issue. But it does highlight your personality issue. Good luck!!
thought Id bump this, as 3.1 includes an improvement, that I think makes things a bit clearer now 
when this topic came up before, the more I played with it, the more I found examples where the Pyramid was correctly keeping things in sync, but using a start offset that was a bit confusing (to me)
I reported this to Squarp, and after a few emails, they could see what I meant (its a confusing topic for sure), and seem to have improved things for 3.1 (as far as my testing goes so far) - and makes it more predictable/obvious whats going on…
anyway, whilst playing with this, it dawned on me a good example of why start offset is needed,
which I thought id share, to perhaps help illustrate why start offsets are needed.
(i think the first time we see a track starting in the middle it is confusing… and hard to see why)
the example, is something that we all know, probably from primary school…
the musical round (which is a form of canon) , theres lots of examples, but for me at school it was ‘3 blind mice’, 'row row row your boat, “Frère Jacques” - the form is better explained in the wikipedia article here, than i can do
how does this relate to the pyramid, live looping, and start offset?
lets imagine playing “row row row your boat”, using live looping.
we can see this is a 4 bar loop, the basic concept is each voice comes in offset by one bar (in the above the ‘start points’ are indicated by an asterisk), the phrase is structured means that the offset creates a harmony (see wiki for details)
so as discussed on wikipedia , we play this by:
track one, we start from bar 1,
switch to track 2, play the same 4 bar loop BUT we start playing when the first loop plays "gently down the stream’ (the first asterisk)
switch to track 3, start playing on the second asterisk
switch to track 4, start playing on the final asterisk
ok, so we can see we are playing each track offset.
so now if we stop the pyramid , and then start it again.
for it to sound the same, the tracks need to be offset against each other… start in different places, if there was no offset… then we would just have a chorus/layering effect.
ok, some observations…
-
why is this available for live looping but not programming.
or. “why can’t I change offset when step programming?”
yeah it’d be nice…
for programming what you would do is… copy the phrase from track 1, then rotate it…
thats no real hardship really.
but for live looping, the equivalent would be you having to start playing for different parts of the phrase, thats not very natural at all.
so I guess its would be a nice extra feature for programming, but a pretty fundamental requirement for looping. -
“yes, but what it should do is not play track 2, until the offset” (*)
ok, I agree… thats definitely one option…
currently, the pyramid basically ‘starts in the middle’, with all tracks playing and everything sync’d,
in this case it might be nicer if it used the offset instead to delay the start, and then loop.
… though I suspect this is not alway desirable. -
this could be done by instead rotating the midi notes…
the is really similar to (1) , given for programming this is what you have to do anyway.
I suspect, the reason for not doing this, is it technically requires more cpu to shift notes around, rather than just record an offset.
also, it would be less clear to see the melody shifted, if anything I think this is a good argument for why it would be nice to be able to manipulate the start offset, so when programming we can do this, rather than rotating notes. -
offset is confusing - its relative.
back to the example…
if track 1 has an offset of 0 (bar) , then this means that the offset for track 2 has to be 3 bars…
this is because when track 2 plays "Row, ", then we need track 1 at “gent - ly”, its one bar behind.
so when track 1 starts, we actually need track 2 to in the last bar the phrase.
the interesting thing though is this is all relative. if we play track 2 first,
so it start on bar 0, then track 1 would be offset to bar 1.
note: Im not quite sure how the Pyramid decides which tracks is the ‘lead’ track,I think it has to be the first recorded track, as the offsets are relative to one another, i.e. if you want to keep it in sync, if you change one, you’d have to change them all… so I suspect they set at recording, and never changed.
hopefully the above might illuminate for someone why it’s doing what it’s doing, and why for some us its definitely the right thing… but for sure, I can imagine its not quite what others want… and perhaps a couple of extra ‘features’ could make it more useful/less hinderance to them (in particular the ability to shift the offset)
Note: to be clear this example, is just to show how tracks needs to be synchronised to each other… I dont think many of us are playing these kind of rounds where each track is the same… 
in practice the tracks are different phrases, and different lengths, possible different time signatures - in practice, this could get very complex indeed, but the principle of staying in sync is the same.
5 Likes
I’ve also been hit by this. I agree that one should be able to set the starting point of a track/pattern.
In the heat of live looper recording it’s not always so sure that you get the timing right with regard to other tracks. so sometimes it gets messed and a track starts at a point where you don’t want it to when you press play.
1 Like
have you tried with 3.1? my experience so far is offsets are less likely to occur now.
what I saw with 3.0, is there would be a tendency for an offset to be used, when it was not strictly necessary (this is what I illustrated to Squarp) e.g. on a 8 bar loop, it might end up using a 6 bar offset, but actually none was necessary.
note: it was still correctly in sync, it just it looked more complex than it needed to be.
this is what I think Squarp have changed, I think the offset is chosen a little more ‘intelligently’
however, I don’t know for sure, as the change list is not specific, they may have found other things too - but from my usage of 3.1 so far, it feels like its more logical.
yeah, I think the first role of the pyramid is to play back as you played it , flaws and all 
(which i think it does correctly)
but for sure, I agree it feels like start offset is something should be editable, in the same way as notes are… we play a wrong note, then we want to be able to correct it.
this is an area perhaps overlooked a little…
many of us are using live looping not (just) as a performance tool, where editing is not relevant,
but also as a way of capturing our playing, which we then edit and refine.
so I agree, I think editing start offset would be cool, though no idea where squarp would put it…the UI is already pretty full
4 Likes
I was just making a track with 3.1, and still a live looper recording would sometimes be set to start from some point later in the pattern using 1bar looper mode. had to retry a couple times before getting it right
because there were several different length patterns in the project while i was making it.
Well, just a quick idea for a shortcut for setting a start point: 2nd + play + step
2nd + play seems to do nothing currently and would at least remotely make sense 
And no need for a more complex GUI apart from maybe some popup.
3 Likes
Setting the offset could also be assigned to the euclid buttons because they do nothing in step modes where offset matters. I.e. you’d press ‘EUCLID STEPS’ + a step to set start point of track (or just to rotate notes so they start at that position, it’s the same thing).
Thanks a lot for this clear and efficient explanation. And nice example too ! If anybody has a question about live looping please read this post first !
Actually the lead track is the “sum” of all previously recorded tracks. You are totally right, we changed how offsets are processed in order to avoid offsets whenever possible. More “intelligently” often means easier :). The idea is to stop thinking about it. With PyraOs 3.1 you shouldn’t even notice offsets most of the time and your explanation is perfect for all the obviously offset cases.
Of course we have been thinking about adding a "set entry point" feature, and also to wait before the entry point. Our actual solution is the best we found in terms of resources, playability and possibilities. Your observations are very relevant.
Thanks for your patience and pedagogy, can we use parts of your post in order to better explain how the live looper works in the manual ?
4 Likes
Thank you, nice to know my understanding is correct
Of course, feel free to use whatever you would like.
… and thanks again for the continual improvements to the pyramid (and hermod).
3 Likes
Sorry to give this dying horse one more beating.
I think the most confusing thing here is, that in track mode there is no other “beat progress indicator” than the blocks on the bottom row. now, when i’ve selected a track that has starting point set somewhere else but the 1st step, i have no way of knowing when to mute/unmute for example, but to remember which step it’s starting at on a given track. and since each track seems to set starting point kind of “where ever” when live looping, i’m feeling completely lost and need to switch between step/seq modes to figure out where the song is progressing.
and to make things worse, the progress bar in seq mode is still messed up, sometimes even counting to five when all tracks i have are multiples of four. this needs to be cleared up somehow, one thing especially i’m missing is beat indicator to track mode, but that requires some rethinking since screen space is sparse.
peace.
edit: also, trying to edit or change track parameters or nudging of a live looped pattern that has start point not in the beginning, it all goes to hell. there should be a configuration option to disable this kind of ‘intelligent start point setting’. combined with a lack of real beat indicator in track mode main screen, this is just a huge source of confusion for me at least. it’s a bug, and not a problem with the manual. my 2cents…
2 Likes
I couldn’t agree more.
This is one of my biggest frustrations with the Pyramid. I run into this all the time since I record events predominantly in live mode. I record something in right when it comes around to the 1 and even if the sequences are the same length, things are all out of place when I play it back. The thing I recorded in on the 1, is offset for some reason and starts at the 8th bar now 
I was really hoping for this to be the sequencer to build pieces in a quick, improvisatory flow. But I find that I spend far too much time starting and stopping, erasing that as it isn’t coming in where it seems like it should… The only way I’ve found to reliably get a pattern to start on the 1 is to stop it, then hit record and play. That isn’t exactly “live looping”.
2 Likes
Running into this realization having had Pyramid for a couple weeks.
The way I see it, if there was a way to turn off this “intelligent offset” in live looping mode it would solve everything. You could then go in step mode and shift the pattern if you need to, and not have the start point all screwy, knowing that it was at the beginning like everything else.
The problem with the offset is that if you go through and record a number of tracks back to back, they, by design, will have an assortment of different start points. Im still trying to wrap my head around why this would be a good thing, as per the canon example, but it is an added complexity that would seem to impede anyone coming from a say, an Ableton Live style workflow.
Please make this an option, to turn off intelligent offset in live looping mode. In the live looping settings: Off, On, On+NoOffset. seems like it would be pretty easy to implement to me.
2 Likes
please write the Squarp-Team a feature Suggestion as i did
1 Like
thanks for the tip. I sent a request as well.
This is the main thing that still trips me up when using the pyramid. I love live looping and recording midi in from an external keyboard, but things always end up in the wrong place. an option to turn off “intelligent offset” would make things so much simpler for certain workflows.