Control Mixer

More
22 May 2012 13:22 #341 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Control Mixer
Thanks. I've fixed that. yeah a long press should be 5, a short press is 1 (for the buttons that have a large range)

Please Log in or Create an account to join the conversation.

More
24 May 2012 11:54 - 24 May 2012 12:03 #346 by FDR
Replied by FDR on topic Re: Control Mixer

PhracturedBlue wrote: I implemented the er9x system almost as-is, but did not implement the dual-rate/expo as a pre-filter. Instead the template will automatically define multiple mixers to get the desired behavior. We may need a new template or moodify the existing template to handle the flight-mode switch.

Here is the DR template. There is only 1 screen for input, but it is implemented as 2 mixers:
1) ch = If (! dr_switch) Input1 * rate1 * curve1
2) ch = If (dr_switch) Input1 * rate2 * curve1

To do flight mode, you'd need something like this:
Here is a collective definition (throttle stick controls the collective in both modes, but with different curves)
1) var1 = If (! fmode) Input1 * curve1 //This is a 2d curve
2) var1 = If (fmode) Input1 * curve2 //This is a 3d curve
3) collective = If (! dr_switch) var1 * rate1
4) collective = If (dr_switch) var1 * rate2

The throttle could be the same, using an 'idle up' curve for 3dmode, or it could be a function of a different channel (like the collective or a mix) for 3dmode.

Note that after defining a dual-rate mode (and pressing 'ok'), you can switch to 'complex' to see how the mixers were actually configured.


I think it will be better to continue here, even though my post will concern things about both the mixer and the GUI...
I will try to write down, what I understand about the mixer interface and what I do not:

Main sreen:
1. On the screen in the first column there are the 8 channels (numbered correctly from 1 to 8, so users can understand, as opposed to the right pane of the emulator, where the same channels are indexed from zero)
2. The second column contains the stick associated with this channel, or does this come from the source? If it is the source, what happens when the mixer type is "None", because it has no source definition? Is it an unassigned channel then? Either way, I couldn't change that, so it is so far probably just a hardcoded example, isn't it?
3. The third column is a button titled with the selected "mixer type". It opens the mixer for editing. Clear.
4. The last (fourth) column shows the switches and/or curves applied. I couldn't change it either, so the comment for the 2nd column applies here too. What I do not understand is: what if it is a complex mixer, which can have more pages (= more mixers) with different switches and curves? The other thing: in all the "switch" controls the items are rather channels, than actually harware or software switches.

"None" mixer type:
5. See 2. Is it an unassigned channel then? By the way it freezes when I click OK in the "None" window...

"Simple" mixer type:
6. "Src" is the source stick or channel value. I see the four sticks: THR, RUD, ELE, AIL; the three premixed cyclic channel: CYC0, CYC2, CYC2 (Wouldn't be better to index them 1 to 3 for the non-programmer users? ;) ); and the channel outputs (?) from Ch1 to Ch12. Will the channels be used as a calculated dummy one to use in other mixes, like in the er9x, or these are only the actual channels, and there are other ways to implement the intermediate calculations?
7. "Curve" I see some useful predefined functions here, plus the EXPO option, which duplicates the function of the "Expo" mixer type, plus the PWL curves with six different resolution from 3 points to 13. (They are cool! ;) ) My only (GUI related) complaints here, that it is not visible that some of them are clickable, which then opens it for editing. I realized it only by accident. Is there a way to indicate the editing possibility? By the way it contradicts one of my GUI ideas to show a selection list in case of clicking in such an option spin button... :(

Expo editing screen:
8. I have opened it by an accident. :)
9. I like setting it with the mouse (i.e. the touch pen)! It was a little bit confusing first, because I thought it is the curve that I have to drag, but after that I realized, that only the Y value of the click matters. Nice.
10. IMO it would be better to insist on one layout for the OK and Cancel buttons. For me it is more logical in the OK-Cancel order than vice versa, YMMV.

Curve editing screen:
11. It's cool to have different number of points! It very well substitutes Walkera's approach of having optional points. Not the same, but can be matched pretty good.
12. It is also cool to set points by touch! It would be even better if one doesn't have to select the point first, but just clicking throw the graph to set the curve, i.e. it could use the X coordinate of the click to change the point.
13. GUI related: IMO the graphs should maintain the same proportional XY size on all screens to help to understand the curves. Besides I would like some helping grid (with low contrast, for example dark grey, supposing a black background, and light grey for the XY axles) by every 20% or 25%. Other fancy idea is to show the X and Y value projections of the actual stick (or channel) value point with dashed or dotted lines, where applicable... :)
14. Is it intentional that if I set a curve, and then go to an other channel, there will be the same curve by default?

Scale, Offset, Max, Min:
15. I see no effect they have. Shouldn't they change the transfer function visibly?
16. Again the opposit order, i.e. Min-Max would be more logical to me. YMMV

