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