@David-Healey said in Invalid use of incomplete type vSIMDType:

did you make a pull request?

you vastly overestimate my understanding of git

@Christoph-Hart said in C++ Version Preprocessor?:

everything will explode

I am yet to experience an explosion, RTNeural-NAM is using std::span and the Linux/Mac compilers are complaining unless I switch the AutoGeneratedProject.jucer to C++20

C++17 works fine on Windows so I'm not even sure if the span is ever actually created

Edit: Yep it's some weird ghost function which isn't being called anywhere, might be for a specific edge-case but I can comment it out and use C++17

Is there a preprocessor definition (in HISE settings) to set the C++ version for export?

@David-Healey said in Invalid use of incomplete type vSIMDType:

We know the issue isn't in the JUCE modules because those haven't been touched.

The reference to Point is ambiguous error I'm getting is a confirmed JUCE issue (it was patched in a later version of JUCE), but it's caused by a clash with the Rubberband library so it's not HISE's fault. Either way I'm going to test the signalsmith shifter instead which sounds better out of the box anyway

I'm also getting a bunch of fftw errors when compiling your fork (development branch), I assume I need to install that on MacOS?

Edit: Yep signalsmith solved all of my woes

@David-Healey said in Invalid use of incomplete type vSIMDType:

@iamlamprey have you tried a diff between my fork and the develop branch?

not sure what that is or how to do it lol but I'll start googling

Still working at this, found another juce thread:

https://forum.juce.com/t/dsp-module-no-longer-compiles-on-linux-after-april-17th-commit/27684/6

possibly related to the explicit template with jmin? there's a few of those in that monolith file

this clank also fixes that particular error:

// Include this AFTER juce_dsp.h
// It aliases unsigned long to the existing uint64_t SIMDNativeOps specialization,
// fixing builds on platforms where MaskType resolves to unsigned long.

#pragma once

#include "juce_dsp/juce_dsp.h"

namespace juce { namespace dsp {
    template<> struct SIMDNativeOps<unsigned long> : SIMDNativeOps<std::uint64_t> {};
}}

which forces it to use uint64_t, but I'm also getting a bunch of Reference to Point is ambiguous errors so this all might just be xcode doing xcode things...

@David-Healey Whatever the default is, I think clang

I should clarify: this error is happening when I try and compile third-party nodes, HISE itself built just fine. i doubt I could use your fork since mine has Altar-specific changes to include the Rubberband library

This SIMD stuff is quite the pest, getting similar errors on MacOS even after my "fix":

In file included from /Users/user/Documents/altar/DspNetworks/Binaries/Source/Main.cpp:6:
In file included from /Users/user/Documents/HISE/hi_dsp_library/hi_dsp_library.h:55:
In file included from /Users/user/Documents/HISE/hi_tools/hi_tools.h:148:
In file included from /Users/user/Documents/HISE/hi_dsp_library/../hi_tools/../hi_streaming/hi_streaming.h:62:
In file included from /Users/user/Documents/HISE/JUCE/modules/juce_dsp/juce_dsp.h:236:
/Users/user/Documents/HISE/hi_dsp_library/../hi_tools/../hi_streaming/../JUCE/modules/juce_dsp/containers/juce_SIMDRegister.h:85:32: error: implicit instantiation of undefined template 'juce::dsp::SIMDNativeOps<unsigned long>'
    using vSIMDType = typename NativeOps::vSIMDType;

And here's an old post from the man himself:

https://forum.juce.com/t/dsp-module-breaks-compilation-on-linux/27346/4

Seems like it's either a JUCE issue, or just the different behaviors of different compilers

@David-Healey eugh ok thanks for letting me know, between this and the gcc strictness linux really hasn't been a smooth experience lol

@David-Healey said in Looking for Linux Testers :):

Which version of mint did you use?

22.2 Cinnamon, im not interested in ensuring compatibility with edge case distros when the linux userbase is already like 5% AND it's a free plugin lol

also tried makeself, post install script was giving permissions issues despite chmod, got bored and gave up, replaced it with a simple bash script instead

Managed to get Altar compiled on Mint and it's working in Reaper for me, but I expect it will break immediately for anyone else lol

Download: https://github.com/nytemairqt/altar/releases/download/v0.3a-Linux-Alpha/Altar-v0.3a-linux-x86_64.tar.gz

(I think that's how you're supposed to distribute on Linux?)

@d-healey I'm not sure if it's lying necessarily, more likely there's multiple ways to skin a cat

Either way it worked on my end, tested on Ubuntu LTS and the latest Mint

Okay, just had to add my HISE path to that same file

@d-healey Clanker said it was the Linux equivalent of %appdata%

Copying it seemed to get me past the compile wizard, and I can use Compile DSP networks to dll to create the .sh script, but that's all it makes

I don't get the usual folder structure or even the AutoGeneratedProject.jucer file

@Dan-Korneff Yep you're right, I had to copy

~/.config/HISE/compilerSettings.xml

to

~/.hise/compilerSettings.xml

Ctrl + H to view hidden files, for anyone stumbling upon this in the future

ah there's a full 35 min video in the course, thank you sir :)

@d-healey I've got this:

<?xml version="1.0" encoding="UTF-8"?>

<CompilerSettings>
  <HisePath value="home/user/Documents/HISE"/>
  <UseIPP value="0"/>
  <ExportSetup value="1"/>
</CompilerSettings>

Still just asks me every time, I'm not using your fork, do you know if you've made any other changes that might affect this?

@d-healey Did you have to set anything up special? Mine just asks me to go through the Compile wizard forever

Edit: ok im definitely missing something, my Export Wizard asks me for an IDE and the dropdown list is just empty

What's the best way to compile these? I can't open my project without first compiling the nodes, but I can't use "Compile DSP Networks to DLL" because Linux

Do I really have to copy + paste the AutoGeneratedProject.jucer file from Windows, manually set all the module paths and includes and run make every time? Surely there's some equivalent to the Export button that will create the DspNetworks/Binaries subfolder correctly on Linux?

@d-healey chatGPT lol