"DualRate" mixer type:
17. How the D/R value is different from the Scale or Min/Max? Since neither of them has effect on the graph, it isn't easy to understand...
18. Shouldn't some of the values offer more than 100% to scale thing up? That is where the separate D/R filter would come handy, or the current travel adjust after the mixes...
19. I have already written about the switches which are rather channels in point 4.

"Expo" mixer type:
20. Points 4., 15., 16. apply here too...
21. What is the difference between the expo mixer type and a simple mixer type with expo curve, apart from the possibility to define a switch and directly editing the expo value (i.e. without opening the expo screen)?
22. There is a little bug on opening the expo screen by clicking into the expo box: open a mixer by clicking the button; step throw to complex type; change the curve to any PWL; step back one to expo type; click into the expo box: it will show the curve screen instead of the expo screen.

"Complex" mixer type:
23. Well, let's say: it is complex! ;)
24. The new controls are: the "Mixers" which determines how many mixes this complex type consists of; the "Page" which says which of the mixers we are seeing/editing now; and the "Mux", which determines how this mixer affect the previous mixes (i.e the output value so far).
25. The "Mux" can replace the whole previous value with the one it calculates, but it has sense only if it depends on a switch. It can also multiply the previous value with it's calculated value, or add it as a correction value.
26. IMO the logical order is Mixers (= Mixer count), Page (Current mixer), Mux, all the other settings...
27. I have already mentioned my concern about what is shown on the main screen's switch column in case a multi-mixer complex type...

That is so far...
I hope you do not take it as nitpicking, I really would like to understand the functioning and the idea behind, and would like to help.
Last edit: 24 May 2012 12:03 by FDR.

Please Log in or Create an account to join the conversation.

More
24 May 2012 14:03 - 24 May 2012 14:53 #347 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Control Mixer
Thank you for doing this. I am not a GUI designer, and I absolutely want feedback on what works and what doesn't. Your feedback is very thorough. I bolded where I would like additional feedback since this is now a very long post.

FDR wrote: Main sreen:
1. On the screen in the first column there are the 8 channels (numbered correctly from 1 to 8, so users can understand, as opposed to the right pane of the emulator, where the same channels are indexed from zero)

Noted. I've changed the right-hand screen. You will eventually be able to scroll down to see all channels rather than just the 1st 8

2. The second column contains the stick associated with this channel, or does this come from the source? If it is the source, what happens when the mixer type is "None", because it has no source definition? Is it an unassigned channel then? Either way, I couldn't change that, so it is so far probably just a hardcoded example, isn't it?

Yes. the main screen is all hard-coded except for the mixer type at the moment. The 2nd column will be the source. you can't change it here, but it should reflect the value in the mixer.

4. The last (fourth) column shows the switches and/or curves applied. I couldn't change it either, so the comment for the 2nd column applies here too. What I do not understand is: what if it is a complex mixer, which can have more pages (= more mixers) with different switches and curves? The other thing: in all the "switch" controls the items are rather channels, than actually harware or software switches.

Again, it is hardcoded as you noted. It should show the switch in use if applicable. I'm not sure showing the curve makes any sense here since here. Maybe just the curve function.
would work.
I am not sure how to deal with the complex mixers. The way er9x does it looks like this:
ch1  <control1> <switch1> <curve1>
 +   <control2> <switch2> <curve2>
 R   <control3> <switch3> <curve3>
so each mixer is listed below the channel with how it is applied (add, mult, replace) and its values. The er9x approach is not newbie friendly, so I'm not sure it is a good way to go. Do you think we should go the er9x route for this?
Note that in er9x, there is a pool of curves and the mixer selects one, so you'll see something like "C1" which tells you that the 1st curve is used. In my current implementation, each mixer has a dedicated curve so this doesn't make sense. I didn't see much value in reusing the same curve for multiple channels, and think it can be confusing, so I didn't do that.

"None" mixer type:
5. See 2. Is it an unassigned channel then? By the way it freezes when I click OK in the "None" window...

Yes, this is an unassigned channel. I've fixed the hang. Do you think 'Unassigned' would be a better name?

