[.uhm] FM Synthesis in Hive

[drzhnn]

My first working iteration of FM vowels script (A, AE, I, U):

Code: Select all

NumFrames = 4
Envelope L0=1 T1=1 L1=0

// A
Wave start=0 end=0 "sin(2*pi*phase*5)*env(phase)*2"
Wave start=0 end=0 "sin(2*pi*phase*6 + x)*env(phase)*0.5"
Wave start=0 end=0 "sin(2*pi*phase*4.5 + x)*env(phase)" blend=sub

// AE
Wave start=1 end=1 "sin(2*pi*phase*3.5)*env(phase)*2.5"
Wave start=1 end=1 "sin(2*pi*phase*4 + x)*env(phase)"

// I
Wave start=2 end=2 "sin(2*pi*phase*13)*env(phase)"
Wave start=2 end=2 "sin(2*pi*phase*2 + x*0.8)*env(phase)" 

// U
Wave start=3 end=3 "sin(2*pi*phase*8)*env(phase)"
Wave start=3 end=3 "sin(2*pi*phase*3.5 + x)*env(phase)"
Wave start=3 end=3 "sin(2*pi*phase*1.5 + x)"

Envelope L0=0 T1=0.5 L1=1 T2=0.5 L2=0
Wave "lowpass(main, 0.95*env(phase), 0.1*env(frame))"

Spectrum lowest=0 highest=0 "0"
Normalize base=each

https://soundcloud.com/drzhnn/uhm-wavetable-test-8

[hollo]

Thank you and thanks for all of your other tables as well

[drzhnn]

Thank you and thanks for all of your other tables as well

You're very welcome! It's my pleasure, really, I'm having fun making those

[Howard]

Great stuff, Denis
BTW I prefer the vowel table without the final lowpass. In general I think it's best to give the HIve filters something upon which they can work their magic (exception: pure bell and organ tables).

[drzhnn]

BTW I prefer the vowel table without the final lowpass. In general I think it's best to give the HIve filters something upon which they can work their magic (exception: pure bell and organ tables).

