MIDI Notes not sustaining beyond end of clips

[pdxindy]

Because the clip launcher is a non-linear improvisational tool...

And that's exactly why allowing notes that extend beyond the clip end would be an awesome feature: it would allow in the launcher something that is impossible to achieve today. For example, you could have loops where each notes overlaps with the next one (e.g. to create an endless glide on an arpeggio), including the last one overlapping the first. With current Bitwig limitation this is impossible, no matter how you configure the loop settings.

The only difficulty with respect to the clip launcher would be to decide what to do when switching clips. But a simple rule can solve the problem: cut the notes if the switch is mid-clip (as is done now), but let the notes play their intended length if the switch is done at clip end.

(It is not impossible to achieve that today. Use 2 tracks)

The thing is, you do not know what clip follows. You can jump to any clip, or switch scenes. It is not just one simple rule. You will end up with a set of rules where notes sustain and where notes do not sustain. Users will have to remember those rules to work with them. It hinders spontaneity by adding complexity.

How would you handle automation? Suppose there is modwheel automation that is affecting the note that sustains. But while that note is sustaining, the clip has looped and the modwheel value jumps to its initial state at the start of the clip. As the clip loops, the sustaining note would jump to a new sound if say the modwheel was controlling filter cutoff.

What you are asking for mostly works when you know what is going to happen. If you know exactly what you want to happen, just use Arrange.

Another thing, in adjusting length of clips, you will not be able to just drag a clip edge to the left without also having to go in and edit the midi notes if you do not want those notes to sustain unexpectedly.

IMO, too much added complexity for too little benefit. Fortunately, I feel confident there is almost no chance of the Devs doing something like this. But if they did I would want the option to leave it as is.

[fuxoft]

I I certainly DON'T WANT any part of MIDI note to extend past the bounds of the clip it belongs to.

Then don't puts events in your clips that do - that's quite simple and has no bearing on what we are asking for.

What you ask for is that when I am recording, slicing, moving and copying clips between dozens of tracks, there may arise - by various combination of coincidences and mistakes on my part - a situation when MIDI note is held during a time when there is no visible clip in the timeline. Am I getting that right?

This is something that I want to avoid at all costs, no matter what I do, for various reasons that I could try to explain but I don't really want to because, clearly, they are subjective. You want it because it suits you. I never ever want it to happen, whatever stupid thing I do.

[slackhead]

You want it .... I never ever want it ....

You can never make everyone happy. But a configurable option would go some way

[fuxoft]

You want it .... I never ever want it ....

You can never make everyone happy. But a configurable option would go some way

Yes, exactly! I don't want to convince you to change your opininon. I just wnat the developers to know that this is not 100% universal request.

[pdxindy]

Because the clip launcher is a non-linear improvisational tool...

And that's exactly why allowing notes that extend beyond the clip end would be an awesome feature: it would allow in the launcher something that is impossible to achieve today. For example, you could have loops where each notes overlaps with the next one (e.g. to create an endless glide on an arpeggio), including the last one overlapping the first. With current Bitwig limitation this is impossible, no matter how you configure the loop settings.

It is not impossible...

You can already sustain a note in a looping clip. The loop point has to start later than the clip start so you can only loop a section. I only use it for creating an endless drone note(s) but you could do something like this:

http://draigathar.org/sounds/sustained-notes.mp3

[pdxindy]

You want it .... I never ever want it ....

You can never make everyone happy. But a configurable option would go some way

no thanks... it's a waste of development time

the idea does not really make sense... it requires one to already know what one wants to do, in which case you may as well use Arrange in the first place... which will be easier.

