About Parts and Sequences

[muzycian]

About the Composer and Sequence Editor Time Bar

In other threads on this forum, people wrote that they want the Sequence Editor to use the same time bar outline than the Composer.

When a sequence Part starts on 9.1.0000 and you open the sequence editor for it, MU.LAB currently shows a time bar starting at 1.1.0000 because that's the start point of the Sequence.

Now people requested that then the time bar should start with 9.1.0000 too.

In essence, it's just another logic.

And i understand the requested logic because it may be more easy, at first sight.

BUT:

Imagine we use the requested system.

Then when we open the sequence editor for the part starting at 9.1.0000, then the sequence editor time bar should say the same.

But when the sequence has a start locator that is not at the beginning of the sequence, then this system already doesn't fit anymore.

Because when you set the play position at 9.1.0000 and the sequence start locator is at 3.1.0000, then when opening the sequence editor, the play cursor would be at 11.1.0000 (9 + (3-1)).

Then you could say: mu.lab has to take the start locator into account too.

But note that once a sequence is looping, there is an inevitable difference between the composition time and the sequence time anyway.

So i'm asking myself wether all this work makes enough sense.

As it is now, it's the same as in Ableton Live: if you edit a sequence, you see the sequence time bar.

And the very start of a sequence is always at 1.1.0000

In most editing situations, this is absolutely ok.

I agree that in certain more complex situations, the difference between the composition time and sequence time could be a bit confusing.

But in such case: just put the composition play position at the right place, go to the sequence editor, and you will see the play position line at the correct place within the sequence

About the Sequence Locators

Currently a Sequence has 2 locators: Start and Loop.

When splitting a Part, a Part uses an internal "offset" parameter which is the offset within the sequence, starting at the sequence start position.

This offset parameter is a part parameter, and is currently not editable (i agree it should be though, at least in some way). It's only used when splitting parts.

pljones wrote:

Currently, it's acting like the Part is being split, which means you have two parts pointing at the one sequence, with each part addressing the sequence appropriately.

If I used the same sequence in two parts already, then split one of the parts, I end up with three parts but still one sequence.
Opening the full sequence in the un-split part and editing it there will affect one or other of the split-parts (depending where I edit).

Of course.

You always have the choice to create and use a fresh new independent copy of a sequence via the "Duplicate Sequence" function.

Why should a split make an new sequence?

It's exactly for this reason that the above "Offset" parameter has been created.

To avoid having to create a new sequence for every sequence part split you make.

I want to tell the part where:
1. in its sequence to start playing
2. in its sequence to stop playing (see below)
3. its loop start point is (if appropriate)
4. its loop end point is (if appropriate)
Each part should have those attributes independently of the sequence being used.

The essential conceptual question i have here is:

Should a sequence loop be part of the Sequence itself or of the Part?

If i have a nice drum sequence using a sequence loop.

Then i copy a part using this sequence to another part, without duplicating the sequence, thus i really want the same sequence to be used.

Then i edit that drum sequence including editing the loop, e.g. i could expand the loop.

Then the question is: should the other part using this same sequence also be affected by the new loop or not?

In both the "Yes" and "No" situations, there are advantages and disadvantages.

But summarizing all thoughts, i would choose for the "Yes".

Because you always have the option to use "Duplicate Sequence" if you want another, independent version of that sequence!

Conclusion

MU.LAB is very flexible with sequences.

Almost all options are covered.

Unfortunately, this flexibility seems to cause some complexity and related confusion.

Feel free to drop your opinion on this topic!

Together we may find an even more finetuned system.

[deleted]

DELETED

[Bonteburg]

ouf Jo!
Mother of all posts.

Don't have the time to read it all rigt now but a few remarks:

-I wasn't even aware of the issue until now, so I guess Jo's logic flows pretty ok with me.

-MU.LAB is (to my mind) a pattern based sequencer, so the "131-2-3-4 ... 132-2-3-4" -paradigm makes perfect sense to me, and it's even imperative that it stay, if MU.LAB want's to continue to be as refreshingly different as it is.

Marco

[tonAP]

[Edit] Deleted: wrong thread[/edit]
-
Obviously it should be post on "bugs and observations" thread
maybe better I'll delete it here and re-post there?

[muzycian]