"Simple" mixer type:
6. "Src" is the source stick or channel value. I see the four sticks: THR, RUD, ELE, AIL; the three premixed cyclic channel: CYC0, CYC2, CYC2 (Wouldn't be better to index them 1 to 3 for the non-programmer users? ;)); and the channel outputs (?) from Ch1 to Ch12. Will the channels be used as a calculated dummy one to use in other mixes, like in the er9x, or these are only the actual channels, and there are other ways to implement the intermediate calculations?

That is just a typo. the cyclics should be 1-3. I've fixed it now.
I am planning to make the source spinbox name clickable. When you click it, it will reverse (minus sign in front). I'll do the same for the switch spinbox. Note that this is different than channel reverse where you reverse the output, this will just reverse the input (and/or whether the switch applies in the ON or off state)

Currently sources work like er9x where unused channels can be used as intermediate variables. I've been thinking that may be confusing, so I was considering having 3 categories: inputs (sticks, switches, buttons), channels (actual channels), and 'vars' which are intermediate. Do you think this would be more clear? It means the main page would need to show all channels and all vars

7. "Curve" I see some useful predefined functions here, plus the EXPO option, which duplicates the function of the "Expo" mixer type, plus the PWL curves with six different resolution from 3 points to 13. (They are cool! ;) ) My only (GUI related) complaints here, that it is not visible that some of them are clickable, which then opens it for editing. I realized it only by accident. Is there a way to indicate the editing possibility? By the way it contradicts one of my GUI ideas to show a selection list in case of clicking in such an option spin button... :(

See my answer to 21 for the expo stuff.
As for indicating where it can be clicked....For the cases where no option is clickable (the min/max buttons) we could use a different button or different text color to indicate it. For the 'curve' spinbox, I'm not sure what to do. I could have them all be clickable and just have no control options when the curve screen pops up? Also I don't understand your last sentence. Can you rephrase which GUI idea you don't like?

Expo editing screen:
10. IMO it would be better to insist on one layout for the OK and Cancel buttons. For me it is more logical in the OK-Cancel order than vice versa, YMMV.

good observation. I'll think about OK-Cancel vs Cancel-OK

Curve editing screen:
12. It is also cool to set points by touch! It would be even better if one doesn't have to select the point first, but just clicking throw the graph to set the curve, i.e. it could use the X coordinate of the click to change the point.

With the mouse this would make sense. The problem is that the touch-screen is not as accurate, and if there are more than 3 points, you could easily grab the wrong one. I agree the current interface isn't as nice, but it is more robust.

13. GUI related: IMO the graphs should maintain the same proportional XY size on all screens to help to understand the curves. Besides I would like some helping grid (with low contrast, for example dark grey, supposing a black background, and light grey for the XY axles) by every 20% or 25%. Other fancy idea is to show the X and Y value projections of the actual stick (or channel) value point with dashed or dotted lines, where applicable... :)

Yes, the curve display could be much nicer. In the editing screen it will be difficult to overlay the final transfer function because we don't have access to the necessary data at that point. I'll think about it some more. Adding minor grids is a good idea. I'll look into it.

14. Is it intentional that if I set a curve, and then go to an other channel, there will be the same curve by default?

No that is a bug.

Scale, Offset, Max, Min:
15. I see no effect they have. Shouldn't they change the transfer function visibly?
16. Again the opposit order, i.e. Min-Max would be more logical to me. YMMV

I am planning to move the min/max to a 'channel page' because they aren't actually part of the mixer at all. they set the physical limits of the channel. It is also where I'll set the channel reverse. Do you think that'll make more sense?
Currently the curve at the bottom of the screen is not the final transfer function. It is just an image of the curve. Having it be the transfer function would be really cool (and here you could overlay the actual value of the stick input. But I'm afraid it would be confusing because it would only apply for the specific mixer/template. I.e. the curve would not necessarily represent what the final channel would look like since mixers can stack. Also if another mixer were the soucre, I'm not sure I could get the overlay to work. I'm open to opinions

"DualRate" mixer type:
17. How the D/R value is different from the Scale or Min/Max? Since neither of them has effect on the graph, it isn't easy to understand...

DualRate means you have 2 scalers, one when the switch is on, one when it is off. They both share the same curve. Normally you'd have one scaler at 100% and one at 70% (for instance). Min/max are fixed and are the same regardless of switch position (as I mentioned for 16, min/max are physical limits for the servos and I'm planning to move them out of the mixer page)

18. Shouldn't some of the values offer more than 100% to scale thing up? That is where the separate D/R filter would come handy, or the current travel adjust after the mixes...

yes, min/max and scaler/offsetshould allo to go to +/- 125% It is on my todo list

19. I have already written about the switches which are rather channels in point 4.

It is a it confusing at the moment because there are only 4 inputs coded (the sticks) there aren't any switches implemented yet. That is why you don't see an option to select which switch controls the mixer. I'll get to it soon.

"Expo" mixer type:
21. What is the difference between the expo mixer type and a simple mixer type with expo curve, apart from the possibility to define a switch and directly editing the expo value (i.e. without opening the expo screen)?

