@d-healey @d-healey said in Sliders not responding to "Consumed" MIDI CCs:

setCustomAutomation

Now that I've had a bit more time, there are a number of hurdles with using this method.

Issues Encountered

MIDI Learn disappears
The "MIDI Learn" option no longer appears in the right-click context menu of knobs — unless an automationId has been manually assigned in the Properties panel.

automationId overrides control callbacks
Assigning an automationId disables the knob's regular controlCallback, which is where most of my knob logic lives (e.g., updating processors, linked components, states, etc.).

Workaround via automation callback
You can attach a callback to a specific automation and call the original controlCallback logic from there — but this adds boilerplate and breaks modularity.

Avoiding feedback loops crashes HISE
Trying to assign a knob as the target of its own automation (to bypass issue #2) results in an infinite loop that crashes HISE.

Controller numbers don’t carry over
If you switch the automationId to a new target, the MIDI CC assignment doesn't carry over. It must be learned again manually — making it difficult to share CC control across multiple processors or targets.

🤕

@CyberGen Can you make a minimal example that demonstrates the issue with the scripts in those positions?

@CyberGen you're absolutely right, but this would break backward compatibility. So making your own array seems to be the solution for now.
In the waiting for a HISE_USE_NATURAL_TEMPO_ORDER preprocessor ☺

@CyberGen said in Dynamically switching processorId of an AudioWaveform Tile.:

should I add this to the gitHub issue list?

Can do

@DanH ok, that explains it. Thank you!

@Lindon @bendurso @d-healey Thank you guys, these are great suggestions. Much appreciated. I haven't had a chance to sit down to try to implement them yet. I'll let you know how these work out as soon as I give them a try.

@CyberGen I have the same problem on Linux.

@CyberGen Well, just by messing around, discovered that you can put the numbers instead of the builder.ChainIndexes.... So it's zero based:

builder.create("GlobalStaticTimeVariantModulator", "Attack Time Mod", ampEnvelope, 0); // for Attack Time, 1 for Attack Level, etc.

😁

@CyberGen While we're at it, typing a string in the Component Browser could reveal components with that ID.

Same here.

@CyberGen Nope

@Matt_SF Thank you for this example. My old code worked in this way. The issue is that now I am not declaring knobs in the standard Content.getComponent() way. I'm using objects. As in reg UIObjects = {}; and these do not seem to be added as attributes to their parent script like normal const var do. I was wondering if there was a different way that wouldn't require the use of const var nor global references.

@d-healey said in Button.setValue(1) oninit not reflected in UI:

The default value of buttons seems to not be useful.

@d-healey yes. The project needs at least one expansion.

@CyberGen fortuitously discovered that setting the ignoreNoteOn to 1 acts as a reset signal. Whenever triggered, the LFO goes back to the start of it's cycle without having to play a note. You might sometimes need to set it back to 0 immediately (depending on what's required of the LFO) but it's a good workaround. :clinking_beer_mugs:

@d-healey awesome! thank you.

@CyberGen A list of License Manager API endpoints. Might be useful for those using the License Manager API.

Base Endpoint:
/wclm/v3
Methods: GET
Description: Base route for the wclm/v3 namespace.
Verify License:
/wclm/v3/verify
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for verifying a license.
Activate License:
/wclm/v3/activate
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for activating a license.
Deactivate License:
/wclm/v3/deactivate
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for deactivating a license.
Get License Details:
/wclm/v3/get-license-details
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for retrieving the details of a license.
Get Product API Meta:
/wclm/v3/get-product-api-meta
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for retrieving product API metadata.
Get License Status:
/wclm/v3/get-license-status
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for retrieving the status of a license.
Get Current User Licenses:
/wclm/v3/get-current-user-licenses
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for retrieving licenses associated with the current user.
Register License Key:
/wclm/v3/register-license-key
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for registering a new license key.
Set License Status:
/wclm/v3/set-license-status
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for setting the status of a license.
Create License Key:
/wclm/v3/create-license-key
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for creating a new license key.
Update License Key:
/wclm/v3/update-license-key
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for updating an existing license key.
Delete License Key:
/wclm/v3/delete-license-key
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for deleting a license key.
Add License Key Meta:
/wclm/v3/add-license-key-meta
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for adding metadata to a license key.
Update License Key Meta:
/wclm/v3/update-license-key-meta
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for updating metadata associated with a license key.
Delete License Key Meta:
/wclm/v3/delete-license-key-meta
Methods: GET, POST, PUT, PATCH, DELETE
Description: Endpoint for deleting metadata associated with a license key.

Well this might not be directly related to the topic but I find the etc/etc/etc/etc.... is kinda annoying too in the Script Editor's dropdown, despite the files in question are in the GLOBAL_SCRIPT_FOLDER

Screenshot 2024-07-10 at 21.03.47.png

Why not having something like this:

Screenshot 2024-07-10 at 20.40.17.png

Or this:

Screenshot 2024-07-10 at 20.45.09.png

EDIT: that last one should go in the first dropdown, my bad...

But I much prefer the first solution. I personally don't like accessing the script from the drop down because you have to firstly create a tab and making it a script editor. While a double click in the Project Directory does it for you.