Yes please post it in the other thread; thanks!

[tonAP]

Yes please post it in the other thread; thanks!

Done

[pljones]

You quoted my explanation to Jonny Pumphandle of the current way MULAB works when splitting a part. I don't have a problem with splitting, other than the odd glitch. It's logically correct that all edits to a sequence should apply to all parts that use that sequence and that splitting a part retains the references to the same sequence unless you duplicate the sequence.

To be clear, I think the essence for me is that a sequence is something I could dump to a .mid "as is", whilst a part is all the "meta-information" telling MULAB how to deal with its sequence -- that is, different parts can treat the same sequence differently.

So, we get to the question: what's in the part and what's in the sequence...

Given that the part applies the start and end point, it seems only consistent (to me) that the part apply the loop points. And, I just can't conceptualise loop points as part of the sequence. (Nor with audio: I consider the "acidized wav" a terrible thing .) Now of course, if you're into loops (and I know you are, Jo), then you might have a very different approach.

You ask on playback, how should an "unrolling looped part" appear in the sequence editor.

Between part start and loop start, the time bar on the sequence will match the current play position. The first time through from loop start to loop end, the time bar will simply continue. When loop end is hit and the play position returns to loop start, the part of the time bar between loop start and loop end will show the new timing - i.e. continue to show the current play position (so there will be a "discontinuity" between just before the loop start and the loop). I can't see anything confusing about that myself but I can understand it could be disconcerting.

[muzycian]

You quoted my explanation to Jonny Pumphandle of the current way MULAB works when splitting a part. I don't have a problem with splitting, other than the odd glitch. It's logically correct that all edits to a sequence should apply to all parts that use that sequence and that splitting a part retains the references to the same sequence unless you duplicate the sequence.

Sorry, it seems i misunderstood there.

Ok, this quest is solved then.

(note that i plan to add extra features for the splitter tool: eg if you hold shift, the right split is a duplicated sequence. cfr shift+control = copy+duplicate)

So, we get to the question: what's in the part and what's in the sequence...

Indeed.

Given that the part applies the start and end point, it seems only consistent (to me) that the part apply the loop points.

Mmm, that are 2 different things imo:

the part start + end are the *part* start + end, so that still has nothing to do with the sequence.

And, I just can't conceptualise loop points as part of the sequence. (Nor with audio: I consider the "acidized wav" a terrible thing .)

Are you serious?

You can't deny it's a good thing to store the important markers of an audio file together with it. It's almost part of the audio itself, imo.

When MU.LAB will have a sampler, it will use samples.
Locators will also be defined at that very sample level!

Regarding sequences: an example:

Imagine you import a midi sequence containing a drum sequence.
Now you isolate a nice sequence loop within that drum sequence.

Now you draw a new sequence part, and you choose the same sequence.

Would you be happy that you would have to re-set that same loop for that same sequence then?

(because if the loop is on part level, you would have to set that same loop again)

Now of course, if you're into loops (and I know you are, Jo),

Euh, why do you think so?

Fyi: i use this principle: everything can be a loop. it only depends on how long you set the loop length. so if you're into straight sequences (ie non-loop), then just indicate that the loop length = oo which practically translates into no loop.

then you might have a very different approach.

You ask on playback, how should an "unrolling looped part" appear in the sequence editor.

Between part start and loop start, the time bar on the sequence will match the current play position. The first time through from loop start to loop end, the time bar will simply continue. When loop end is hit and the play position returns to loop start, the part of the time bar between loop start and loop end will show the new timing - i.e. continue to show the current play position (so there will be a "discontinuity" between just before the loop start and the loop). I can't see anything confusing about that myself but I can understand it could be disconcerting.

I see the picture.

And i agree, this system could cause a confusing feeling too.

And so i'm not convinced that all the dev work is worth it. Also because i've the impression that only part of the users have an issue with the current system.

Anyway, i'm looking forward to continue the discussion.

[pljones]

Are you serious?

You can't deny it's a good thing to store the important markers of an audio file together with it. It's almost part of the audio itself, imo.

When MU.LAB will have a sampler, it will use samples.
Locators will also be defined at that very sample level!

Regarding sequences: an example:

Imagine you import a midi sequence containing a drum sequence.
Now you isolate a nice sequence loop within that drum sequence.

