@David-Healey it was me and yes it is HISE!

@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.

@Bart Thank you! I just did the development and design, I didn't make the samples myself. The Atlas Sounds guys did all the sound design!

@arcy I don't think any Faust filters are polyphonic but I know for sure that one isn't. I got it to work by sticking 2 faust nodes side by side inside a multi container. You'll also need to remove the <:, from your faust code or you'll get a channel mismatch error.

@ally It worked! Thank you @ulrik!!

@griffinboy Yep, there's an array in this file: /hi_scripting/scripting/api/ScriptingGraphics.cpp

It's on line ~2510 so I just open it up and search for one I remember!

@dannytaurus look up synthgroup on the forum.

There’s an older post from Christoph where he details the use cases of the synth group. They are quite specific.

I’m not sure how you have your current set up in the tree that it’s possible to do what you want to do the way you want to do it.

@Steve-Mohican supersaws are kinda hard to replicate in a wavetable. I assume you mean a supersaw to be is a stack of multiple saw voices detuned against each other with stereo spread and panning. Getting that into a wavetable is going to be hard even if you're in Serum or Vital. Reason being, most wavetable synths wavetable osc are mono. Serum and vital are two prime examples. You need to also constantly modulate and move thru the table to replicate the detuning.

The Hise wavetable module works best if you design wavetables in other wavetable designing tools like Serum WT editor, Vital, SA Node etc. Those can spit out samples with interpolation that make morphing between frames smoother in Hise in my experience.

EDIT: Here is a supersaw wavetable file for Hise.

https://www.dropbox.com/scl/fi/vwcfz7e9zc76st1kf0ivk/Supersaw-Stereo.hwt?rlkey=qgny2d1l92vd4t0nnb8wd7kf9&st=c0x9u3wl&dl=1

@Lindon It's doable. 6 might be a little much voice count wise with unison voices coming from the synth group melting your cpu...

@dannytaurus you have limited options for what you can put on a waveform generator in a synthgroup.

If you end up not wanting to use the pan control in the header of the Wave Gen, you can also make a polyphonic script fx Panner that, once hardcoded, can be placed on the waveform generator on the synthgroup level as a hardcoded polyphonic fx.

I would try

Synthgroup (this is where your envelope and filter go)

Then inside of the Synthgroup
WG1
WG2
WG3
etc.

You can use the detune in the wave gen but it doesn't update real time, if that's an issue with your design try the purple pitch mod.

@TinyHustlr @d-healey has some youtube tutorials and content on his Patreon too.

@DanH

@clevername27 said in Expandable GUI:

@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.

@d-healey I think keyboard opening and closing is a great use of this feature! It's a feature lot of synths have, and have had for years. Serum is about 10 years old. And it's done this since the beginning.

I know performers who use VSTs in their live sets appreciate show hide that expands and contracts GUI sizes. For example, Omnisphere can close the presets browser view on the left allowing for the user to magnify the GUI for their live set. Obviously you don't need a robust preset browser while playing out live in a soft synth.

Omnisphere standard view

Omnisphere collapsed

@clevername27 said in Expandable GUI:

There are also practical concerns. Most people use laptops. Screen real estate is at a premium. Whenever a plugin is open, it will initially be obscuring some part of their DAW. And the last thing anyone wants is for a plugin to suddenly take up even more space. They may have carefully placed your plugin window so it's not stepping on anything — but if it suddenly gets bigger, all bets are off. When your interface expands, it may not even be on the screen.

But lot of synths use this feature to ultimately reduce screen size.

@clevername27 said in Expandable GUI:

Complex interfaces can also affect your sales. Prospective customers may think the plugin with lots of controls, expandable panels and such — is cool. But it's also overwhelming.

A lot of synths use hide/show and expand/contract to make things less complex. Serum does this, I doubt it hurt sales! Keyboard open is 2048x1656

keyboard closed is 2048x1456.

