@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!
@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.
@Christoph-Hart Once you learn how to use the WT conversion tool, it is quite powerful! I think you did a great job with it. I'm able to use it to make great sounding instrument tables, synth tables etc.
For everyone complaining that it only spits out nasty fm'y tones, see exhibit A, a video of various types of good sounding wavetables in Hise. Be gentle, I am a novice keyboard player.
Christoph, would you ever consider adding a phase random control for the WT module in Hise? The waveform generator doesn't have that either. It would be a really nice synthesis feature to have in Hise for at least one of the synth based modules.
@Morphoice Duda spent a good amount of dev time and $$$ on the dsp behind how Serum crunches numbers in the oscillators. If memory serves they use SSE2 instructions to allow for cpu efficient yet really clean/stable oscillators (clean being the lack of artifacts.)
@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.
@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.
@Lindon Are you sure? I've tried in 3 different commits. One is the most recent and the others are from July. Also does it on both Mac (Big Sur and Sonoma) and Win 11.
If I load up an Effect Slot and try to select HardcodedPolyphonicFX, HISE instantly crashes. It doesn't crash when I select the Hardcoded Master FX option, just poly.
Any ideas?
What does this button do? It doesn't seem to do anything. Not sure if it's broken or being overridden by other settings?
@clevername27 said in Are scriptnode delays not accounting for block size and oversampling?
- Is it possible to use oversampling with a polyphonic ScriptNode Network?
I don't believe it is possible due to the voice handling/polyphony architecture in hise.
@TinyHustlr @d-healey has some youtube tutorials and content on his Patreon too.
Trying to wrap my head around why you can use this node in a network but can't compile said network to a dll. I'm sure I'm missing something here. Does anyone know?
If you try to load up a oversample node, for example, in a polyphonic network you get a red error message telling you about the folly of your ways. Not so with the pitch mod. It lets you get all the way to 3rd base allowing you to click "Compile DSP networks to DLL" before prompting an error message.
Thanks for any insight guys.
@Christoph-Hart How would you go about getting the Freq Ratio knob in a core.oscillator to work with a Pitch Modulator in the tree?
I have a Waveform generator with a purple voice start constant pitch mod (for detune).
I have a polyphonic script node network using the core.oscillator as a modsource to introduce AM.
If I detune the the pitch mod to anything other than +-12, it sounds awful. Lower notes sound like there's a slow LFO and higher notes sound like there's a fast LFO.
I thought I found the fix - I added a core.pitch_mod to the modchain and connected that to the Freq Ratio Knob.
There's only one problem.
You can't compile a dsp network with the core.pitch_mod. What other node could I use to achieve the same thing?
Thanks!
@aaronventure Sorry to necropost but i found what you had to say really helpful, so thank you! It did lead to one question however...
Would you happen to know when or why you'd want to use a specific block node (256 block, 128 block, etc.) vs blockx?
@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.
@Allen Have you tried just leaving them in the HWT format?