All Button in step edit

[anonyme-x22]

Hello,

When pushing all button to modify a common trigger for all note, you need to dial to a note and modify only this note.

Don't know if there is a purpose for that but its confusing and most of the time i add note or modify the not selected one and everything is mess.

I should be interesting to remove this note selection if not worth purpose.

So whatever knob you turn it will modify really all of the selected parameter.

Thanks in advance,

Have a good day,

Rgds,

 

[srmaietta]

All button has a few modes of quickly modifying values, and yes, they generally revolve around the chosen step.  
there is a page/chapter in the beginners guide..

Steve 

http://wiki.midibox.org/doku.php?id=mididocs:seq:beginners_guide:start

[TK.]

To be honest: sometimes I also don't like the more cumbersome handling which was introduced just for the "ramp" function.

I could make the "ramp function" optional, and users who normally don't use it could turn it off in the Options page - do you agree?

Best Regards, Thorsten.

[anonyme-x22]

Exactly, the ramp is never used, except for velocity or cc ramp, which is really not often!

[TK.]

I added an option to disable the features:

   o new option 15/34 "ALL allows relative changes/ramps" can be used to disable these (existing) features
     for users who don't need such enhanced editing capabilities and prefer simplified ALL button handling

-> http://www.ucapps.de/mios32/midibox_seq_v4_098_pre9.zip

Best Regards, Thorsten.

[anonyme-x22]

Hello,

Many thanks, that will really make the device way more fun, and easy to use, as the all will work whatever the cursor is positioned for the current pattern track.

So actually it works but:

There is also another issue with all button which is not related to the ramp, the fact is that if you turn all encoder under a blank step, it will add the step while, whatever the ramp mode is activated or not!

i think it's a bug, all should only affect already existing step because you still have to concentrate yourself in order to do the knob turning on a note!

Futhermore, you can't disable the step once you have rotated the wrong encoder meaning:

- Exit All button

- Remove the unwanted step!

- Select again All button

- Concentrate to be under/find an already set step.

- Update 

Rgds,

Edited April 5 by anonyme-x22

[TK.]

This is no bug, but just the behavior as implemented already in MIDIBox SEQ V2 - it's consistent because regardless if ALL is selected or not, whenever somebody turns a GP encoder the corresponding step will be activated.

But I understand that it would be better to avoid this in ALL mode - this would be a special condition, no "bugfix"

Best Regards, Thorsten.

[anonyme-x22]

Hello,

That's the issue " regardless if ALL is selected or not, whenever somebody turns a GP encoder the corresponding step will be activated."

what use case you put under if all button is activated:

Lets say C3 C3      C3 Four step

- Push all button

- Move encoder 3 : i get C-1, whatever i set the layer to!

So you get the pattern mess with a note you don't want!

As you can see no valid use case for this so it's called a bug!

This said if all button off why not, even if it's not consistent, yes effectively encoder under none could raise the step on!

I don't think it's an option.

The goal of the option "Ramp...." is to avoiding concentrate onto the cursor or encoder when all is pushed, or actually that option, work in half as you steel need to concentrate to which encoder i need to turn = set the cursor under a note in other way!

Rgds,

Edited April 6 by anonyme-x22

[TK.]

Why are you blaming me? I wrote that I could add a special condition (no option) to prevent this.

Best Regards, Thorsten.

[anonyme-x22]

Again, you're wrong, i don't blame you!

I understood special condition as option!

So as option menu is only one level, i think you  understood i don't want to surcharge it!

That just it.

I will never blame, you , just put it like the user point of view and the dev point of view!

My only goal is to advance, not to blame anyone, perhaps i wrote it the wrong way,

But sorry , it has never come into my mind to blame you, it's useless, and as i said respect for you're already work, but improving involve arguing , to reach common commitment, and yes sometimes we can have wrong feeling, like he blame me or what, etc, don't fall here, that's a negative process!

Take it as a dev which handle a user, and we do not speak the same language, so sometimes before thinking the wrong way, most of the time, that's because we did not understood each other!

We have the same goal, making this software better every day!

Also take into account that we do this activity (UI Design) behind a screen with differed time, the most efficient way would have been us in the same room physically!

It's common practice, and already validated, but unfortunately du to several reason, we can't do it like this!

 

Edited April 6 by anonyme-x22

[TK.]

Well, "did not understood each other" brings up an important point - let's talk about the background of our debate.

From my point of view: you are very unhappy with the MIDIbox SEQ UI and after you noticed that I became a bit more active you bring up some points + improvement ideas under the assumption, that I've all time of the world to discuss each detail and rework the appr. firmware parts based on your wishes.

But fact is, that my focus is still on very different topics, that a serious rework would require much more time to assess options with multiple users (like I did >10 years ago with onsite meetings), that the implementation probably has to be done by a programmer who needs to be funded.

The energy I can spend on MIDIbox projects these days is still very low, and my motivation to continue discussions in the mode that you prefer is also very low.

Maybe this helps you to understand a bit better why I don't react like you think I should do.

Best Regards, Thorsten.

P.S.: I'm off for some days due to business reasons...

[anonyme-x22]

Hello,

I agree, and i'm sorry if you feel wrong again.

I understand that time today is limited for everyone, and the time are difficult, however i don't expect you to do all the thing as fast as possible.

But we've agreed that for all function, avoiding this behavior is a good point.

So please when you get time, take a look at this issue to really finish the thing we started.

As i said we can work as small increment when you get some time.

As for the mode of discussion, i'm sorry again but i'm muted.

Of course, if you help me for the most having a way to test the software without need to upload it on the seq 4 v+, i will manage the build environment to make the things!

Rgds,

Edited April 7 by anonyme-x22