Expandable GUI
-
@WepaAudio said in Expandable GUI:
when life give you lemons you learn how to make lemonade
A bit more complicated than that...
https://youtu.be/rIK-q6JoOeU?si=ua8Dt6P5NxSctyoR -
https://youtu.be/Dyq2xUoNeIo , I believe this is what you guys want?
-
@ustk I believe this is what they want? https://youtu.be/Dyq2xUoNeIo
-
@ustk jajajajajaja what amazing clip and very true, I will stop using that lemonade crap I wrote jajajajaj
-
@WepaAudio said in Expandable GUI:
so when I code In C-sound it’s possible to make -25% t o + 200% zoom in zoom out for the “blinds” jejeje, I can post that code and see who can translate that to Hise code, I belive that program is built with juce
Are you referring to Cabbage?
Yes it is possible to do this with a JUCE app but the functionality is not in HISE.
-
@d-healey yes, I didn't want to mention the name because is HISE forum, but .... yes ,is cabbage, by the way what this mean? ! saving embedded samples are bad practice, save the sample file to a file instead.
then the other question is How to do it and in where to save it, thank you!
-
@WepaAudio When you've mapped your samples you should create a sample map by clicking the save button in the mapping editor. If you don't do this then the sample mapping will be saved with your HISE project (this is the embedded sample map) but it's then fixed, if you change the mapping you can't get back to the previous one. Whereas if you save it you can have multiple sample maps that you can swap out and change as needed.
-
I apologize, but I think this feature is really necessary.
Please add this @Christoph-Hart
-
-
@orange agree!
-
@orange @Christoph-Hart Please :folded_hands:
-
-
@Fortune My hot take is that @Christoph-Hart shouldn't do it.An interface that changes size is poor design. You should never require so many on-screen widgets as to require the expansion of the interface. Think contextually.
-
@clevername27 said in Expandable GUI:
@Christoph-Hart An interface that changes size is poor design. You should never require so many on-screen widgets as to require the expansion of the interface. Think contextually.
No, you are looking at it from a very shallow and tiny perspective.
This has nothing to do with a large number of parameters. Several parameters can also be stored at the user's discretion. This has to do with flexibility.
Maybe you can choose not to use the expandable GUI from this perspective. But Users want to see this feature, just like they want the resize feature too.
For example, let's consider an fx plugin with Mid-Side feature. Users who do not want to use Mid-Side prefer to see only one channel and perform stereo processing. Users who want to use Mid-Side want to see the mid and side parts on the screen at the same time, which is important for them in terms of intervention. In such a case, the screen expand feature can be used for users who want Mid-Side.
Or another example: while some users want to see a huge analyzer on the screen, some do not. The expand feature can be used for this.
These were just two examples, even if you do a little research on other forums, you can understand that the expandable GUI feature is a feature sought by users.
Besides, many leading developers use this feature in their plugins as new plugins are released every day.
-
@clevername27 The expanding interface is probably the best compromise when considering primary use cases and the addition of more in depth features for power users.
The long-standing alternative is tabs or pages.
The expanding interface affords the ability to see primary and more advanced or less common use case controls all at once if it’s appropriate for the user. The Arturia compressor is a good example of this. Instead of clicking a tab or a page to see the extra controls, you never leave the primary view.
-
@ally Your goal as an interface designer is to minimize the number of GUI elements that are visible to the user - not to maximise them.
-
@clevername27 not me
More is more! I'm looking forward to an expanding interface so I don't have to use tabs for everything -
I can see a use case for this when you want to show controls that needs to be visible alongside other controls but not all the time. For example a macro panel where you can assign macros to other controls on the GUI. You don't need this panel visible all the time but you need to be able to see the regular UI controls and the macro panel at the same time.
Also good for hiding the on screen keyboard because not everyone wants to see that. In this case it is optionally reducing the amount of controls visible rather than adding more.
-
Put them in tabs or in an expanded part, it's a design choice so a matter of taste in the end. So saying that you have to do this or that does not apply in my opinion.
Although a use case in favour of expandable GUI is when you want a distraction free mode of your interface, like for instance for visualisers where you don't want anything else (so you can open more instances side by side), or as Dave said a key board, or even a preset browser when you want to keep an eye on the controls that are changing as your go through the presets...
So it's a yes for me, I can clearly see where it could be really useful and not just a whimsy wish
-
@d-healey said in Expandable GUI:
Also good for hiding the on screen keyboard because not everyone wants to see that. In this case it is optionally reducing the amount of controls visible rather than adding more.
This would be the #1 use-case for this for me as well.
-
F Fortune referenced this topic on