Yeah, without the final lowpass the sound is more airy But this is one of those things why I think that uhm scripts should be saved within presets. May be as on option. May be with ability to extract uhm to a separate file later on. There are so many ways you can tweak a single uhm script to get hundreds of useful wavetables... As simple as changing just the Seed value. Saving each iteration of a script to a separate file will create more problems in a long run, and uhm scripts are harder to manage (no dedicated browser, no search, they can't be renamed or moved to a different folder without breaking presets they've been used in - and you never know whether a particular script was ever used or not). Such behavior is not friendly for script creators, preset designers, script enthusiast nor it is for preset users with hoarding issues (and it's probably the majority of them). If user's collection of h2p presets (with embedded uhm's or not) is getting out of hand, at least they can safely dump some of their treasures without fear of breaking anything else. But with separate uhm's... the only safe scenario is the "collect but never delete".

[Ranoka]

My first working iteration of FM vowels script (A, AE, I, U):

I wanted to do something like this but wasn't sure how to approach it. Very nice result!

[drzhnn]

I wanted to do something like this but wasn't sure how to approach it. Very nice result!

Thanks! I just tried a different approach and I like it even better. It's based on noise filtering instead of FM. Only "Ahhh" for now:

Code: Select all

NumFrames = 3
Envelope L0=0 T1=0.5 L1=1 T2=0.5 L2=0

Seed = 8644259122
Wave target=aux1 "lowpass(1-2*rand, 0.2, 0.5)"

Seed = 16512
Wave target=aux1 "bandpass(1-2*rand, 0.5, 0.1)" blend=add

Seed = 779513
Wave target=aux1 "highpass(1-2*rand, 0.6, 0.9)*2" blend=multiply

// A - high notes
Wave start=0 end=0 "lowpass(aux1, 0.22, 0.8)*env(phase)*0.5"

// AA - mid notes
Wave start=1 end=1 "lowpass(aux1^3, 0.3, 0.5)"

// AAA - low notes
Wave start=2 end=2 "lowpass(aux1, 0.35, 0.9)*env(phase)"

Spectrum lowest=0 highest=0 "0"
Normalize base=each

It's easier to iterate. You can change seed values, cutoff and resonance, blend modes, and switch noise layers on and off to get very wide range of sounds. I spread frames across keyboard to have more control over spectrum of low, mid and high notes:

[pdxindy]

BTW I prefer the vowel table without the final lowpass. In general I think it's best to give the HIve filters something upon which they can work their magic (exception: pure bell and organ tables).

Yeah, without the final lowpass the sound is more airy But this is one of those things why I think that uhm scripts should be saved within presets. May be as on option. May be with ability to extract uhm to a separate file later on. There are so many ways you can tweak a single uhm script to get hundreds of useful wavetables... As simple as changing just the Seed value. Saving each iteration of a script to a separate file will create more problems in a long run, and uhm scripts are harder to manage (no dedicated browser, no search, they can't be renamed or moved to a different folder without breaking presets they've been used in - and you never know whether a particular script was ever used or not). Such behavior is not friendly for script creators, preset designers, script enthusiast nor it is for preset users with hoarding issues (and it's probably the majority of them). If user's collection of h2p presets (with embedded uhm's or not) is getting out of hand, at least they can safely dump some of their treasures without fear of breaking anything else. But with separate uhm's... the only safe scenario is the "collect but never delete".

+1

I'll never be able to delete an uhm script cause I'll never remember if there is some preset using it.

[u-u-u]

BTW I prefer the vowel table without the final lowpass. In general I think it's best to give the HIve filters something upon which they can work their magic (exception: pure bell and organ tables).

Yeah, without the final lowpass the sound is more airy But this is one of those things why I think that uhm scripts should be saved within presets. May be as on option. May be with ability to extract uhm to a separate file later on. There are so many ways you can tweak a single uhm script to get hundreds of useful wavetables... As simple as changing just the Seed value. Saving each iteration of a script to a separate file will create more problems in a long run, and uhm scripts are harder to manage (no dedicated browser, no search, they can't be renamed or moved to a different folder without breaking presets they've been used in - and you never know whether a particular script was ever used or not). Such behavior is not friendly for script creators, preset designers, script enthusiast nor it is for preset users with hoarding issues (and it's probably the majority of them). If user's collection of h2p presets (with embedded uhm's or not) is getting out of hand, at least they can safely dump some of their treasures without fear of breaking anything else. But with separate uhm's... the only safe scenario is the "collect but never delete".

Maybe there could be a way if the scripts could offer some variable parameters to the plugin. Those parameters would be visible in the seperate wavetable window and applied before loading the script (so not be modulatable/automatable). This would be an easy way to e.g. alter the seed parameter etc..
And this way you could have a single script for one core concept wavetable generation architecture but with some 'variable constants' (like that term ) in it.
I mean, what I just described would be like a preprocessor (in C) as i understand it correctly.
What do you think?

EDIT: I just call those 'variable constants' '#defines' from now on to elaborate the idea even further: to change one of the #defines of the script you would have to change its value in the wavetable window (maybe as a knob, button or dropdown list) and then click on a 'reload script' button to apply the changed #define value and rerun the (preprocessed) script.

[Touch The Universe]

My first working iteration of FM vowels script (A, AE, I, U):

Code: Select all

NumFrames = 4
Envelope L0=1 T1=1 L1=0

// A
Wave start=0 end=0 "sin(2*pi*phase*5)*env(phase)*2"
Wave start=0 end=0 "sin(2*pi*phase*6 + x)*env(phase)*0.5"
Wave start=0 end=0 "sin(2*pi*phase*4.5 + x)*env(phase)" blend=sub

// AE
Wave start=1 end=1 "sin(2*pi*phase*3.5)*env(phase)*2.5"
Wave start=1 end=1 "sin(2*pi*phase*4 + x)*env(phase)"

// I
Wave start=2 end=2 "sin(2*pi*phase*13)*env(phase)"
Wave start=2 end=2 "sin(2*pi*phase*2 + x*0.8)*env(phase)" 

// U
Wave start=3 end=3 "sin(2*pi*phase*8)*env(phase)"
Wave start=3 end=3 "sin(2*pi*phase*3.5 + x)*env(phase)"
Wave start=3 end=3 "sin(2*pi*phase*1.5 + x)"

Envelope L0=0 T1=0.5 L1=1 T2=0.5 L2=0
Wave "lowpass(main, 0.95*env(phase), 0.1*env(frame))"

Spectrum lowest=0 highest=0 "0"
Normalize base=each

https://soundcloud.com/drzhnn/uhm-wavetable-test-8

This is great! Thnx

[drzhnn]

Maybe there could be a way if the scripts could offer some variable parameters to the plugin.

I really like this idea Probably way beyond the scope of the current update but that would be a great feature indeed. The syntax could be something like this:

Code: Select all

Define target=var1 label="Seed" type=randint min=100 max=1000000

or

Code: Select all

Define target=var2 label="Operator1 Rate" type=array "1, 1.7, 17.2, 5, 4.2"

^ being able to define working ranges would help to avoid errors like dividing by zero etc.

[#rob]

Maybe there could be a way if the scripts could offer some variable parameters to the plugin.

I really like this idea

If I understand the WT system correctly, the code has to be rendered into the actual wavetable before the plugin can use it. Having variable/controllable parameters in the code would mean every parameter change triggers a (-n internal) re-render of the wavetable.
You think your computer could pull this off in realtime?
Maybe in, say, 2053?

[drzhnn]

Maybe there could be a way if the scripts could offer some variable parameters to the plugin.

I really like this idea

If I understand the WT system correctly, the code has to be rendered into the actual wavetable before the plugin can use it. Having variable/controllable parameters in the code would mean every parameter change triggers a (-n internal) re-render of the wavetable.
You think your computer could pull this off in realtime?
Maybe in, say, 2053?

No, not realtime Variables in a script would be like placeholders, and the actual values would be set via knobs in the GUI. The wt would be re-rendered at each change. And those knobs in the GUI won't be automatable.

[EvilDragon]

There goes CPU efficiency of Hive, then. Probably ain't happening

[Urs]

Hehehe, yeah, sorry... I'm happy this is somewhat bug free as of yet. I can't possibly go back to surgery mode anytime soon.

We can discuss additions in the future...