@griffinboy Yup that has been a sensible request for quite some time now (I think @Dan-Korneff was the OG of asking for that). I'll add another parameter to the container that lets you select the oversampling type).

@aaronventure yup the bugfixes are on my immediate todo list.

@aaronventure great write up, I'll definitely take this advice into account when I'm back working on scriptnode. I understand most of the issues, some are just bugs that have not caught my attention (eg. the faust things), but some are harder to implement:

• multiple inputs / outputs for expression nodes will create the question on when you want to do the recalculation - when the first parameter changes, when any of them changes, and to which outputs do you send it to?
• If I try to remove the requirement for restarting HISE after compiling, then there will be a lot of glitches from intermediate nodes being tied to the old DLL file and all the edge cases - what if the parameter amount changes or the amount of complex data slots? However I think I can revisit how difficult it is to implement - I actually wrote a few things that allow this (eg. that's why the project dlls have a counter in the filename because Windows cannot replace currently loaded DLLs), as I can see that this is a somewhat annoying roadblock in improving the workflow with scriptnode.

and you could click it to switch between the compiled and uncompiled networks. I just checked and that doesn't seem to be a thing any more, or I'm missing a step.

Yup I removed that for several reasons as it created many subtle issues (eg. both the uncompiled and compiled node referencing filter graphs and other shared resources) and in the end the only target audience for that feature was me so that I could compare the compiled and uncompiled nodes as a debugging tool (which should be completely identical in the ideal world).

I got an idea about the node chains: In the last round of scriptnode refactoring (alongside the template stuff) I've added a new "Lock container" function which collapses any container of a network into an opaque node (that looks like it was compiled) which helps a lot with modularizing and organizing big networks. Currently these locked containers are not linked if you duplicate them, but I could add this as a feature so that if you make edits inside one of the locked container, the other containers will update too. That's a complex thing to implement though so don't expect it to happen to soon.

Sorry guys I need a few more minutes the tech is acting up.

@d-healey good for me.

I‘m back on Friday so let‘s doodle that stuff.

@Lindon yeah if we could please not hijack other threads with bumping your own issues. I know there is a lot of stuff that has accumulated over the last months and I‘ll chew through them in a sensible order but it shouldn‘t be determined by who screames the loudest.

@Orvillain I could add a wrapper to Path.contains(), then you can at least create shapes with hit zones using paths and test the hover state with the mouse positions, this relieves you from the burden of weird geometry and a JSON file.

all I know is that I see a lot of people talking about SIMD for pretty much every dsp algorithm

That's because it sounds tempting to just change the instructions of your code and get a 4x speedup, but in most cases you need to rethink the entire algorithm to allow multiple data points to be processed. Eg. with a simple filter algorithm you somehow have to make sure that you rewrite the recursive structure of IIRs (take the last two samples and multiply them with some coefficients) to something else so that it can process 4 samples at once.

I'm very noob when it comes to this area,

I would recommend not focussing on that then but get your algos right, sound good and be reasonably performant. In step 2 you then can learn how to profile hotspots and in step 3 you can try out if using SIMD will yield measurable benefits that you can verify with step 2.

@Orvillain you need to rethink that entire approach, even in JUCE it's almost impossible to query the actual pixel at a given position because the image data is passed to the GPU so the CPU will not now the blended state.

@Morphoice depending on how big your project is, this might explode the complexity of the preset management system so I wouldn't recommend that for anything else than one knob plugins.

Two different topics:

1. Multithreading does only make sense if you can defer some processing so that it doesn't have to be calculated immediately (like the tail of impulse responses or fetching & interpolating samples from disk). This excludes most audio calculations which must happen within the audio callback. There are a few synths which go out of their way to enable multithreaded processing for voices (I think Diva is one of them), but usually a single plugin should never exceed the capacity of a single core for its audio calculations.
2. SIMD on an architectural level (calculating multiple voices with a single vector instruction requires a very narrow architecture of the voice handling & modulation and will not work with a generic solution like HISE. And even then the performance benefit is not worth the programming overhead. If you have a custom narrowly scoped algorithm (eg. a special filter), then rewriting this with SIMD instructions might be a good thing, but even then you won't XIMD for it, but can just use SSE / Neon directly or use the JUCE wrappers.

@d-healey you can definitely use some LAFs that use CSS and others that use scripting in the same interface, it's just that every LAF instance does either run in CSS mode or regular HiseScript function mode.

I think we have to keep the AHDSR envelope as it is and add a new module that gives you more flexibility with a performance tradeoff. The AHDSR envelope is optimized to the bone to be able to be used with hundreds of sampler voices without adding much if any CPU and a flexible envelope with dynamic loop points & adjustable curves is another beast but I second that this might be useful in hybrid synth scenarios or other use cases.

@Oli-Ullmann good catch the broadcaster probably ignores the last event because the index of the changed band doesn‘t change. A quick fix would be to enable the queue of the broadcaster to pass through all events.

@VirtualVirgin Math.pow

HiseSnippet 1317.3ocuX0rbhaDDdDFgiwNaksxt24n2JtnfXu+3JGVa9KgxKXJKVW6dxYrz.LERynHMXa1T4dtky6s7Hjq4leGxKRdCR5YFAHYgYMT1VtJP8OSquomt+ZY5DvsIgg7.jwFcG6SPFaYZMlIFTc.lxPMqgLdhYKbnfDTPqpxXebXHwAYXr1OJUXrQVj55eeaErKlYSloBgNkSsIui5QEyz14finttMvNjtTuXdu2AMs4rpbW9H.OqYVB4isGh6SZiktkwDYjqtCUvCrDXAID7oB2Yr0.9kLs+mRCom6RjBkQVPfzpQUGPcc5LYuFhPFY6Lamuldm+LyVTG5T8yx.eixPgYqHdNvHyhfT4k.RFwfTVMjdpokc.0WLyhDOaZ1jAGH8vPpNNTz9hLt1rJGbfIJ5gGRZD.BSWv1upTocJ.e7hen2HlsfxYE3r1bA4X11uH+ulei7+V9B2zTudy0l7wDvccIAy0r7zMXQKba1HuyIA6T3Br6HxTGgsexbZt6VN0Vuqi4Hm0jQEG6Shjavccj4J48oOAPQoM3t22rFVfkGJQ5.+7IABpDNF0HW.U05inMLqQBGJ39PccpyOnxg6LxEKRVNI6ahL.4iDmgxCJVHULNde0RTiUZg0X2UH9TyNTg8f4iwLyAiPl5g.iQclesY8d8H1hY.LqYiOrpsgkV51v7QsgvyT9v2JRrPiOTdtMf+t4rhc+.hONfzk2wEOd6PrmuK4D.i6T3bWt8PK5mHo6P70PnhzissGfYLha3pzHk6dhbBcBejfx52BKBnWgLLaOxyBnosIUiPGnyHirGRKWRJKqKrHLGkv+AWQFKKkMhLVdhwXsesIhK4ACUGGQ2iLVWm6CUI4y5cUYzgtt7Kqx87oQUovYfRWGt6X+AbF0VpR6wDjdnGeD7Phf6OgC6hotxxZqQg.QgywLKvY0XLi0NkDDpB75lkJB+Ak4s4NfIyFXaHwNtCVLP1uH4dfhSRPQ6oEoIvZ75DYHlLlSmk.H5I25pgbqEirQWOJkftsL5n1L7ToUarK5T44sD7HYLktOAe5AEdvfKMfRf2mGCuyb4wBhFwfXdSOtybP3yhivId7XAvrw.XNUNLI3dhBbPemJ4c+AqbRtXxD.kClSHHHzLV3t3f9DQXzXIFwVWzqNxa5HWQ.vuf5fguHv.esNcTlpT1MmX+oVSh82lv9KfTTYXI1bYiu4lGrktCzeWMY1ZMZnOvJVYDvtq4dSnQlUXNjqlPPTG33bf42pkOgzH99BRuSjfMVKJKJSplR8me9y+8aaguJtND5f+3.KAwWRCG2OqgjK0oj3yg0kNcHATti5UWSEKzB.f5JE.fvdC.nttc.ro463befQOPfREp3O+0eXd9QETohxgiDbOvhyzVonJr0MEX4PlDkXaYB9Nnn1xp1.cy5otxnEN8tEW+T2bu2TL40EGeja6i1eW+2+KutpR9xO8w962Qb9d6pkgO58cRW2WKun9JeBd3b6qTFtO6qtU5f9RVyTzAftG5NwEHjHG0OEweTNp+Rx2mIQN5VIElSOwGuNcOAT+eWHEtt+e87ClzS.3MUTR1SrzbC2Uxoe9aq8OQbCVdbtX.7lZ2DL68k3ltOxCaYdBIjHzQIUrRVGTgyG5gUuj2p8ua8X7JodX6.9YQS6kESekRCTTwT+lDaX1RJWnL5hatakuZvY11ICUpE98q5B2cUW3dq5Be4ptvWspK70q5BeyWdgxeRmn1SIqIz80otlNynNSN8Pw5f9efqsiyv

@aaronventure This was raised before by @tomekslesicki, the symbol indicates that this modulator has the ability to kill notes (hence the panic button icon).

Bad UX, already flagged for redesign when I'm back.

@tomekslesicki I don't think it's something within HISE or some scriptnode flag - more likely a linker issue because of a ARM architecture mismatch.

Looks like one of the more annoying build glitches because of how your macOS build pipeline is set up.

If a vanilla project builds, then there must be something in your project that messes up the build configuration. Check whether the project.xml file contains some funk.

The tempo management is done on the HISE level so there's not much to interact on the JUCE API with for this.

Take a look at this base class:

https://github.com/christophhart/HISE/blob/b46a708644731dc4ba18d4f0aba86681d3894d80/hi_dsp_library/dsp_nodes/CableNodes.h#L371

You need to subclass from this, then override tempoChanged() (see a few lines below for the implementation of the tempo syncer. Basic C++ knowledge about polymorphism comes in handy, but getting this to work should lie within your skillset, so go for it :)