@Christoph-Hart Yes, GDExtension is the framework for creating the dynamic libs, but I have no formal training in C++, so I have no idea how involved it is to write an API.

@ustk Ah that's good, now I need ChristophGPT to implement it :)

@ustk said in Making standalone app with offline/batch features?:

... I don't think it is possible to batch or treat offline using a scriptnode graph. But I reckon SNEX can use the nodes in code so there might be a possibility to use them offline too.

Thanks, yes I dug a bit into the api on docs.hise.audio and found a few things perhaps able to take care of some of it.

Standard Hise API:

File.createDirectory, File.getChildFile, File.getParentDirectory, File.show -- link -- check, check, check & check. AudioFile.loadFile -- link Engine.loadAudioFileIntoBufferArray -- link -- "Loads a file and returns its content as array of Buffers." -- perhaps able to do the data store.

In the Scriptnode List of Nodes I found control.file_analyser, (link 📖), which surely must do it's job offline. Perhaps there is a way to cue samples (blocks of samples) to be run through any module or chain? Then there's the core.file_player, (link 📖), which also handles audio files possibly offline. Both of these though are farily simple modules with no extras in the docs. The docs are void of any descriptions of the Scriptnode list of nodes, at least on the committed docs.

Perhaps it is something one has to code yourself in SNEX as you say, but then perhaps the real idea is to have a processor handle all things hise in offline mode. Not even beginner in C or C++ so would not know where to start. The method could be to pipeline all audio blocks in an array of files through the code. Haha. Just stuff it in there, nice and thick. 😬

@d-healey Well the sets are not correct, SSE 4.2 is NOT the highest or newest that HISE uses. Most likely AVX and AVX2 aswell. Or indeed I would have to dig out that old spiked-on AMD cpu in my intel machine.

Architecture = "native" is the issue. It over-rides any setting you make in hise. It uses your build-cpu´s sets available to do the best enhancements available. And whoever said IPP is the only thing in need of higher sets hasnt read the amount of issues on this topic over at the juce forums.

Setting Architecture to x64 in the .jucer project is the ONLY thing I was able to start my instrument build with. That flattens it to x86_64, which is basic original specs of the first 64-bit cpus, so no SSE3 or above, most likely.

@d-healey said in Linux standalone instrument application and settings folder locations:

/home/.config is a folder. . on GNU/Linux means the folder is a hidden folder. The default vst folder is /home/.vst or /home/.vst3/ and LV2 plugins go in /home/.lv2`. I'm pretty sure most users are familiar with this.

Windows and (especially) MacOS like to tell users what to do, GNU/Linux is a little more flexible generally, depending on the distro and desktop environment.

Okay, that´s a big part of why a lot of people choose Linux instead of the others. That´s a part of the platform and most experienced users or intermediate will handle that fine. The obviousness/strictness of a mac is a big part of why an answer can be found almost anywhere. And having rules for it is a big part of a platform. Nevertheless, freedom is in the whole Linux air. To be respected.

You can download an installer I created here to try it out.

Will do! Thanks a lot for the info.

This info should really go in the docs. The paths on Linux is an essential part of docs. One fine day. Perhaps I´ll get there first, you never know.