@Alatar said in Audio Engine Sample Rate?:
Is HISE using an internal sample rate, which is different from the host sample rate?
Hise plugins run at the DAW sample rate.
The Hise app itself runs at the sample rate you choose in the settings.
Resampling may occur somewhere else on your PC, but Hise is trying to match whatever it's told.
The sample rate conversion is immediate. It happens during runtime.
The rate at which the sample is played back (in other words the pitch) takes project vs file sample rate into consideration.
The sampler plays back the file at the right speed for whatever sample rate the Daw reports to the plugin.
After all, a sampler that plays back sounds at a different pitch is a resampler by definition. So all the work can be done at the lowest level in the sampler, outputting the samples at the correct sample rate (speed) to begin with.
yeah this is what shows when there is an error, it stops at this point and prompts the user to close the window, without the Completed message.
What's odd is that there is no error message above.
There definitely is some kind of error here. Its refusing to compile.
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.
Latest Hise Build, Juce 6.
I am unable to export to VST3 on Windows.
Full Console:
Re-saving file: D:\Projects\Hise Projects\Griffin_Test\Binaries\AutogeneratedProject.jucer
Finished saving: Visual Studio 2026
Finished saving: Xcode (macOS)
Finished saving: Xcode (iOS)
Finished saving: Linux Makefile
Compiling 64bit FX plugin Griffin_Test ...
MSBuild version 18.3.0-release-26070-10+3972042b7 for .NET Framework
Plugin.cpp
PresetData.cpp
factory.cpp
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(333,4): error C2872: 'Rectangle': ambiguous symbol [D:\Projects
\Hise Projects\Griffin_Test\Binaries\Builds\VisualStudio2026\Griffin_Test_SharedCode.vcxproj]
(compiling source file '../../../AdditionalSourceCode/nodes/factory.cpp')
C:\Program Files (x86)\Windows Kits\10\Include\10.0.26100.0\um\wingdi.h(4639,24):
could be 'BOOL Rectangle(HDC,int,int,int,int)'
D:\Projects\HISE-develop\JUCE\modules\juce_graphics\geometry\juce_Rectangle.h(66,7):
or 'juce::Rectangle'
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(333,4):
the template instantiation context (the oldest one first) is
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(365,95):
see reference to function template instantiation 'juce::Rectangle<float> hise::simple_css::Positioner::slice<
hise::simple_css::Positioner::Direction::Top>(const juce::Array<hise::simple_css::Selector,juce::DummyCriticalSection
,0> &,float)' being compiled
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(333,14): error C2062: type 'float' unexpected [D:\Projects\Hise
Projects\Griffin_SpringReverb\Binaries\Builds\VisualStudio2026\Griffin_Test_SharedCode.vcxproj]
(compiling source file '../../../AdditionalSourceCode/nodes/factory.cpp')
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(336,33): error C2065: 'copy': undeclared identifier [D:\Project
s\Hise Projects\Griffin_Test\Binaries\Builds\VisualStudio2026\Griffin_Test_SharedCode.vcxproj]
(compiling source file '../../../AdditionalSourceCode/nodes/factory.cpp')
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(336,16): error C2530: 'toUse': references must be initialized [
D:\Projects\Hise Projects\Griffin_Test\Binaries\Builds\VisualStudio2026\Griffin_Test_SharedCode.vcxproj
]
(compiling source file '../../../AdditionalSourceCode/nodes/factory.cpp')
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(337,37): error C3536: 'toUse': cannot be used before it is init
ialized [D:\Projects\Hise Projects\Griffin_Test\Binaries\Builds\VisualStudio2026\Griffin_Test_SharedCod
e.vcxproj]
(compiling source file '../../../AdditionalSourceCode/nodes/factory.cpp')
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(346,25): error C2672: 'hise::simple_css::Positioner::RemoveHelp
ers::slice': no matching overloaded function found [D:\Projects\Hise Projects\Griffin_Test\Binaries\Builds\Visu
alStudio2026\Griffin_Test_SharedCode.vcxproj]
(compiling source file '../../../AdditionalSourceCode/nodes/factory.cpp')
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(306,50):
could be 'juce::Rectangle<float> hise::simple_css::Positioner::RemoveHelpers::slice(juce::Rectangle<float> &,floa
t)'
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(346,25):
Failed to specialize function template 'juce::Rectangle<float> hise::simple_css::Positioner::RemoveHelpers::s
lice(juce::Rectangle<float> &,float)'
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(346,25):
With the following template arguments:
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(346,25):
'D=hise::simple_css::Positioner::Direction::Top'
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(306,33):
'Rectangle': ambiguous symbol
D:\Projects\HISE-develop\hi_tools\simple_css\Renderer.h(306,42):
syntax error: missing ';' before '<'
Press any key to continue . . .
Is this a bug, or something I've not set up correctly on my end?
Indeed!
I've also got someone after this. But judging from the lack of movement on this, my guess is that it's troublesome to implement
I do custom dsp for Hise.
Analog modelling, circuit similation, synthesis engines. Adapted from latest research.
The scientific side is my specialty.
Looks fine! Especially for something like an LFO selection.
See how tiny the Ableton dropdown selection boxes and multiple choice buttons are in the background?
Ah!
How bizzare.
Yes now I remember, Asio doesn't like multiple different apps trying to leach audio. I remember now, I switched ages ago to a different driver because of this. It pained me to do so.
The OBS beta capture does work with Hise on my machine.
I'm on Windows. I'm sure it works differently for each OS.
It's very picky about capturing audio from exact window names, unless you set up the following option. So if you're getting silence it could be because of this. But I assume you've already tried fiddling with all the available options by this point, so that's probably not useful advice.
Does the regular system wide capture not work?
I use virtual cable on windows for any custom routing.
And I alternate between using OBS system wide audio capture, and the experimental app audio capture feature, depending on my needs at the exact moment
If you want to record high quality audio without alias / resampling issues please record to mkv in flac format. Default OBS has audio artefacts that are audible.
@Phelan-Kane
I've yet to use the matrix modulator with any filters, I think this is an issue for @Christoph-Hart to have a glance over!
That being said, any dsp I've posted on the forum is long overdue an update, most of those posts were incomplete dsp, given out as a starting point, with the intention that it would be modified. Robustness is one of the things that was not fully fleshed out.
Although, if even the default hise filters are failing, I doubt it's an issue to do with that, since all the default Hise filters are simple designs chosen to be modulation safe.
It sounds like OP has already tried that. And that method does work, sending json packets to a c++ node and back again via global cable works fine. I doubt that Christoph will add anything bespoke for this since it's a method that technically works fine.
I do agree that it feels a little bit hacky to use, but in practice it works and I've not hit any project killing limitations with it yet. You can organise all the offline c++ logic neatly if you create a single node to interface with hisescript, and design a data packet key so that you can call your c++ functions using keyed data packets down global cables and it will know what c++ functions to call based on that.
Possibly a thing that would make a bigger difference is improving the c++ node template with more features and callbacks. I find it quite fiddly to implement proper offline processing in c++ nodes, you have to do all the threading yourself. The nodes feel like they are designed for straightforward sample in sample out processing and the optimizations sometimes step on your feet.
If I think about it properly, even I left Kontakt after creating one instrument. I didn't like the way it was coded and I couldn't do the things I needed to in the framework. Plus expensive for indie + Kontakt is forced to be so backwards compatible that it's practically frozen in time.