Now you draw a new sequence part, and you choose the same sequence.

Would you be happy that you would have to re-set that same loop for that same sequence then?

(because if the loop is on part level, you would have to set that same loop again)

Yes, I'm serious.

If I replicate the Part, then I expect to get the same start/loop/end and sequence. I expect to be able to change the part/loop/end and sequence for a Part. The start/loop/end are tied to the Part, not to the sequence. The start/loop/end and sequence are both attributes of the Part.

So if I draw a new Part, then I expect to set new start/loop/end points and have to set the sequence for the part.

Yes, I expect to be able to save meta-information about how I'm using a sequence but I don't consider it part of the sequence. I expect to be able loop audio files whether they're in WAV, AIFF, MP3, OGG, uLaw 8-bit raw, or whatever. The loop information isn't audio data. If it has to sit in the audio container, you're constrained as to what formats you can loop. I threw uLaw 8-bit raw in there because it doesn't come with a "container format" that allows for meta data, like the others. Putting the start/loop/end in the Part means it works the same - not only across audio formats but between audio and event sequences. Less complex .

What you're suggesting sounds like you're adding another conceptual layer: Part, Sequence, content. The Sequence is a meta-data container tied to its content, except that you can duplicate it and refer to the same content. So:
> Many parts can refer to one sequence. They'd all share the same start/loop/end points.
> Many sequences can point to one content (be it audio or event). They could each set their own start/loop/end points but editing the content (audio or events) would affect them all.

That sounds overly complex to me for what's needed. If the part owns the start/loop/end, then there's no need for a layer between the content and the part (other than as a "raw" container).

[muzycian]

Yes, I'm serious.

If I replicate the Part, then I expect to get the same start/loop/end and sequence.

Of course, no discussion on this.

So if I draw a new Part, then I expect to set new start/loop/end points and have to set the sequence for the part.

I doubt if everyone agrees on this...

Anyway, it's very difficult to make the right choice here.

Both systems have advantages and disadvantages.

But as you are defending 'the part-level', just for discussion sake, i defend the sequence-level (which does not logically mean it's my personal favorite; first of all, i try to highlight all aspects, like you do).

So:

One of the things i very much like to do is switch sequences while a part is running, just to check which one sounds best.

This can be done via the Part Property Panel.

Now if the start/loop/end is on part level, this doesn't work as i'm loosing the sequence loop info as there is no sequence loop info, which is Essential imo.

Oh dear, in muzys, the situation was simpler: a part nor sequence didn't have a start/loop/end, as the start of the sequence was always the start, and the sequence length was always the loop length. (which could be oo if you don't wanted to loop the sequence).

Mmm, it was lovely simple.

But i had 1 problem with it: when splitting parts, a new sequence had to made, no choice.

So, purely continuing this brainstorm, maybe best of all worlds would be to use the muzys approach, but keep the 'start/offset' parameter on part level, which can be used in splitting situations.

<edit>
I'm fooling myself: the muzys approach IS a sequence loop on sequence level. It was just more implicit.
</edit>

What you're suggesting sounds like you're adding another conceptual layer: Part, Sequence, content. The Sequence is a meta-data container tied to its content, except that you can duplicate it and refer to the same content. So:
> Many parts can refer to one sequence. They'd all share the same start/loop/end points.
> Many sequences can point to one content (be it audio or event). They could each set their own start/loop/end points but editing the content (audio or events) would affect them all.

That sounds overly complex to me for what's needed. If the part owns the start/loop/end, then there's no need for a layer between the content and the part (other than as a "raw" container).

I see it otherwise:

A sequence is an object playing a certain riff.

If i select sequence "A", then i always want to get the same result.

I do like (yes, also personally ) the independentness of a sequence towards a part!

In other words: the objectivity of a sequence towards a part.

And that's why i like the sequence loop to be on sequence level.

Although i admit some imperfections:

-> currently the loop is on sequence level, but the start/offset (used in split situations) is on part level

-> for audio parts, the start is on part level

-> for samples, the sample object itself will define a set of locators, but it's the upper level (the sample player object) which will define the start/loop/end points, by choosing out of the sample locators. but point is that it's the 'upper' level which defines the practical start/loop/end.

