Added a link to the app to the SFZ format site, now the SFZ to HISE converter is linked (and thereby HISE itself :) ) from the tools section:

SFZ Creation Tools - SFZ Format

(sfzformat.com)

This should be pretty easy to test out. One developer ID with 2 separate plugin codes. A few testers on different DAWs and machines with different OS versions.

I can be a tester on anyone's plugins. Do not, however, have a project ready or a functioning HISE install, cause of a re-installation issue at the moment...

Very well made plugin, looks great!

@RastaChess The output plugin needs to have your midi-keyboard activated through the tile on your plugin settings page (which I assume you have) to receive midi, as David mentioned. Also you need to add a midi panel for the midi-channels too.

The open source project is accessible here on GitHub:

GitHub - anderseklov/SFZ-to-HISE-converter: JS web app that converts SFZ instruments into a HISE samplemap and a JSON object with opcode data.

JS web app that converts SFZ instruments into a HISE samplemap and a JSON object with opcode data. - anderseklov/SFZ-to-HISE-converter

GitHub (github.com)

I still did not add a release yet, but will soon. Then you can download a minimalistic HTML app and keep in your book marks, work with offline etc. Or just use the live web app.

I made a tool for myself a while ago, a translator for SFZ to HISE samplemaps that worked better than the internal one in HISE did at the time. Since then @Christoph-Hart fixed the importer and it now works better. Even so, I went ahead and made it an open source web app (standard JS) that translates SFZ into HISE samplemaps.

It also does another thing I wanted at the time I started the project and that came from another thing I was doing, which is to gather up all the opcodes into an object form so I could interface and re-work it a bit and save it as data. So this app outputs a JSON object that you can copy to clipboard with a button on the app ui to raw JSON or in a variable form. So either just the object itself { data } or in a var x = { data };.

The project is now on my website, KeyPleezer.com, and you can check it out and test it out and see if it works for you. It can be used for those SFZ instruments that are in structures that HISE has issues with or where settings in the SFZ to HISE converter app can help solve the issue and get you a valid samplemap.

The fact that you get an object with the opcodes makes it possible to output other formats as well, like the DecentSampler.

I will be publishing the source and a stand-alone HTML/JS app on Github soon and then post the links here.

Until then you can test it out in the published web tool:

SFZ to HISE Translator / Converter - online application

SFZ to HISE Translator / Converter application. Converts SFZ instruments into HISE Sample Maps. Use online or download and use on your computer.

KeyPleezer (keypleezer.com)

I wrote a little manual for it as well:

Manual for the SFZ to HISE Translator / Converter application

Online operations manual for the SFZ to HISE Translator / Converter application. Latest version. Read about how the app works and what you can do with it.

KeyPleezer (keypleezer.com)

I'm sure there are bugs remaining in it so feel free to help me test it out and find them, give feedback on features etc.

@d-healey said in Time Stretching:

I think for now this is beyond my C++ level. I'll come back to it again at some point unless someone else implements it first (pleeeeaaaassseeee!!!) :D

Thanks for giving this a go, David! This is indeed an attractive feature for hise! Can't wait for this to work. My C++ is much worse than yours, but perhaps not this guys:

The Audio Programmer - "Implementing a TimeStretching Library (RubberBand)":

(It's a live stream, so watch in 1.5x speed :) , not sure it gives you more insight than you got cause it's for JUCE. Perhaps the Hise part is more difficult)

@Christoph-Hart Okay, I see. Too bad but I see the time-sucking black hole in re-inventing the wheel for you, especially for such a unique computing environment. Already lots of time spend making new features and fixing bugs. Not worth it.

@Christoph-Hart Thanks for the clarification!

The CPUs instruction set for SIMD seems to be a big factor for the actual gains. I found a nice thesis by a guy named Anthony Blake called "Computing the fast Fourier transform on SIMD microprocessors", including lots of comparisons from quite recent machines (i7-2600, around 7yrs old "only":=). It included a high-performance FFT library called SFFT / Spiral, vDSP, Intel IPP and FFW3: (page 140 in pdf)

https://www.cs.waikato.ac.nz/~ihw/PhD_theses/Anthony_Blake.pdf

According to the benchmarks, another library called SFFT (Sparse Fast Fourier Transform) was used that partially trashed the others (FFW3/vDSP/IPP) around the 4-64 bit sets in lots of tests. But according to the Spiral SFFT page:

the algorithm can be faster than modern FFT libraries. However, the reference implementation is not optimized for modern hardware features such as the cache hierarchy, vector instruction sets, or multithreading.

Too bad, would have loved to stare at some more graphs and then going "I wish I understood the context". :) It is now being used in 3D FFT to analyze the trajectories of gravitational pulls or ... well space n shit

@d-healey Thanks for the video, I saw it yesterday and it is really good. He explains it perfectly.

Hi, I'm new to algorithms and C++ and all the tough stuff. I saw a few videos on FFT (Fast Fourier Transform) and the basics of shortening down lots of big iterations, especially for waveform based calculations and deductions. Still, it's a bit fuzzy.

My main question is:

• If an FFT library (such as IPP or FFTW3) is used, is the end code binary (hise executable or your end-software/plugin executable) going to run faster? Or is it just the compilation time that is reduced via the FFT algorithms?

• • aka, does my plugin run faster during it's use if I use IPP/FFTW3 during compilation of it?

@Lindon said in Setting up my M1 mac for Universal binary compiles....:

1. What OS do I need to be running? - I'm guessing its coming with V12(Monterey)

