administrators group

Christoph Hart

@Lindon ah good one I‘ll go through the list and check which ones can be made dynamic.

Christoph Hart

@aaronventure checked a few of those and they are all no low hanging fruits - some are inaccessible to the main controller instance (JUCE_BETTER_MACHINE_IDS), some are actual compile time constants which change the class templates (JUCE_USE_BETTER_MACHINE_IDS)

HISE_SUSPENSION_TAIL_MS was easy to add
NUM_HARDCODED_FX_MODS and NUM_HARDCODED_POLY_FX_MODS are also dynamic now.

I've also added them to the about window and they will read out the exact value that HISE uses (so either the compiled default or the value overriden in the extra definition field).

Christoph Hart

@HISEnberg empty room problem, but as soon as there starts to be demand for it I'll think about a good solution.

Christoph Hart

@Sawatakashi yup apple broke something again, it's also happening here with Xcode 16.3. Just use an older version of Xcode until I figure out what they thought of this time.

Christoph Hart

What is the converter property?

it contains an encoded function for how to turn the value into a string. That might include range, suffixes, or even options (when using comboboxes). I unified this system a few months back so that plugin parameters and MIDI controllers should show the properly formatted text from the values (I think in this case it will affect the range slider display). Ideally you don't need to think about this at all, as it will be handled by HISE automatically).

So if I add this preproc to my project's Extra Definitions for the current system, it will start showing up in the JSON object?

I don't have to build HISE with this preproc?

Yes exactly, I've recently added a function that dynamically pulls some preprocessor values in HISE and uses the static compile time preprocessor in the compiled plugin. This obviously only works with things that do not affect compile-time code, and I have to explicitely implement it for every preprocessor.

I'm open to a suggestion of preprocessors that you might benefit from this - as I said, with some it won't work (eg. HISE_NUM_CHANNELS is being used as a static array size for all multichannel data objects which would slow down the performance within HISE considerably), but HISE_USE_SVF_FOR_CURVE_EQ might be a candidate for this improvement, as it just pulls the value when creating the filter objects.

Why is there no global Extra Definitions field that will apply to all systems?

No idea, but I just paste the stuff I need in all the platforms I want to support and I suggest you do the same :)

Why a preprocessor instead of a method call like you described in the post from 4 months ago? Won't this complicate hopping between projects that use it and the ones that don't?

As I described above, a preprocessor is resolved into a static compile time value, so the compiler might perform optimizations. We can leave that on the table inside HISE for certain things, but moving eg. the number of macros into a function would be a performance regression in the compiled plugin.

These settings will be refreshed when you switch projects and change the field in the settings so it should be about as comfortable as calling a method.

Christoph Hart

@aaronventure Alright, I've pushed the channel filter feature. You have to add HISE_USE_MIDI_CHANNELS_FOR_AUTOMATION=1 to your extra definitions to enable this, otherwise it will retain the old functionality.

I've also updated the docs for the MidiAutomationHandler object so it's not fishing in the dark anymore.

HISE | Docs

(docs.hise.dev)

Christoph Hart

Here I see allowMidiAutomation, but no mention of MIDI in the rest of the example.

yeah, the example is all about plugin parameters, MIDI is a different concept. But it's listed here:

HISE | Docs

(docs.hise.audio)

It basically replicates the enableMidiLearn property of the UI component but for the automation slot.

Christoph Hart

Alright, here it is:

https://docs.hise.dev/glossary/plugin-parameters.html
https://docs.hise.dev/ui-components/floating-tiles/hise/pluginparametersimulator.html

Christoph Hart

@d-healey I've written a huge doc section about plugin parameters, so once the CI build is through, it'll rebuild the docs.

Will I be able to use this with full expansions?

If you compile Rhapsody with HISE_MACROS_ARE_PLUGIN_PARAMETERS=1 then yes.

What is the gesture support, is it MPE related?

Nope, it's a feature in most plugin APIs that tell the host that the user is currently moving a control (mostly so it can deactivate automation lanes while the user drags the knob etc). It's not supported by all hosts, but it will make some hosts behave better.

administrators

Posts

HISE | Docs

HISE | Docs

Member List