Sequence chopping...

[mutools]

If you can show me the benefit of having a sequence that has a loop identifying 3 notes... while showing me 6 notes to the left (in grey) and 4 notes to the right (in grey) when I only want the 3 notes? Let's see...

The answer is simple: If you don't want these notes to be there, delete them

(and as messaged before: I'll add a "Trim To Played" function that speeds up doing so)

[mutools]

+1 I liked the way Muzys had that R-click Toolbox.

yep, was using muzys the other day and like used in cubase/logic right click toolbox is good system to my way of thinking. can't see jo going back to toolbox though, and menu shortcuts in mulab just as good though when comes down to it.

Indeed.

By the way, i don't understand what that toolbox system has to do with the sequence part split topic we're talking about. I'm not complaining that something would be off topic, no, i just don't understand the association.

[mutools]

Wrt the split function: One thing i'm considering is that if the user splits a unique sequence part then the new splitted part (the right one) is also a unique part. That sounds like logical, consistent and intuitive behavior indeed.

Does anyone think that would be unexpected behavior?

Of course this will not be the case when splitting a shared sequence part. In that case the new split part will also share the same sequence. And if you don't want that -> "Make Unique". And if you don't want any extra remaining events which are not played -> "Trim To Played". (wishlist function)

Sounds all very neat to me.

[plutonia]

DHR53, I guess it can be hard to adapt to a new way of thinking about a task when you start using a new tool. But trying to judge the tool and make statements about it having shortcomings based on how you think it should work is just not a good way to adapt to the tool. It just helps encourage a fixed mindset. Focus more on the musical result you're after and don't worry so much about the details.

At least +1.

(i would like to say +10 but my rational side prohibits me that)

i don't agree with you tone here. this particular tool and function is flawed and not conducive to fast workflow in my opinion and accusing dhr53 of i fixed mindset isn't helpful;he, like myself, is frustrated that you seem unable to see that this function isn't implemented in a useful or sensible way that allows the user to quickly create and edit their music in note form and allow the musical result they want to be realised. if the tool is well implemented the user doesn't have to adapt to it's shortcomings which is the point we're both making.

jo, telling him to 'delete the notes' if he doesn't want them there isn't helpful either and just highlights that the function is slowing down dhr53's workflow.

[mutools]

DHR53, I guess it can be hard to adapt to a new way of thinking about a task when you start using a new tool. But trying to judge the tool and make statements about it having shortcomings based on how you think it should work is just not a good way to adapt to the tool. It just helps encourage a fixed mindset. Focus more on the musical result you're after and don't worry so much about the details.

At least +1.

(i would like to say +10 but my rational side prohibits me that)

i dont agree with you tone here.

I had that feeling yesterday already i.e. that DHR might be overfocusing on something. That's why i yesterday also wrote: Don't forget to focus on the Music. Now pljones writes something similar, and i express my +1 for that. Then what's wrong with my tone?

this particular tool and function is flawed and not conducive to fast workflow in my opinion and accusing dhr53 of i fixed mindset isn't helpful;he, like myself, is frustrated that you seem unable to see that this function isn't implemented in a useful or sensible way that allows the user to quickly create and edit their music in note form and allow the musical result they want to be realised. if the tool is well implemented the user doesn't have to adapt to it's shortcomings which is the point we're both making.

Already from the start of this topic i'm constructively reasoning with you. I already made several proposals to optimize things. Feel free to reply on them.

Again, the very first thing we must agree on (or not) is that being able to use shared sequence parts is a feature, not a flaw.

If you don't agree with that (which is your freedom of course, no bad feelings) then conclusion is that MuLab is not the best tool for you. In the other case we can continue reasoning about how to optimize things, like i did up to now.

[mutools]

jo, telling him to 'delete the notes' if he doesn't want them there isn't helpful either and just highlights that the function is slowing down dhr53's workflow.

And that's why i think pljones wrote something about the fixed mindset (correct me if i'm wrong) because those notes don't hurt at all, and they don't slow down workflow at all.

And even then, i already proposed to add a "Trim To Played" function.

The split function may be optimized indeed, i do understand the critic there, and so i've also already proposed several things. What's your opinion about my proposals?

[mutools]