@d-healey said in Expandable GUI:

I might also use it to display a macro panel, because in this case the user needs to be able to see both the macro assignments and settings, and the controls on the UI that they are assigning those macros to.

Not sure if you're familiar with this vst, but Spire allows users to show/hide macros. It's a nice feature!

macro closed view

All that to say, I see why so many users here have wanted this feature! At the end of the day, developers who care about UX and UI will use this update to make better GUI's and smoother experiences for their customers using their products. To assume, as some have in this thread, that it will only lead to poor design and UX is short sighted to some degree IMO.

@clevername27 I don't think you're considering the use cases where this can be highly relevant and actually improves UX in a given UI and actually goes with what you're saying (less is better).

Here's an example the advanced view GUI.

Here's that same view but after user clicks the settings icon at the top right,

The expanding interface here lets you, in most use cases, to NOT see those controls. Which goes with what you're saying, in that its good practice not to flood users with 100s of options at once.

But when a user does need to access these global controls in this example, they aren't losing their place in the synth and they aren't going to need to tab back and forth if multiple edits are needed in the settings.

Compare this with Serum . The settings pages takes away the ability to edit the oscillators, the filters, and most of the synth's parameters.

So what's a better user experience? To make the user completely leave the page they are on and have to tab back and forth or have an expanded view with the controls that need to be accessed when the user needs them? I think you can make arguments for both, but the ladder is growing in popularity.

Another interesting use case I saw of this is with a emulated compressor. The main GUI has the controls you would see on the physical counterpart, the expanded GUI keeps those in place but introduces new controls with more modern features as well as some experimental features. I think that's an excellent use of an expanding interface.

@clevername27 About 3 years in... I've definitely experienced some weird saving things before but nothing like this! When did you compile last?

HISE has suddenly starting ignoring edits to scripts made in external editors. I’ll edit a script in Sublime (or TextEdit or any other editor), save it, then hit compile in HISE, but the changes won’t take effect until I restart HISE. If I open the script in HISE’s editor and edit it there, it works fine.

The “Save connected files on compile” option in Project Settings has no effect on this. I also recompiled from the source code I had (from 4/29), then tried again using the most recent version of HISE (develop branch) to no avail. I also deleted the config files at ~/Library/Application Support/HISE and let them regenerate themselves… Are there more files somewhere else? (I’m on Mac.)

This just started suddenly yesterday after I’d already been working in HISE for hours. I didn’t notice anything weird, my changes just stopped showing up. No clue what I could’ve possibly done! Any ideas?

@M_Holloway I can't remember if I had this exact issue, but I did have some problem with the newer AAX SDKs and ended up using 2.4.1. You can actually just edit the download link in your Avid account to get the older version. Copy link address and turn 2-5-1 into 2-4-1.

Got this working, thank you everyone for your help! The fix was just updating Visual Studio past 2017. :)

@DanH Thanks! Trying VS2020 now.

Halo 2 looks epic, congrats

Well, after editing little bits of source code and recompiling HISE like 15 times, I finally found it in case anyone else needs to edit this.

The main reference for ALL the green colored sample stuff (back and frontend) is in hi_tools/hi_standalone_components/SampleDisplayComponent.cpp, line 383:

JUCE_LIVE_CONSTANT_OFF(Colour(0xff5e892f));

Just the sample start bar in particular is in hi_components/audio_components/SampleComponents.cpp, line 600:

auto c = SampleArea::getAreaColour(AudioDisplayComponent::AreaTypes::SampleStartArea);

Just change the first one if you want everything but the color to stay the same. If you want to remove it completely, change the second one. You'll also need to change the alpha value on line 607 to 0:

g.setColour(c.withAlpha(0.3f));

You can probably figure out how to remove just the solid line or just the shaded rectangle in the neighboring lines.

Would be nice if there was a way to do this without recompiling but this worked for me for now.

@d-healey Thank you. codesign --remove-signature does the trick.