@Orvillain haha one more lane, bro! I haven't tested 8 pages but I can imagine that it runs against the same node dimension limitation as the parameters before.

Is there a way to update the scriptnode UI with the relevant new parameter

Not without hacks. The best way of thinking about this is a black box communication of parameters into the node. Now if you want to update a UI state that you display on the plugin interface, global cables (and their data callback) are the way to go, there you can easily pack everything up into a nice JSON and send it back to HISE Script (on a deferred thread!), but I wouldn't recommend going the extra mile of updating the internal scriptnode parameters only so that you can look at them in the network with the right value.

@ScreamingWaves I can't offer support for anything else than the latest Xcode because macOS regularly messes up stuff with updates to either macOS or Xcode so we have to agree on something and this is the rule.

Xcode 16 works.

@Lindon yeah, the AI bot scraping is kind of maxing out the server capacity, not much we can do here except for upgrading the server when it gets too annoying.

@blackbneard You're almost there, the only thing you did wrong was using more function arguments than necesssary. setParameter() always requires a single argument that contains the parameter value and all the branching is done with the template constant like you assumed.

template <int P> void setParameter(double value)
{
    if(P == 0) thresh = (float)value;
    if(P == 1) attack = (float)value;
    if(P == 2) release = (float)value;
}

@Orvillain have you tried the new pagination feature? That allows you to subgroup parameters into pages. It looks like this is just an UI problem and having a node with 100 knobs will look very ugly anyways.

Aw poor @VirtualVirgin that was half an hour that you'll never get back, sorry for being not clear enough.

So basically what happens is that I'm taking the markdown files from GitHub to build the HISE docs website. The documentation generator takes some autogenerated code and merges it with the additional text from GitHub - this way it stays always up to date and the formatting is consistent.

Now the problem was at some point (and we discussed this at some HISE meetup) that the user engagement with the task of contributing to the HISE documentation is mostly hindered by the complicated system that people have to follow in order to write the docs so we came up with the solution that the HISE documentation generator just creates these empty markdown files for all undocumented API methods that have the proper file name / folder scheme so that they will show up later in the docs. From there, people can just edit the empty files to add more context, code examples or more thorough explanations than the one liner API help that is being extracted from the HISE source code.

So what looks like a bug to you - empty text files - is actually a feature that is supposed to lower the barrier for user contributions.

@Straticah nice one, looks great!

They are autogenerated and empty so that you can edit them and fill the gaps :)

@Orvillain I think maybe my example was not the best one. The complex group system is only useful if you need something ... complex and if all you have is RR groups then you don't need it at all - in fact the normal RR system even has a function where it precalculates the number of RR groups for each velocity / note number and automatically wraps around that, which is a far more suitable solution for your use case.

The complex system is getting useful if you have to combine multiple things, eg. crossfade dynamic layers with RR groups or legato transitions with crossfade, etc.

@Orvillain I'm ignoring all the UX suggestions and minor glitches as I'm completely unsatisfied with how it behaves at the moment and I will have to do a third or fourth complete redesign of the UI of this thing.

The only glitch I see in this video is that if you have more than 2 groups (eg. 5 or 8) it still only performs 3 groups - probably it knows that there is no sample in the last group and then it resets the counter, but I'm not sure why it does that.

But in general it's expected that you use as much RR groups as you have RR variations, so you're already in weirdo land if you use more RR groups than samples.

Now if you have different amounts of round robin variations within a single samplemap you can achieve this by using multiple RR layers - which is where this complex system starts to show its strength, for simple RR stuff you don't need that in the first place.

So let's assume you have closed hi hats and open hi hats in the same sample map. For closed hi hats you have 8 RR variations, but for the open hi hat you only have 6 RR variations. You cannot setup a single RR layer to work with both types, instead you need to create 2 RR layers:

1. One for the closed hi hat samples with 8 groups
2. One for the open hi hat samples with 6 groups

And then we assign the closed hi hat samples to be cycled by the first layer and the open ones by the second. Now comes the important part: in order to tell HISE which samples are subject to which layer you can use the Ignore flag (so in this case both layers need to have the ignore flag enabled). This works like this:

1. Assign the closed hi hats to their respective group in the first layer
2. Assign the open hi hats to their respective group in the second layer
3. Assign all closed hi hat samples to the ignore group in the second layer
4. Assign all open hi hat samples to the ignore group in the first layer.

Note that this idea can be combined with any layer so you can create very complex group arrangements. If only the UX would make it easier to understand that stuff...

here's a new page/group system

You can also add a new page / group using the context menu of the parameters in the DSP Node List on the left, this is more convenient than editing the property in the generic editor.

Am I understanding this correctly and we are talking about playing notes on the actual computer keyboard? If yes, why is this an issue, is anybody using that except for testing if a note is playing?

Have you checked whether this happens with other plugins too? Some computers do not allow more than two keys pressed at the same time, maybe it's a system wide issue?

@d-healey yup, +1 for the linkTo solution, that's precisely how it's intended to be done.

@Lindon you could even use HiseScript to write a batch processor that perform these steps, fun little excercise and you'll get to know the Buffer class which is highly useful when operating with wavetables (you can compute any wavetable and feed it to the wavetable synthesiser once you get the hang of it).

@Lindon yes but even then it's easy to create discontinuities which mess up the harmonic spectrum. In that case just try the resynthesiser, it basically does resampling with a few tricks like this.

@Lindon funny, almost all wavetables I checked that came from external sources were already power of two so I assumed that was some kind of industry standard.

You might run into issues when trying to resample a single cycle length depending on the interpolation technique you choose, it might cause some discontinuities at the start / end of the cycle.

@Orvillain that's such a basic optimization technique that I would expect any compiler made after 1975 will incorporate this.

If you don't trust that, you can easily do this yourself:

buffer[i % 4096]
buffer[i & 4095]

these are equivalent statements with integer numbers, one costs 88CPU cycles, and one is for free (~1 CPU cycle).

If you want a good read, this is the quasi standard reference for comparing CPU instructions. You need to dig around a bit to find what you're after, and again, you're basically doing yourself what the compiler will do for you already so it's purely educational:

https://www.agner.org/optimize/instruction_tables.pdf

the assembly instruction for division (and modulo) is IDIV which clocks at 88 CPU cycles. AND takes a single CPU cycle.

@ustk pretty sure you can attach a mouse broadcaster to the viewport.

@Orvillain said in Ring Buffer design:

because you avoid modulo and branching in the inner loop.

If your buffer size is a power of two (which it always can be, just round it up), then modulo boils down to a bitwise AND operation with even the lowest optimization settings. This vastly outperforms the performance impact of having a bigger buffer, so I'm not 100% sure this is worth the hassle.