As you see there is a different approach for audio as for sequences.

The very reason for that is that sequences can be duplicated very easily (if you want another loop), it doesn't take much memory. For audio this is differnt of course. It would not be ok if you had to duplicate an audio file or sample just to loop another section of it.

If we would use the muzys approach of sequences (with an additional start parameter on part level), everything may fit together...

But then we loose the Loop/End locators in the sequence editor, which are definitely a fun thing...

<edit>
As said in the edit above: in fact, the muzys approach IS a sequence loop on sequence level. It was just more implicit. So it would not be the right conclusion/solution to give up the current Loop/End system. Not ending the discussion wether it's best on part or on sequence level.
</edit>

As said in the other thread: Surprised that it's such a difficult topic. But definitely making sense.

[pljones]

One of the things i very much like to do is switch sequences while a part is running, just to check which one sounds best.

This can be done via the Part Property Panel.

Now if the start/loop/end is on part level, this doesn't work as i'm loosing the sequence loop info as there is no sequence loop info, which is Essential imo.

Okay... I think I begin to understand. If you've got a 16 bar phrase and you drop a two bar riff onto it, it should repeat 8 times. If you drop a 4 bar riff in, it should repeat 4 times. Like you say, in Muzys, we had the "length" -- but yes, that was just the distance between the Start and Loop markers on the sequence...

Mmmm....

[davidweese]

OK I have to weigh in on this!

Everyone has valid points, but what is the general case, and what is intuitive? The whole idea of MuLab is to make music FUN and simple, and confusing paradigms are not simple.

With that I say the following :

1. If you are going to have a user selectable start / loop point in a sequence, then it makes absolutely NO sense imo to only have one of them allowed!!!!! The whole concept assumes the user is using the sequence to ORGANIZE MUSICAL IDEAS FOR LATER REARRANGEMENT. Presumably you would use different PARTS of the sequence as variations in different parts of the song......yes?

Ok, fine, when would I ever use this? Well, I might have a 16 bar drums beat I vamp over 4 times to create 4 variations of a bass part, let's say.

So, as a newbie, the obvious thing to do, since the whole idea is that sequences are these loopable entities, is to LOOP! For me, that means let the 16 bar sequence play 4 times, jamming over it each time.

OOPS. The entire paradigm just fell apart becasue this concept doesn't even apply to looped takes...or does it?? nope, all four takes become one 16 bar cacaphony with all passes combined in one sequence/clip. yuck.

BTW this would be useful IF I could hear each of the stacked passes as it loops! Like for a drum part, pass one is hi hat, pass 2 is kick, then snare, etc.

Why the heck not just let parts have a simple offset parameter per part??!?

If so, then you have this :

1. Sequences and parts are the same UNLESS the part has an offset/loop point
2. The offset/loop point IMHO can ONLY make sense as a parameter of the part
3. Any part whould be able to select ANY start/loop point they want, just like Muzys did wave loop points - it's JUST an offset from the true start of the sequence - what is the big deal??!?
4. If the sequence maintains a master list of start/loop points set by a part, fine. It's a list. Again, no big deal.
5. Just make the START/LOOP setting for the active part one color, and all non-active ones (relating to the sequence) a different color in the sequence editor. Preferably the unused ones for that part would NOT BE SELECTIBLE!!!! Think of all the users who would acidentally change a start point that affected many other parts! On the other hand, a right mouse click menu to proactively change the active start/loop for that part is fine.
6. The sequence editor should certainly show BOTH the timeline of the sequence AND it's positon of the specific part in the master timeline. The simple fact is people don't JUST treat sequences as standalone musical pieces. They are used and edited in a CONTEXT. And as much as the current behavior might make sense, the fact is, it's confusing, and that's very bad for MuLab.
7. Of course if you draw a clip and you select a sequence for it, the sequence should loop to fill the part, and being able to select a start/loop in addition to the sequence just makes sense.

As I said in another post, the programming principle of "least surprise" needs consideration here. What would the average person expect? Advanced capabilities like offsets are just that - ADVANCED. The average new user (which is, by definition, EVERYONE who uses MuLab!) has GOT to expect that the sequence editor simply shows them their sequence data, period.