jo, telling him to 'delete the notes' if he doesn't want them there isn't helpful either and just highlights that the function is slowing down dhr53's workflow.

I hope you didn't interprete that reply of me in another way than i meant it. I really mean that if a user don't want certain notes, then simply delete them. I did not mean that in any other way.

[Crackbaby]

Wrt the split function: One thing i'm considering is that if the user splits a unique sequence part then the new splitted part (the right one) is also a unique part. That sounds like logical, consistent and intuitive behavior indeed.

Does anyone think that would be unexpected behavior?

Seems logical indeed

Remember we're more than one user here.. what one user sees as a flaw might not bother ANYONE else Unless you make a customized version for each user, you cant satisfy everyone.

[Hermu]

for me, there are some discrepances in sequence part splitting which are not really logical.

1. sequence part resize has the same result as splitting a sequence part and deleting the right one.
i expect after splitting a sequence part and deleting the right one that the right one is really deleted.
but if i open the MIDI Editor the deleted right one will also shown.

sequence part resize has the same result.

2. splitting a sequence part and deleting the first one and move to left leads to minus beats.
what should we do with minus beats?
why is the sequence part not adjusted?

if i delete a sequence part, i expect the deleted part is really deleted.

[plutonia]

jo, telling him to 'delete the notes' if he doesn't want them there isn't helpful either and just highlights that the function is slowing down dhr53's workflow.

And that's why i think pljones wrote something about the fixed mindset (correct me if i'm wrong) because those notes don't hurt at all, and they don't slow down workflow at all.

And even then, i already proposed to add a "Trim To Played" function.

The split function may be optimized indeed, i do understand the critic there, and so i've also already proposed several things. What's your opinion about my proposals?

thanks for further input jo. not quite sure what 'trim to played' means but how about a 'split and make part unique sequence' function. that would mean that when a split was made and the note editor was opened because the part is within what is now a new sequence only the notes in the split part would be shown. mibbe this is problematic to code but if it isn't it would be a more logical way of using the split command i reckon and more what is expected from new users. i still cannot see any advantage or reason for seeing the notes in the entire sequence, as happens at the moment, when i have split it into parts for editing or copying so it may be that it is as it is because of a coding issue.

[plutonia]

for me, there are some discrepances in sequence part splitting which are not really logical.

1. sequence part resize has the same result as splitting a sequence part and deleting the right one.
i expect after splitting a sequence part and deleting the right one that the right one is really deleted.
but if i open the MIDI Editor the deleted right one will also shown.

sequence part resize has the same result.

2. splitting a sequence part and deleting the first one and move to left leads to minus beats.
what should we do with minus beats?
why is the sequence part not adjusted?

if i delete a sequence part, i expect the deleted part is really deleted.

yes, i noticed this before and couldn't work out if it was supposed to work like this. although i've never used it, the ability to create loops within sequences/part is good aditional option though.

[mutools]

i expect after splitting a sequence part and deleting the right one that the right one is really deleted.

It is deleted. The part that is.

but if i open the MIDI Editor the deleted right one will also shown.

You may still see events that belong to the sequence, but they're not played.

Note that automatically deleting any unplayed events is contradicting the shared sequence concept because if a shared part is split and events would be auto deleted in the new split part this would affect the original sequence and thus that sequence part too. That's why i emphasize the fact that before we can discuss this 'split' topic in depth you have to choose whether you agree with the shared sequence concept or not. If yes, we can continue reasoning about possible optimizations. If not, MuLab may not be the best tool for you.

splitting a sequence part and deleting the first one and move to left leads to minus beats. what should we do with minus beats? why is the sequence part not adjusted?

Please elaborate on this situation, i can't immediately repeat this.

[Hermu]

If not, MuLab may not be the best tool for you.

MuLabs split functionality is not realy useable, because the same effect i can get easier with resize.

[mutools]

It depends on what you want to do. I have the impression that you seem to assume that the only reason for a split is to delete the splitted section. There are other reasons too eg move or copy the split, edit the split, ...

[mutools]

If not, MuLab may not be the best tool for you.

MuLabs split functionality is not realy useable, because the same effect i can get easier with resize.

Note that my quote was related to the shared sequence concept topic, not to the split topic.