The 'expo curve' is not identical to the 'expo template'. The template does use the 'expo curve' but it is actually implementing 2 mixers (one with the curve and one without, whereas the curve is only setting the curve for a single mixer. For instance setting expo on the simple template means you can't disable it) Setting expo in the dualRate template means that the same curve is used regardless of the switch, and the switch just controls the scaling.

22. There is a little bug on opening the expo screen by clicking into the expo box: open a mixer by clicking the button; step throw to complex type; change the curve to any PWL; step back one to expo type; click into the expo box: it will show the curve screen instead of the expo screen.

good catch.

"Complex" mixer type:
24. The new controls are: the "Mixers" which determines how many mixes this complex type consists of; the "Page" which says which of the mixers we are seeing/editing now; and the "Mux", which determines how this mixer affect the previous mixes (i.e the output value so far).
25. The "Mux" can replace the whole previous value with the one it calculates, but it has sense only if it depends on a switch. It can also multiply the previous value with it's calculated value, or add it as a correction value.

you got it right.

26. IMO the logical order is Mixers (= Mixer count), Page (Current mixer), Mux, all the other settings...

I was trying to keep the different template pages as similar as possible. I'm certainly open to other ideas. I'll think about this further

Again thank you for taking the time to give this very detailed feedback. It is very valuable. Please continue to provide feedback on what you find.

I'll make as many of the fixes noted above as I can and will check in a new release.
Last edit: 24 May 2012 14:53 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

More
24 May 2012 20:19 #348 by FDR
Replied by FDR on topic Re: Control Mixer
OK. Now it is more clear then before, but I still have a lot of questions, not to mention the things I've forgot about in my previous post.
It would be too long to quote the whole post, so I will reflect in pieces.

PhracturedBlue wrote: 4. Do you think we should go the er9x route for this?

No, I'm not sure jet. One thing is sure: it is too complicated. I think I'm not a simpleton, but it is difficult for me to understand, so for a simple (not even programmer ;) ) user it could be too difficult.
So the er9x uses more row to describe a channel mixes if it has more. It makes sense. (Their user manual doesn't show an example of it.)
But we might eliminate the confusion, it the functions would be elementary, not that complex as they are now. For example there are those min/max values, which even doesn't depend on the mixes, curves or switches. They are the analogues for the current travel adjust values, which are the last applied scaling values for the output, to suit the otherwise perfectly mixed channel value to the phisical servo travel. They should be added separately.
And there are the problem of the dual rates (which doesn't necessarily mean two values, for example in the er9x it may be 3: low, mid, high) and expos. Their meaning is to preprocess the inputs to a choosen characteristics, or simple limit the inputs to achieve a more relaxing control over a too responsive one, without the need of redrawing all the curves. I would like a separate function for this too.
As you wrote, the difference between the expo mixer and a dual rate expo curve is that the later is switchable. I would probably settled with series of primitive functions, any of which would be switchable.
To explain that here is an example:
ch1 <input>               // the stick
 *  <scale_1>             // a basic limit
 *  <scale_2> <switch_1>  // d/r
 *  <expo_1>  <switch_1>  // expo
 *  <curve_1> <switch_2>  // a curve, which is a simple transfer function
 R  <curve_2> <switch_3>
 +  <mix_1>   <switch_2>  // a mix, which depends on other channels value
 *  <mix_2>
 *  <travel>              // the final "scaling"
It is very much like a complex mixer type of yours, just split down to basic functions.
This is a more complicated approach to display, but simpler to understand, I think. There is no need to display all of this on the main page, there it would be enough to indicate (with small icons for example), that there is scaling(s), curve(s), mix(es), and that they depend on switch(es).
After opening the channel screen, there could be this list, with the ability to select the switches, and to open the function (like scale, expo, curve, mix, etc) screens to edit the values.
Do not start to change anything, I just thinking loud here, I should rethink these things... :)

Other thing I have forgotten, that we should allow to change the functions order (within sense), in your approach it would be the order of pages in a complex mixer...

I hope I was clear. It is quite hard for me to put it to words, my engish is too bad.

Please Log in or Create an account to join the conversation.

More
24 May 2012 21:09 #349 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Control Mixer
You are doing a great job with your English. I know many native speakers who couldn't do as well. Plus I can't speak anything else, so I am very grateful that you can :)

ch1 <input>               // the stick
 *  <scale_1>             // a basic limit
 *  <scale_2> <switch_1>  // d/r
 *  <expo_1>  <switch_1>  // expo
 *  <curve_1> <switch_2>  // a curve, which is a simple transfer function
 R  <curve_2> <switch_3>
 +  <mix_1>   <switch_2>  // a mix, which depends on other channels value
 *  <mix_2>
 *  <travel>              // the final "scaling"

As you said, this is nearly identical to the 'complex' mixer, (or to the original er9x implementation). the main difference is that you have broken down the transfer function and scale/offset into separate 'mixers'. From my perspective currently a single mixer implements:
if (switch) then
    mix = input * f(x) * scale + offset
    if (mux == ADD) then
        out = out + mix
    else if (mux == MULT) then
        out = out * mix
    else if (mux == REPLACE) then
        out = mix

You seem to be considering something like 2 types of mixers:
if (switch) then
    if (type == SCALE)
       mix = scale + offset
    else if (type == TRANSFER_FUNCTION) then
       mix = f(x)
    if (input) then
       mix = mix * input

    if (mux == ADD) then
       out = out + mix
    if (mux == MULT) then
       out = out * mix
    else if (mux == REPLACE) then
        out = mix