Anything more complicated should be a pleasant surprise one can DISCOVER when the creative muse calls for it. The fact that the start point is THERE at the first beat is a simple, obvious clue that (A) anyone can understand, and (B) few people will actually use for the reasons explained in the 4 pass scenario above.

That scenario ONLY works and makes this feature useful IF you started by stretching the drum loop out to 64 bars, right? Otherwise your new sequence cannot effectively be broken up into 4 variations.

Jo, why and how would you ever use or want a single start/loop point? Are you assuming that if you wanted a different one you would make a unique copy of the sequence? Help me get this!

Forgive the following diatribe :

THE AVERAGE PC USER HAS NO CLUE WHERE ANY OTHER FILES ACTUALLY RESIDE OR WHAT A SHORTCUT ACTUALLY IS. Why? Because IMO the most diffcult concept for people to "get" is INDIRECTION. That's why programmers have a hard time with pointers. Start points and loops within a single entity (a part) but actually within an entity that CONTAINS that entity (a sequence) is, in essence, TWO LAYERS OF INDIRECTION.

Powerful? Perhaps, but intuitive? no way. Useful? Only marginally, but perhaps for loop oriented users, and that's cool. But it's a perk, y'know?

UPDATE

OK I get it. Doing it my way, if you change the start/loop on a non-unique part, you would need a pop up that asks you if you want to make this one unique. That's getting hairy.

So I recant. One start/loop is ok. Or is it? Jo, is this right??! The idea is to do a variation, you create a unique copy of the part and set a new start.loop in that part? Ahh, you are creating a new SEQUENCE at htis point, no?

But it's still confusing because if you draw a part too big, and choose a sequence to loop in it, how does it know which one to point to??!?

[muzycian]

Jo, why and how would you ever use or want a single start/loop point? Are you assuming that if you wanted a different one you would make a unique copy of the sequence? Help me get this!

One of the things i very much like to do is switch sequences while a part is running, just to check which one sounds best.

This can be done via the Part Property Panel.

Now if the start/loop/end is on part level, this doesn't work as i'm loosing the sequence loop info as there is no sequence loop info, which is Essential imo.

For me, a sequence should be a 100% self-contained piece of music.
(i'm talking on midi event level, not about the target/plugin level)

If i select sequence "A" in this or that situation, i always want to get the same sequential result.

At the other hand, the main purpose of a Part is:

-> a building block in a Composition (i.e. something is playing From...To...)
-> select a Target for the content
-> eventually define some extra parameters (eg. an offset within the content because the part has been split)

I don't want Parts to be equal to Sequences.

Because then you can't work with multiple parts using the same sequence, which is one of the essential ways of working. The opposite (each part uses an unique sequence) being equally essential. I want MU.LAB to support both systems. So the 'indirection' / 'extra level' is needed. No doubt about that.

The question on table is: who should define the sequence loop: the part or the sequence?

Again, this is a very difficult discussion as there are arguments for both ways.

But i tend to conclude that it is the sequence.

If you want the same sequence but with another loop, then you indeed have to duplicate the sequence. Which is quite logical as it will sound different!

If the sequence loop would be defined by the part, then you can never simply point/select/use e.g. That Hihat Pattern, as it would always depend on the part. You would have to point/select/use e.g. That Hihat Pattern In That Part, which is a more complex concept, imho.

Though i don't have a 100% convinced feeling on this...

Damn... So difficult...

[davidweese]

Because then you can't work with multiple parts using the same sequence, which is one of the essential ways of working. The opposite (each part uses an unique sequence) being equally essential. I want MU.LAB to support both systems. So the 'indirection' / 'extra level' is needed. No doubt about that.

Ok...I see. I had a lot more to say, but now I get it.


All sequences are of infinite length, and by zooming in the seq editor you can change the loop period. Ahhhhhhhhhhhhhhhhhhhhh!!!!!! It finally dawns on me!

To insert bars, move all the data and/or change the start/loop points...eureka!

OK I am stupid, you are smart. I go shut up now.

Sorry to stress you out with this debate. I will do a video about this soon.

Dave

[davidweese]

OK. I did a YouTube video that explains what's going on with parts and sequences. Please see it at the production blog, www.natalieweese.com.

I also updated the production blog with and article about my VST kit, since most of what I use is free.

Dave Weese