Traditionally the OS that your new mac comes with is the lowest macOS version that you can run, sadly. So if there is a need for backwards compatibility (when is there not?) that may present issues. Virtualization for pure testing can of course be done in VMWare Fusion including sound and drivers actually, but building/compiling via virtualized macOS is ill advised, I tried :(

2. What version of Xcode do I need (bearing in mind that there's at least one of the later versions that wont work with HISE)

Xcode can most likely be run in a few lower versions than the latest, even though the OS is newer and not explicitly supported. Reference the Xcode versions easily here:

Xcode Releases

More than you ever wanted to know™

xcodereleases.com (xcodereleases.com)

Nice overview there. But do download from your account from the link that @orange left above.

I'm compiling for iOS (iPad, Simulator) and getting the old messages Reference to 'Point' is ambiguous and 3 other ones. See image below. I am on Xcode 10.2 / Mojave which builds macOS apps great, but not iOS (HISE Master branch v3.0.1, just released).

I saw some previous threads here about iOS and researched my errors on the JUCE forums and found that they have come and gone multiple times during the last 2 years or so. Some JUCE issues for reference: Juce #1, Juce #2.

Here are my latest build errors

I saw that JUCE community have been battling the Xcode changes for many years when it comes to Reference to Point' is ambiguous messages. Seems that the MacTypes.h was to blame and it seems to be called through the hi_core.mm and hi_core.cpp files.

@Christoph-Hart I am building macOS apps fine, but not iOS apps. Did you fix the "Reference to 'Point' is ambiguous" for macOS? If so, can we do it for iOS as well?

@bthj - I saw your post about successful iOS builds but have questions - how did you solve these issues? (you mention not using the auto-generated Xcode project at Binaries/Builds/iOS/, so what did you use instead?)

@UrsBollhalder - you mentioned before building iOS app with Xcode. If you could expand a bit on the details I would really appreciate it. :)

@orange - you attempted iOS builds also, how did it go?

Happy for any solutions!

My machine:

• macOS Mojave 10.14.6
• Xcode 10.2
• iOS SDK that runs the Simulator is 12.2
• tested Deployment iOS versions: 8.2, 9.0, 9.4 (so far, same errors)

Btw, thanks @Christoph-Hart for making the PKG and EXE releases on the latest Master merges/commits, highly appreciated!

@d-healey said in Cant build with IPP, but I could the last 2 yrs.:

@andioak IPP isn't included with HISE.

Dough! Haha, no it isn´t included, you're right. IPP is just implied as a somewhat good performance enhancement addition.

Okay, I found few examples of (to me less understandable) comparisons of IPP vs FFT3W, but this one of the KissFFT and FFTW3 has some single-precision bumps of around 2-7x the speed:

3.0 GHz Intel Core Duo, Intel compilers, 64-bit mode

(www.fftw.org)

I just read that the GNU GPL contains some kind of linking exception. So perhaps that can apply to using the IPP with a GNU GPL plugin.

I would worry about the opposite order here, the IPP license's reservations to be delivered within the GNU GPL. But of course, GPL-v3 is nasty in its allowances of differences in open:ness, so perhaps your worry is more warranted.

Still I would avoid including any proprietary components in a free software app.

I agree entirely.

@d-healey said in Cant build with IPP, but I could the last 2 yrs.:

Setting up FFTW3 on Windows is more complicated than IPP :D

If the licenses do not marry, it does not matter, you could not use IPP anyway. If a license of IPP does not work to deliver a software or plugin with GNU end licenses, then why is it included in HISE?

@d-healey Ok, thanks for the info.

Is there a way to get that into the main (master branch) md doc, you think? That would definitely be a thing to know ahead of building your first setup and definitely your first plugin. (assuming it is correct that it does not marry with a GNU license, that is :) )

@d-healey Did the Intel IPP have a non-GNU compatible license? I thought it was just in case intel cpu:s were present, use IPP.

So does the FFTW3 have the same advantages over the default fallback, Kiss FFT?

Why is this not in the Readme.md?

@d-healey said in Cant build with IPP, but I could the last 2 yrs.:

@andioak Don't use IPP on Mac, there is no need for it.

Why? There was a need for it before due to the Hise compressed audio and some other stuff. Did that need go away?

@BWSounds said in Cant build with IPP, but I could the last 2 yrs.:

Only with the IPP settings off it will build correctly, but I've have the IPP installed on my computer for about 2 yrs now and I never had this issue...

The IPP libraries are strange, they are deprecated every 2-3 years. The recommendations for installations and support are very narrow for me as a macOS user. As an example the IPP 2019 version only supports certain macOS versions, like 10.13-10.14, 2020 version only supports 10.14-10.15 and things like that. Check the OS support carefully before installing the IPP version, or any upgrade. Intel also hides any version they consider too old. Sucks, was a lot of hoops for me last time.

The shift to C++ 17 caught me by surprise recently, perhaps that has some issue in older versions of IPP.

@Christoph-Hart

• can I build HISE with C++ 14?
• if not, is there a dedicated installation of C++ 17 I can add to macOS 10.13?
• what is the minimum target OS on macOS / iOS for this newest build of Develop branch?
• What is the minimum version of Xcode for building HISE?

Not getting the latest build from this afternoon to build, neither does the one from a few days ago on MacOS.

My system:

• MacOS 10.13 High Sierra
• Xcode 9.2 + IPP 2019
• JUCE library error message is present (but the /JUCE/ folder is used, which I thought was correct, no?)

Xcode still image with the errors:

Not sure how to read that... pleas help.