To me it is harder to understand. That said, it may be that my idea for 'templates' that hide the complexity of the mixers is poorly thought out or at least poorly implemented. I was trying to make the most common cases easy to implement. To properly do 3-position fmode + 3-position dual-rate channel, it will take many lines in a complex mixer. I could try to abstract that away by building a better 'dual rate' template that can handle all of that for the user, and only expose the settings that are needed (the page could potentially look just like the Devo8 dual-rate page, though I'm not keen on that layout either) and leave the user ignorant of the mixers. Alternatively we could take the er9x route, and force the user to learn the (reasonably simple) mixer rules, and build complex expressions with them. In my use of er9x, I think this is too high of a learning curve for most users.

Other thing I have forgotten, that we should allow to change the functions order (within sense), in your approach it would be the order of pages in a complex mixer...

yes, ordering the mixer pages is a necessary addition

Also, I have just checked in fixes for most of the bugs you reported:
* switching from complex->expo tempate you still see the pwl rather than expo curve
* curve values are reset when editing a new (unassigned) channel
* xy graph shows dashed line at 25, 50, 75% (in curve editor only)
* all devo8 switches are now mapped:
z = gear, x = rudder D/R, c = elevator D/R, v = Aileron D/R, b = Mix (3-way), n = FMode (3-way)
* CYC is 1-3 now
* 'Ok' works when a mixer is set to 'none'

Please Log in or Create an account to join the conversation.

More
25 May 2012 03:00 #350 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Control Mixer
So I just committed code to draw the actual channel output transfer function in the template graph. It doesn't obey servo limits, so changing max/min won't have any effect, but it should fully evaluate complex mixer equations even if they are dependent on other mixers.

Because it doesn't obey the servo limits, I would recommend not playing with the 'offset' value, because it can cause the function to go out of range.

I'm not sure it is a good solution though. The graph is evaluated by evaluating the current value of all Tx inputs except for the value shown in the current mixer 'Source'. The curve then plots a sweep of the mixer Source against the channel output. I also draw a box with the current value of the channel which will move as you change any inputs affecting the channel.

The weird thing is that if you, for instance, are on the 'Expo' template, and toggle the switch, the curve will change, since with the switch off, the curve is linear, and with the switch on it is expo.

Anyhow, please give it a try and provide feedback on it.

Please Log in or Create an account to join the conversation.

More
25 May 2012 09:54 - 25 May 2012 09:58 #351 by FDR
Replied by FDR on topic Re: Control Mixer

PhracturedBlue wrote: As you said, this is nearly identical to the 'complex' mixer, (or to the original er9x implementation). the main difference is that you have broken down the transfer function and scale/offset into separate 'mixers'. From my perspective currently a single mixer implements:

To me it is harder to understand. That said, it may be that my idea for 'templates' that hide the complexity of the mixers is poorly thought out or at least poorly implemented. I was trying to make the most common cases easy to implement. To properly do 3-position fmode + 3-position dual-rate channel, it will take many lines in a complex mixer. I could try to abstract that away by building a better 'dual rate' template that can handle all of that for the user, and only expose the settings that are needed (the page could potentially look just like the Devo8 dual-rate page, though I'm not keen on that layout either) and leave the user ignorant of the mixers. Alternatively we could take the er9x route, and force the user to learn the (reasonably simple) mixer rules, and build complex expressions with them. In my use of er9x, I think this is too high of a learning curve for most users.

One other main difference is, that in my way (or in er9x way if you like), there is a switch for every basic function, so they are independent.
An example to enlighten it:
If you want to implement a d/r option and some curve, you will use the complex type. But since every page has one switch for all the settings, to be able to switch the d/r scaling, you have to repeat the same curve on each page.
By the way, as I have already written about, dual rate can mean more then two options, and the expo isn't necessarily an on/off thing either, but more likely two (or more) different value depending on switch(es).
That's why I like more the er9x way of preconditioning expo/dr options:

I would go further and add the expo/dr option to pots and trims too!
(In the DEVO 8 we do not have pots, but in the 7, 10 and 12 we will. The lack of pots what makes me want to use the trims for channel inputs... Of course they don't need calibration, but trim step settings instead.)

If I understood well, we agreed, that the min/max values go out to the end with the reverse switches. (They are the "Limits" on the chart.)

Now if we had a separate module for the expo/dr, then what we have in the mixer, is just that: mixers.
Note, that I have splitted even the "mixer" function into separate curve and mix(er). The difference is that the curve is only a transfer function, i.e. takes the same channel value as the input, and it's output will be the new value of the channel. The mix however can take an other channel/stick value as input, and it's output can add, multiply or replace the affected channel value. It is very much alike to the curve, if somebody selects the same channel as the source.
The question then is, if my simple transfer curve belongs to the preprocessing section too, i.e. expo/dr/curve...
The other advantage of separating could be, that in this way these blocks don't belong to the channels, but directly to the inputs (sticks, pots, trims) instead.
It later allows you to simple assign an "input" to the mixer including all the preprocessing.
Furthermore I would allow to select for input: a stick (or pot) input (which is the position calibrated/normalized); a stick (or pot or trim) value (which is the stick input processed by expo/dr/curve); or a channel value. The same things could be used as source for the software switches complemented with a value and direction.
Last edit: 25 May 2012 09:58 by FDR.

Please Log in or Create an account to join the conversation.

More
25 May 2012 10:20 #352 by FDR
Replied by FDR on topic Re: Control Mixer
Your latest bug fix introduced another one: now on the dualrate and complex type the graph doesn't change with the function selected, and the PWL-s are not reflected back from the curve screen.

Please Log in or Create an account to join the conversation.

More
25 May 2012 10:37 - 25 May 2012 10:44 #353 by FDR
Replied by FDR on topic Re: Control Mixer
The new curve looks a bit busy for my eyes with dashed lines:


I would like it better with solid lines for the grid and the graph too:


PhracturedBlue wrote:

Curve editing screen:
12. It is also cool to set points by touch! It would be even better if one doesn't have to select the point first, but just clicking throw the graph to set the curve, i.e. it could use the X coordinate of the click to change the point.

With the mouse this would make sense. The problem is that the touch-screen is not as accurate, and if there are more than 3 points, you could easily grab the wrong one. I agree the current interface isn't as nice, but it is more robust.

Still someone could draw the curve with the pen. Is it possible with the touch screen, or it only supports clicks?
It would be a stellar feature!
Attachments:
Last edit: 25 May 2012 10:44 by FDR.

Please Log in or Create an account to join the conversation.

More
25 May 2012 12:23 #354 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Control Mixer
The system I've developed can be modeled exactly like the er9x system. You don't need to model d/r the way I have. You can model it as a curve and and multiplier (so that the curve doesn't need to be duplicated).
I really don't see any difference between expo and a curve. Expo is just one specific transfer function.
I think you may be getting confused by my poorly defined template pages and the capabilities of the mixer. If you like the er9x way of inputting expo and d/r better, we could have a template that looks nearly the same (2 switches, 3 scalers and 3 curves). The main problem I have with their approach is that once I define a D/R or expo on a stick, I can't get at the raw value of that stick anymore. My approach allows you to do so. Their mixers are fully capable to implement the same capability available on the D/R expo page (I've done so) so the underlying implementation doesn't seem important. It is just a question of presentation in my mind, and it is clear you don't like mine :) Also, by moving the expo d/r function into the mixer, it is now easy to apply it at to any input and/or intermediate channel.

Let me merge the d/r and expo templates into one with the same capabilities as the er9x controls, and see if that helps any.

Please Log in or Create an account to join the conversation.

More
25 May 2012 12:34 #355 by FDR
Replied by FDR on topic Re: Control Mixer

PhracturedBlue wrote:

"None" mixer type:
5. See 2. Is it an unassigned channel then? By the way it freezes when I click OK in the "None" window...

Yes, this is an unassigned channel. I've fixed the hang. Do you think 'Unassigned' would be a better name?

It's not essential, I just wanted to clearify...

"Simple" mixer type:
6. ..... Will the channels be used as a calculated dummy one to use in other mixes, like in the er9x, or these are only the actual channels, and there are other ways to implement the intermediate calculations?

....
Currently sources work like er9x where unused channels can be used as intermediate variables. I've been thinking that may be confusing, so I was considering having 3 categories: inputs (sticks, switches, buttons), channels (actual channels), and 'vars' which are intermediate. Do you think this would be more clear? It means the main page would need to show all channels and all vars

Either will do. Only advanced users will define mixers, they will get it both ways...

7. "Curve" I see some useful predefined functions here, plus the EXPO option, which duplicates the function of the "Expo" mixer type, plus the PWL curves with six different resolution from 3 points to 13. (They are cool! ;) ) My only (GUI related) complaints here, that it is not visible that some of them are clickable, which then opens it for editing. I realized it only by accident. Is there a way to indicate the editing possibility? By the way it contradicts one of my GUI ideas to show a selection list in case of clicking in such an option spin button... :(

See my answer to 21 for the expo stuff.
As for indicating where it can be clicked....For the cases where no option is clickable (the min/max buttons) we could use a different button or different text color to indicate it. For the 'curve' spinbox, I'm not sure what to do. I could have them all be clickable and just have no control options when the curve screen pops up? Also I don't understand your last sentence. Can you rephrase which GUI idea you don't like?

Then first I'll try to explain what I meant:
Walkera uses dropdown lists instead your (let's call) option spin buttons. The dropdown's advantage, that you see all the options you can choose, don't have to scroll them up and down to find the one you are looking for.
However your option spin button can be handled with buttons more simpler.
Let's look at the other inputs too:
For numbers Walkera used a numeric spin button, but it had no quick change option, you had to step throw the whole range by one (or sometimes even in 0.5 increments).
Your approach with the long clicks is better. (I have one observation here: if I push the arrow, then first it adds one, only after then it starts to step throw by 5, so in the end you have to correct it back. Anyway I feel 10 would suit as large steps better: the usual range is -100..+100, which is 20 steps by 10.)
And don't forget there are some direct inputs: model name as text, fixed id as a large number (is not suitable for spinning throw), and perhaps the timer values. They should be input on a virtual keyboard, if it is possible. (It is that way in the original fw.)
So I thought it would be cool, if clicking in these spin buttons and boxes could open the appropriate editor, i.e. textual virtual keyboard for the text boxes (model name), numeric virtual keyboard for the numbered boxes (like the fixed id and timer) and numeric spin buttons (practically all the numeric values), and a dropdown list for the option spin buttons.

But this idea interferes with your clickable funtion for opening a whole editing screen for it. I don't say it is bad, but at least confusing, since not all the options need this kind of opening, so it should be indicated somehow, that it is clickable, and a click will do something...
The simplest way would be to indicate it in the caption's text, for example with an asterisk, like "EXPO*" or "5Point*", and document as is...

Scale, Offset, Max, Min:
15. I see no effect they have. Shouldn't they change the transfer function visibly?
16. Again the opposit order, i.e. Min-Max would be more logical to me. YMMV

I am planning to move the min/max to a 'channel page' because they aren't actually part of the mixer at all. they set the physical limits of the channel. It is also where I'll set the channel reverse. Do you think that'll make more sense?
Currently the curve at the bottom of the screen is not the final transfer function. It is just an image of the curve. Having it be the transfer function would be really cool (and here you could overlay the actual value of the stick input. But I'm afraid it would be confusing because it would only apply for the specific mixer/template. I.e. the curve would not necessarily represent what the final channel would look like since mixers can stack. Also if another mixer were the soucre, I'm not sure I could get the overlay to work. I'm open to opinions

Absolutely. At the end there should be a min/max scaling (they call it servo "travel adjust" now), a value limit (might be asimmetric too), and a reverse switch.

Please Log in or Create an account to join the conversation.

More
25 May 2012 12:53 - 25 May 2012 12:53 #356 by FDR
Replied by FDR on topic Re: Control Mixer

PhracturedBlue wrote: The system I've developed can be modeled exactly like the er9x system. You don't need to model d/r the way I have. You can model it as a curve and and multiplier (so that the curve doesn't need to be duplicated).
I really don't see any difference between expo and a curve. Expo is just one specific transfer function.
I think you may be getting confused by my poorly defined template pages and the capabilities of the mixer. If you like the er9x way of inputting expo and d/r better, we could have a template that looks nearly the same (2 switches, 3 scalers and 3 curves). The main problem I have with their approach is that once I define a D/R or expo on a stick, I can't get at the raw value of that stick anymore. My approach allows you to do so. Their mixers are fully capable to implement the same capability available on the D/R expo page (I've done so) so the underlying implementation doesn't seem important. It is just a question of presentation in my mind, and it is clear you don't like mine :) Also, by moving the expo d/r function into the mixer, it is now easy to apply it at to any input and/or intermediate channel.

Let me merge the d/r and expo templates into one with the same capabilities as the er9x controls, and see if that helps any.

Wait! You are right, I was too sloppy with that example. I see now you can do it by setting the mux to add, and ensuring the curve value is zero across the range. However this is my complaint, that you have to handle additional settings to implement something they do not belong to.
I do not dislike your implementation ( ;) ), I just found it confusing sometimes, but I understand your goal to simplify the need of composing complex mixers. But as I see, your complex type will be essential to achieve the desired mixes, and it doesn't seem to be simpler.

Their limitation, that you cannot use the row value if you defined expo/dr, is very simple to overcome: as I have written already, you can easily allow to select stick (row) input and stick (expo/dr corrected) value alike as channel/mixer source.
Last edit: 25 May 2012 12:53 by FDR.

Please Log in or Create an account to join the conversation.

More
25 May 2012 12:53 #357 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Control Mixer

FDR wrote: Walkera uses dropdown lists instead your (let's call) option spin buttons. The dropdown's advantage, that you see all the options you can choose, don't have to scroll them up and down to find the one you are looking for.

I would have prefered a drop-down list too. Implementing it was more difficult though because you need to figure out where to display it based on where it=n the screen it is (towards the bottom, it needs to open 'up' and at the top it needs to open 'down'), so I figured I'd just let MatCat do it instead. The spin-buttons were easy to implement, and got the basic features. For cases where text entry is allowed, the plan is to ave a virtual keyboard (again I'm going to let MatCat implement that). If we keep the spin-buttons, clicking an a text-editable button could allow the keyboard to come up. I don't see much value in using a keyboard for numeric or limited value fields though

Your approach with the long clicks is better. (I have one observation here: if I push the arrow, then first it adds one, only after then it starts to step throw by 5, so in the end you have to correct it back. Anyway I feel 10 would suit as large steps better: the usual range is -100..+100, which is 20 steps by 10.)

changing the step size is trivial. having the 1st long-press move one less so you don't need to correct should be doable too.

One way to deal with your concern about the spinbox (while still using a spinbox) is to add another button. It would make the current spinbox look like (excuse the crude ascii art)
-----   ------   -----   -----
|<--|   |TEXT|   |-->|   |...|
-----   ------   -----   -----
The downside is that it takes up a lot of precious space. So the alternative is likely to use a drop-down box like on Windows, with a 2nd button next to it to open up a new screen. It should be just as small as my spinbox:
-----------   -----
|TEXT    v|   |...|
-----------   -----

Then spinbuttons wouldn't be clickable at all.

Once we have a drop-down widget we can try it.

Please Log in or Create an account to join the conversation.

More
25 May 2012 16:21 #358 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Control Mixer

PhracturedBlue wrote: Let me merge the d/r and expo templates into one with the same capabilities as the er9x controls, and see if that helps any.

I've just committed a merged dual_rate/expo template that closely resembles the er9x solution.
It isn't polished yet and may not work perfectly (I wanted to get feedback on whether this is a useful direction), but it should give you an idea of how it should work.

I also took your suggestions on the curve editor.

As I mentioned before the curve on the 'template' page is based on the current inputs.
So if you try the new expo/d-r page, set sw1 = 'Mix1', set sw2 = 'Mix2' set different curves/scaling for each, and then press 'b' to toggle between the 3 settings.

If you Click on 'Med Rate' or 'Low Rate' it will allow you to have a different curve than the 'high rate' (the default is that they all use the same curve)

Please Log in or Create an account to join the conversation.

More
25 May 2012 18:58 #359 by FDR
Replied by FDR on topic Re: Control Mixer

PhracturedBlue wrote: I've just committed a merged dual_rate/expo template that closely resembles the er9x solution.
It isn't polished yet and may not work perfectly (I wanted to get feedback on whether this is a useful direction), but it should give you an idea of how it should work.

I also took your suggestions on the curve editor.

As I mentioned before the curve on the 'template' page is based on the current inputs.
So if you try the new expo/d-r page, set sw1 = 'Mix1', set sw2 = 'Mix2' set different curves/scaling for each, and then press 'b' to toggle between the 3 settings.

If you Click on 'Med Rate' or 'Low Rate' it will allow you to have a different curve than the 'high rate' (the default is that they all use the same curve)

Wow! Not bad! ;)
1. As I've already mentioned, the graph should maintain 1:1 XY proportions, even if it will be much smaller, to help to evaluate the curve.
2. IMO on this screen the functions should default to EXPO.
3. The only thing it can't do in a simple way is different values for the lower and upper part, but it can be done with curves.
Nice!
4. There are editing glitches on the expo screen...

Please Log in or Create an account to join the conversation.

More
25 May 2012 20:26 - 25 May 2012 20:28 #360 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Control Mixer
I've modified the Expo editor to allow editing pos/neg expo curves separately. The interface isn't ideal, but it is functional.
I made the graph square, though I'm not sure I agree it is the right decision.
Functions default to 'Expo' (this is done for all templates, since the defaultexpo curve is equivalent to linear
I fixed several bugs with how the expo screen works. if you run into more, please point them out so I can get them fixed.

Let me know if you think this is the right way to go about it. If it seems reasonable, I'll move on to working on the 'main' mixer screen and the endpoint screen.
Last edit: 25 May 2012 20:28 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

More
25 May 2012 20:49 #361 by FDR
Replied by FDR on topic Re: Control Mixer
Better and better! ;)
1. On the Expo&D/R screen the Src spins throw sticks and switches instead of sticks and channels, and it crashes at CYC1...
2. The layout not too good, but I can't say better. The point is on the functioning, and that is not bad at all.
3. I don't like the "Med-Rate" title. I always think about as some medical thing. :lol:
Could it be "Mid-Rate"?

Please Log in or Create an account to join the conversation.

More
25 May 2012 22:28 #362 by PhracturedBlue
Replied by PhracturedBlue on topic Re: Control Mixer
It may not be common, but it is valid for a source to be a switch. The code currently doesn't distinguish between sticks and switches (a switch is just a source with a value of -100 <-> 100). It is a discussion rcH4x0r and I had, and I agree with him. Eventually we'll support virtual inputs, so you could map the top-left up-down trims to behave as a single adjustable channel (like a pot).

I have also fixed the graph when the source is computed (either cyc or var). It was a rather large change, so hopefully I didn't cause any other regressions.


By the way, drawing curves freehand could be implemented, but it would require the curve to obey y = f(x). I'm not going to work on development of it at this point. There are more pressing needs.

Please Log in or Create an account to join the conversation.

More
26 May 2012 09:30 #363 by FDR
Replied by FDR on topic Re: Control Mixer
OK, it has sense, but then (since they are probably rearly used) they should be back in the order...
By the way what values will have a 3 way switch? -100, 0, +100? And a 4 way one? :)

Please Log in or Create an account to join the conversation.

More
26 May 2012 11:33 #364 by FDR
Replied by FDR on topic Re: Control Mixer
You may not be happy about what I will say: ;)
On the expo/dr screen there is enough place for three graphs for all the three state!
The second and the third would be optional of course depending on the switches...

Please Log in or Create an account to join the conversation.

Time to create page: 0.111 seconds
Powered by Kunena Forum