Hive 2.1 public beta 02 revision 10947 (incl. native Silicon M1 support)

[Ploki]

non-WT track count is much bigger, and the difference is better pronounced at smaller buffers as well.
M1 speed bump is around 15% - which isn't shabby, honestly.

Unfortunately i don't have the i7 mini anymore to test hive on it. But i have Diva Project file and numbers from the i7 so i'll be able to compare that.

(i think i swapped cpu usage for WT test 64 buffer, M1 is lower)

[Urs]

so... -ffast-math?

I think it sounded aweful for some reason and wasn’t doing much. Don’t really remember, I haven’t dealt with Compiler flags in a decade.

[Ploki]

i think it's what Aleksey (voxengo) and Spire devs used to make M1 builds go brrrrrrrr
Aleksey said that -ffast-math cancels down to -150dB RMS on his plugs, but it made his M1 build about 20% faster (both in Reaper and Logic). Apparently it makes no difference on x86.

Reveal sound also said something about "vDSP library with an SSE adapter and included denormals for the ARM"

Might be worth giving it a spin

[Urs]

It’s not that simple usually. Iterative solvers for instance benefit vastly from higher precision. Hence, what you might gain in the code that isn’t written in NEON already, you might lose in the Shape Sequencer.

In Repro for instance, I went with division instead of reciprocals because it saved a few iterations and was thus faster quite often.

Anyhow, I’ll mention it to the guys. I am sure they already tried any option that was offered.

[fgimian]

The mousewheel scroll direction in the preset browser is still really confusing for me, it's absolutely the wrong way here on PC / Windows 10. Urs, can you please correct this or at least add an option to reverse it?

I'm sorry to quote myself, but Urs can you please address this one? It's really quite annoying to deal with and should be a quick fix.

Thanks heaps
Fotis

[fgimian]

I do have one pretty major gripe with Hive which I've forgotten to mention and it's just bit me in the butt

Hive deals very poorly with missing wavetables. So let's say for example, you copy a custom wavetable path to the Wavetables directory and use them in a few instances of Hive within a project. Let's then say this project is opened on a computer that's missing this directory of wavetables.

• Assuming Hive windows are not open, no dialog box appears while opening the project to advise that the files are missing (similar to what Battery or Kontakt would do)
• This is the scary one, if you save your project while the files are missing, and then restore the files and re-open the project, those presets are destroyed because Hive resets the wavetable back to a sine wave and loses the original location

This literally just happened to me today and I now have to backtrack to the last working version of the project and export / import presets into the newer versions which have lost their wavetable selection.

Most other wavetable synths embed wavetables into the preset, and while this does have some drawbacks, they're nowhere near as severe as what we have here with Hive.

At a very minimum, missing wavetable locations should be retained even when saving a project which can't find the respective files, so that later restoring still allows you to save subsequent versions of a project that was saved while they were missing.

Now off to go fixing my project

[Urs]

Sorry to hear that. To be honest, we expected more problems with wavetables going amiss, but after two years this is the very first time I see any such issue mentioned. So until today we were under the impression that there is no problem. We have already collected about 10 improvement tasks which were never touched since it did not seem to be necessary.

Preserving the missing WT in the project seems like a very good start.

I'm reluctant to open dialog boxes. But in this instance it probably does make sense, particularly if we can somehow detect "use opened project file, might not open plug-in editor window". One of the improvement tasks is a system file browser that opens for the user to select the path to the missing wavetable. I'll promote this to a higher priority, but that'll take until at least the next update to implement.

Regarding storing wavetables in presets, this will stay a no no for us. Sample instruments have worked like this for decades, there's no reason to assume that wavetables should be any different. Nevertheless, .uhm scripted wavetables might make it into presets directly, at least to a certain length. This is however in contradiction to another improvement we're going to explore, i.e. caching complex .uhm scripted wavetables as .wav files to speed up loading time.

[fgimian]

Sorry to hear that. To be honest, we expected more problems with wavetables going amiss, but after two years this is the very first time I see any such issue mentioned. So until today we were under the impression that there is no problem. We have already collected about 10 improvement tasks which were never touched since it did not seem to be necessary.

Preserving the missing WT in the project seems like a very good start.

I'm reluctant to open dialog boxes. But in this instance it probably does make sense, particularly if we can somehow detect "use opened project file, might not open plug-in editor window". One of the improvement tasks is a system file browser that opens for the user to select the path to the missing wavetable. I'll promote this to a higher priority, but that'll take until at least the next update to implement.

Regarding storing wavetables in presets, this will stay a no no for us. Sample instruments have worked like this for decades, there's no reason to assume that wavetables should be any different. Nevertheless, .uhm scripted wavetables might make it into presets directly, at least to a certain length. This is however in contradiction to another improvement we're going to explore, i.e. caching complex .uhm scripted wavetables as .wav files to speed up loading time.

Thanks so much mate, and sorry if I seemed a little frustrated above. Luckily it was an easy fix for me this time.

I think preserving lost wavetables in presets alone would be a huge improvement. If you could possibly add that fix for 2.1, I think it would be a really good improvement and at least help avoid people losing certain parts of their work.

Really appreciate your help
Fotis

[Urs]

(I actually thought that links to missing WT files *were* preserved when projects were resaved... I'll make a ticket for Tas to investigate this)

[fgimian]

(I actually thought that links to missing WT files *were* preserved when projects were resaved... I'll make a ticket for Tas to investigate this)

Thanks heaps, happy to provide any assistance required. I reproduced this on Cubase 11.0.0 on Windows 10 using the VST3 version.

[mcnoone]

Thanks for this update.
I'm going to try it out on my m1 system today.
If I find some issue, I'll let u-he know about it.

[EvilDragon]

Regarding storing wavetables in presets, this will stay a no no for us. Sample instruments have worked like this for decades, there's no reason to assume that wavetables should be any different.

Er, no. Wavetables should be different.

Storing the wavetables in the plugin data chunk is the best thing you can do. Surge does it and it never has problems with missing wavetables. It is not even a big deal (especially with UHM), since you only have two loadable wavetables. Even at 256 frames 32-bit that's 2 MB per wavetable, definitely something you can afford for Hive. Surge has 2 scenes with 3 oscillators, so that could be 12 MB max (or even more since we support wavetables up to 8192 samples per frame and I think 512 frames max).

Vital does the same thing, and I'm sure a number of other wavetable-based synths do exactly the same. Because it makes sense since wavetables don't imply gobs of multisamples being loaded!


Say I wanted to load a 10+ years old project that used some custom wavetables, that after changing x computers in that time I forgot to copy over (or have no access to anymore for whatever reason). Would it not be better if the project just contained the wavetables used instead of presenting me a dialog that's something like "hey, remember that ultrarazorsharphellraiser wavetable you used 10 years ago? Well I can't find it! Where is it?" and you stare blankly because the name of the wavetable doesn't ring any bells, let alone where you might dig it out from.

It's simple. Plugin data chunk should contain the wavetables. Easy!

[Urs]

ED, you're wrong about this in our case. We have humungous amounts of presets and there is a manifold of that available from 3rd parties out there. Making each preset into a 4+MB blob would cost several gigabytes of absolutely redundant data.

Even more so in Zebra3 which will offer many more wavetables per patch.

(also, as I said, this is the first time there's an issue in two years... I think it ain't as bad as it sounds)

[EvilDragon]

Oh I am NOT saying the PRESET should contain the wavetable (although, it would be a good option to have, IMO). After you load the preset, the wavetable referenced by the preset would be serialized into plugin's data chunk.

[Shiek927]

Are there any good examples yet of the comb filters in action?