RFC ToggleIcons: one icon per switch state

More
07 Feb 2013 12:49 #6119 by PhracturedBlue
Replied by PhracturedBlue on topic RFC ToggleIcons: one icon per switch state
sure, that is fine.

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

  • rbe2012
  • rbe2012's Avatar Topic Author
  • Offline
  • So much to do, so little time...
More
08 Feb 2013 19:48 #6153 by rbe2012
Replied by rbe2012 on topic RFC ToggleIcons: one icon per switch state
I sent a pull request.
Everything what came into my mind was tested sucessfully (building all variations of Devo and emu, merging with PBs actual repo, tests with a lot of test cases with the emu_devo8 and Devo8.

The last changes affected the way of storing the new values. Some of the new variants for using more than one icon/image per switch can be saved in a manor where it is fully compatible to the used way of storing in modelXX.ini. Only when it is not translateable the values are stored normalized and comma-separated, while a deViation-version which does not know about the additional features will ignore them.
(This can lead to unpredictible unwanted behaviour because with reducing the values informations about the use of the icons are lost. The old version will work and perhaps show icons, but the wrong one can be chosen.)
I will try to write a manual for this. I haven't done before but I will try to edit the fodt-file.

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

More
10 Feb 2013 06:27 #6192 by PhracturedBlue
Replied by PhracturedBlue on topic RFC ToggleIcons: one icon per switch state
I've just checked in support for multiple icons per switch.

In the end, I ended up basically completely rewriting rbe2012's work (sorry about that). Basically I felt the solution was too complicated.

I made the following assumptions and it made the code much easier to manage:
1) You cannot negate a toggle. With 3-way switches this makes no sense anyway. You can always get the desired behavior by selecting the proper icon position.

2) Switches in capabilities.h are always in order (0,1 or 0,1,2)

3) Only one physical switch can control a given icon location

There is a bit of 'magic' code needed in model.c to handle backwards compatibility, but other than that it is much simplified.

While the icons work on the Devo10 now, I haven't yet implemented the equivalent GUI page to select the icons.

The code could probably use more testing and feedback. I am not sure that the behavior is exactly identical to what rbe2012 had, so if I missed any important features let me know.

RBE: Even though I did a big rewrite, I really appreciate you getting this working. It flushed out the concept well, and provided a solid framework for my update.

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

More
10 Feb 2013 06:28 #6193 by PhracturedBlue
Replied by PhracturedBlue on topic RFC ToggleIcons: one icon per switch state
Also, don't worry about documentation of this feature. Once we're closer to release, I'll update the manual. It needs a lot of work to document the 'standard' mixer among other things.

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

  • rbe2012
  • rbe2012's Avatar Topic Author
  • Offline
  • So much to do, so little time...
More
10 Feb 2013 09:58 - 10 Feb 2013 09:59 #6201 by rbe2012
Replied by rbe2012 on topic RFC ToggleIcons: one icon per switch state
Thank you for rewriting the code. I only wanted to help and not produce more work for you :whistle:
It is quite hard to dig into such a project at this far point. I admit I still have not understood all concepts and ideas behind your programming. And: it comes not really unexpected that my code is not the most elegant one (although I tried this...).

To your assumptions:
  1. Agreed. I only allowed this for backward compatibility for the 3-way-switches. No one will miss something.
  2. You are the man to guarantee this. I was not brave enough to make such an assumption, but it really makes many things easier.
  3. This is what I meant. I think I mixed up "icon", "icon image" and "icon location" in my explanations.
A short look on the code shows me that some parts are solved in a very different manner. I have not so much time now and will look deeper later.
Testing with emu_devo8 showed that it works almost as my version. Only when I took source=AIL and two icons, both worked, but after saving and loading the second icon was forgotten. I think this is not intended.

I had a look at the docu yesterday. The part for the toggles is ahort and clear. I would propose something like this:

Toggle icons are used to display the state of an input. A toggle has Pos. 0 to 1 (or 2) for 2- (or 3-) state-switches and for other inputs Pos.0 is when its value<=0 and Pos1 if value>0. Each toggle can have two resp. three different icons shown depending on the input value. Click on the toggle box to select two resp. three icons.
Up to 4 toggles can be displayed. If only 4 trims are shown, the 4 toggles will replace the area used by trims 5&6. If 6 trims are shown, only 3 toggles can be shown and they will be placed either in place of box 4 or box 8. The toggles will only be shown if there is room for them (no box or bar-graph is using that space).

Although I learned to edit .fodt-files (not easy with Windows) I think it does not make sense to upload a new document...
Last edit: 10 Feb 2013 09:59 by rbe2012.

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

More
10 Feb 2013 13:26 #6207 by PhracturedBlue
Replied by PhracturedBlue on topic RFC ToggleIcons: one icon per switch state
thanks, I've fixed the bug.
On windows, I use LibreOffice portable (so I don't need to install the whole thing) to work with fodt files. I don't like LibreOffice, but not everyone has access to Word. The nice thing about fodt is that it works much better with hgthan an .odt would. As it turns out if you write your odt in Word and bring it to LibreOffice, it is formatted slightly differently, so using fodt and enforcing the use of LibreOffice/OpenOffice is actually better.
Anyhow, that is way off topic.

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

Time to create page: 0.039 seconds
Powered by Kunena Forum