[Groundhog #31684]

@pdxindy: it's only a "waste of development time" because you don't want it. A bunch of your wishes would be a similar "waste of development time" to somebody else.

Having notes playing beyond clip boundaries also extends to just a little bit. The difference between robotic and not. You seem to be intentionally over complicating things because it's pretty simple for people who would use it and would be off by default for people who don't.

The only desirable option would be whether any note of equal value/channel that is played while a sustaining note plays is retriggered or extends the current note.

[drakmaniso]

You can already sustain a note in a looping clip. The loop point has to start later than the clip start so you can only loop a section.

Ok, I had completely forgot that this actually works. This is by far the simplest workaround for the looping case.

The rule seems to be the following: at the end of a clip, notes are truncated, unless the clip is looping and the same note is overlapping the loop start. A bit convoluted, but it works.

The thing is, you do not know what clip follows. You can jump to any clip, or switch scenes. It is not just one simple rule. You will end up with a set of rules where notes sustain and where notes do not sustain.

No, the rule I propose is very simple: if the clip reaches its end, then all the currently playing notes are held during their intended length, no matter what follows. Another way to put it is that notes would be truncated only when the clip itself is truncated, which I find simpler than the current rule.

How would you handle automation?

Automation would not be impacted. Just like notes starting after the end of clips are ignored, any automation changes after the end should also be ignored. Note lengths are different because they can be considered part of the note itself; so if a note started inside a clip, its length should be part of the clip too. The current behavior of Bitwig is linked to the "note off" abstraction, which is a technical necessity to record live playing; but nothing prevents from translating this to a different abstraction afterward.

I get that many are used to the current behavior (and I'm aware that it's highly improbable the feature will find its way in Bitwig). But that doesn't mean there is any conceptual or technical impossibility.

[pdxindy]

Automation would not be impacted. Just like notes starting after the end of clips are ignored, any automation changes after the end should also be ignored. Note lengths are different because they can be considered part of the note itself; so if a note started inside a clip, its length should be part of the clip too. The current behavior of Bitwig is linked to the "note off" abstraction, which is a technical necessity to record live playing; but nothing prevents from translating this to a different abstraction afterward.

I get that many are used to the current behavior (and I'm aware that it's highly improbable the feature will find its way in Bitwig). But that doesn't mean there is any conceptual or technical impossibility.

Automation is impacted... the automation will jump from the end of clip state to beginning of clip state as the note sustains which will change the note abruptly. Sure it can be worked around, but it is more added complexity.

I think the proposed functionality will add a lot of complexity that is not visually obvious and can already be accomplished as is when needed.

[pdxindy]

For example, you could have loops where each notes overlaps with the next one (e.g. to create an endless glide on an arpeggio), including the last one overlapping the first. With current Bitwig limitation this is impossible, no matter how you configure the loop settings.

A looping legato glide already works just fine. If a note extends past the clip end, it will glide with whatever note follows if the clip loops or goes to another clip.

This is an example of feature frenzy... people asking for features before even learning what is there already.

[Dehenry]

the idea does not really make sense... it requires one to already know what one wants to do, in which case you may as well use Arrange in the first place... which will be easier.

It generally helps to know what you do next, especially when performing music. You have to know if the next clip fits the previous in term of key, mood, release time of instruments of the previous clip etc. That's a "burden" that no DAW can take over for you and that's what making music is about. I don't understand what the problem is with remembering if a clip has sustained notes or not. If you don't want sustained notes, simply record them shorter. If you have recorded sustained notes in error, the natural reaction would be to shorten them, but not to request that the DAW generally cuts them off. That's a bit like "I don’t like the note a sharp, so Bitwig should always ignore that note".

Anyway, I would be more than happy to use the Arrange instead of the Clip Launcher to avoid the problem, but notes are cut off in the Arrange as well.

I find this whole discussion about huge problems being caused by sustained notes etc. a bit theoretic. Again, just look at Logic and Cubase, they have solved this "problem" ages ago, and Logic even has something that is quite similar to a clip launcher (not sure about Cubase because I don’t use it). You could even consider it more "problematic" than Bitwig's Clip launcher because with Touch Tracks you can launch clips without any launch quantization, and guess what – it does not cause a disaster, not even a problem...

[pdxindy]

Anyway, I would be more than happy to use the Arrange instead of the Clip Launcher to avoid the problem, but notes are cut off in the Arrange as well.

The only situation where that happens is when you punch-in/out. Otherwise in the usual recording situation, everything you play is recorded and played back and nothing is cut off.

And it's quite easy to work around for punch-in/out.

[pdxindy]

The thing is, you do not know what clip follows. You can jump to any clip, or switch scenes. It is not just one simple rule. You will end up with a set of rules where notes sustain and where notes do not sustain.

No, the rule I propose is very simple: if the clip reaches its end, then all the currently playing notes are held during their intended length, no matter what follows. Another way to put it is that notes would be truncated only when the clip itself is truncated, which I find simpler than the current rule.

I more often trigger a clip change at the end of the clip... and I might change to a clip that would not sound good with a sustaining note from the previous clip... or it might.

In that scenario I could create 2 clips one that sustains and one that doesn't... but then I do not necessarily know which I want at the time of choosing. This suggestion boxes you in and there is no way to stop a long sustaining note without interrupting other stuff. (Plus there would be no visual reference whether a clip sustains or for how long)

The way it currently works is already better than that IMO. What I do is have a group and inside 2-3 tracks with clips that all send midi to the synth on the group track. With that setup it is easy to create sustaining notes as it loops, poly-rhythm sequences, etc etc. You can bring any clip in and out and decide on the fly to let some notes sustain or not as you bring some other tracks in. Open ended, flexible, visually clear (and easy to edit in the multi-clip editor).

To me, this suggestion comes from linear DAW thinking but it becomes an imposition on the fluidity of the non-linear environment.

And I would hate to not be able to make a clip shorter without also having to go in and truncate any notes that might now sustain... (<--terrible)

btw, it is interesting to consider it and I appreciate that you are actually discussing how this stuff works

[drakmaniso]

I more often trigger a clip change at the end of the clip... and I might change to a clip that would not sound good with a sustaining note from the previous clip... or it might.

Then it's very simple: do what the current Bitwig behavior force you to do, cut all the notes at the end of your clips. Obviously this can be done automatically, a simple checkbox in the settings would take care of that. That would make no difference for you.

The thing is, the feature discussed here only add new possibilities, and doesn't remove anything. Those used to the current behavior would still have it work exactly the same.

[Coockie1176ln]

Havent followed the subject and since i wrote far to much has bern written hehe. So i havent read what been said. But i go to point

Having loop that will include start of clip will basically mess up bitwig loop note function. If you include start of clip but set loop point before end of midi length and before start of midi, then you have endless midi playing. Cant have both because then one will mess with the other and vise versa