@Christoph-Hart said in Scriptnode File Player and Round Robins:

nah, that's a different topic :)

Damn, my cunning plan didn't work 🤣

@Straticah Yup the table editor needs a big upgrade imo.

@Christoph-Hart dude you gotta redefine your meaning of "this is complex and will take me a while" 🤣

@DanH Digging this back up as would be a lovely addition going forward @Christoph-Hart 👼

Too many vsts have a chaotic automation list.

@VirtualVirgin Agree!
+1

@ulrik Oh that's a cool solution, thanks!

@aaronventure I would expect it to work in the same way as component value broadcasters and component control callbacks. - I've never tested which triggers first. I think after the callback would make the most sense.

Edit: I just did the test with the value broadcaster and it fires before the component control callback, but I think for MIDI messages it makes sense for the callback to fire first - although I haven't given it much thought.

@d-healey OMG I was just looking at that…that would be dope.

@aaronventure said in [feature request] Working with lots of groups:

It's the only part of the whole dev experience that is below Kontakt's /UI.

Yeah I'd agree on this, although Kontakt's group management is pretty bad too, but it does have the group table in the monitor window which is basically what I'd like to see in HISE.

@Simon yup https://github.com/christophhart/HISE/issues/432

@griffinboy you should use the unscaler node. So, your script controls the network parameter, which goes into an unscaler node, which goes wherever. It then sets its target to the raw value, ignoring range and skew of the target.

@clevername27
Good to know.@d-healey has no problems either. Maybe I shouldn't worry so much and just write to the User VST3 folder... Thanks for your feedback! :-)

@Dominik-Mayer To be honest, I don't like that the titles of unread posts are underlined, because it clutters the look unnecessarily.

@Christoph-Hart bump

@Christoph-Hart Any chance we can get this on your radar? Webp is the preferred image format for websites these days. It would be very helpful to be able to render them in HISE. I believe support was added in JUCE7?

@orange yes

@griffinboy said in Oversampling for polyphonic scriptFX:

although other antialiasing / cramp reduction methods are definitely more efficient and probably better in the long run.

Agree, although it seems hard to understand to me, and implement...

@Christoph-Hart Thank you for wading through my message, and taking the time to thoughtfully respond. It means a lot to me as a (one of many) developer(s). (Thank you, @d-healey, as well.)

stuff that changes internal behaviour (eg. CACHING). When I implement this I will not be thoroughly testing it in all possible use cases because there are too many. And then I'll deactivate it again like 99% of all users which marks it for instant deprecation / regression.

I see your point — isn't that accounted for by making it a preprocessor flag, tho?

On the other hand having a queue not work by default is an instantly recognizable problem which you can address while actually writing the function (BTW the broadcaster system is automatically switching to a queue based messaging if it's necessary so when you eg. attach a broadcaster to a single parameter of a single module, it won't queue because it assumes to just use the current value, but as soon as you're attaching it to one or more sources it assumes that it needs to update all changes so the queue is enabled automatically).

I hear you saying some of these things are instantly recognisable (if I understand you correctly), but I'm not sure that's always the case—if something doesn't seem logical as causing a problem, we may not look there for a solution, regardless of obvious the problems was (once you know).

…lead to clogging and a sluggish UI performance…

Understood, but as a developer, I'd prefer sluggish first (and working), then optimising.

I have to look again but I vaguely remember that you can already recall the default user preset (if you're using that feature). If it's not there then it's definitely a valuable addition.

Default preset, yes (though no Callback flag); Default Values, no. I may be missing something, but I'm confused why Default Values seem linked to Presets—what is the benefit of them as a shared feature, verses the flexibility gained by keeping them separate? Like maybe…

Default Value: The value assigned to a component upon creation (in the compiled plugin), and the double-click value. Default Preset: Values for starting with a specific configuration.

Also a bit hesitant about deactivating this (and therefore clearing out the globals with each compilation). Might lead to subtle glitches that nobody will encounter because it's not active.

Absolutely—but would it be problematic as a preprocessor flag? I'm thinking new developers here, who might not expect global persistence.

I remember you experienced this somehow but I actually don't see a reason why it wouldn't be ordered - sure some things are executed on different threads, but they should all end up in the console queue in a chronologic fashion.

(Understood - I only included it after seeing another user's post about the same issue.)

Script files should be saved though but I think I've added this a few weeks ago (somebody was complaining about external files not being saved with compilation and the fix for this should also implement the save script on save.

(Thank you — I am one of the guilty.)

However this is a thing that I could add as a function (just like setEnableQueue() with the default being on so you can deactivate it.

Be still my heart…

Yeah, I'd rather spend an evening with a glass of red wine and the default preset system to ensure that it behaves sanely than to branch between different opaque execution options.

👍

Can you elaborate on this? I would assume that all callbacks are executed.

I meant that the preprocessor flag I'm suggesting would change this behaviour, so no Callbacks were selected. (Currently, all my component callbacks are wrapped in "if-than"s to ensure they don't fire on startup, because their correct functionality depends on various states.)

I'm not sure if you've checked out the default user preset system yet but it covers a few of the things addressed with these suggestions. The defaultValue property is still useful if you want to change the double click position of a slider (which is almost always zero) from the initial state when you load the plugin (and I'm excluding Protools here because they made the decision to fuck up this distinction on their end).

What I could add is another sanity check that checks if the default value deviates from the value in the default preset and prints a warning (or even autocorrects it).

Indeed—I love (almost) everything about the Default Preset system, particularly that there are Callbacks for before and *after. I remember your note about Pro Tools in the docs…hurray for Avid.

My plugin has over 50 GUI widgets, all of which have different states depending on the other widgets and such…for my case at least, the Default Preset system is the GOAT except for the automatic Callbacks on registration (because none of them are ready to do anything).

Thanks again for your replies and thoughts. 🚀