@griffinboy

Solved, it was me being silly. I checked and it was only certain projects that had the issue.
After investigation I found what I had done wrong:

#include <Windows.h>

^ I had used this line in my c++ nodes,
And it happens that Windows.h has methods with the same naming as some of the Hise files, creating a conflict.

The include was actually in a dsp file that I wasn't even using, which is how I missed it.
But when Hise goes to compile as VST it runs every c++ dsp file, and so the error flagged.

@Christoph-Hart

Thanks
I'll hold off for a bit then,
until you've finished that!

@griffinboy Does this work for the sampler?

https://docs.hise.dev/scripting/scripting-api/synth/index.html#getdisplaybuffersource

so:

the function is indeed called when loading a samplemap and

volume pan pitch

is correctly applied to the buffers, I haven't tested the range properties but they should work too if the other ones are processed.

Are you sure that this is not something else on your side?

@Christoph-Hart

Seems fixed, thank you!

@Christoph-Hart

The core:extra mod node?
I haven't used this node before!

Thanks for your response, I agree, it's certainly a fiddly routing scenario.
Part of me wants to completely write the sampler and everything else in the project from scratch so that everything is custom c++ and can be routed by hand.

However, I'm working with Dan on a project where he needs to use the built in Hise sampler because he's made a ton of monolith and sample map files for the hise sampler...

So my task is to figure out how to play nice with the hise modules while supporting FM between the custom stuff and the hise stuff 😬

@Christoph-Hart said in Parallel Threaded Voices in Hise?:

If your synth is able to max out a single core it won‘t work in a musical context anyway

Maybe I phrased it a little wrong, I'm talking about SIMD.
Many synths for example use SIMD for batching unison voices, or voices in general, or left right channels even, and processing them in parallel. This is common, no?

I was talking about parallelism rather than just threading.

@griffinboy yes it copies the data so that it works across the DLL boundary of the network DLL (otherwise it would be very prone to crashes). Once it's in HISE it will be referenced (so if you attach multiple callbacks they will use the same data object).

@d-healey

Interesting.
Okay I've never done this before I didn't know set attribute could be used that way.
I'll have a go

@griffinboy Thank you! 👍

@Christoph-Hart

Good to know that it wasn't anything bad. It didn't seem to be breaking anything.

Is it okay for me to use this function then? It says that I shouldn't here unless I'm rendering. But I couldn't really see why, so I've been using it

@griffinboy

edit* Rephrased into a more answerable question hopefully!

@Christoph-Hart

08acaf42-bb5e-4882-9a57-48678a5a5f49-image.png

well, all hope is not lost lol

@Christoph-Hart

Thanks I'll look into it!

@griffinboy i suspect that implementation will just be a stretching of the path across a different area, haha.

For multiple channels, you'll probably find it easier to do using the new Rectangle() object.