F'em

[Muziksculp]

F'em is $179. , no Intro discount pricing ?

[Greenstorm33]

There was intro pricing but it lasted all of about ten seconds.
Edit: or maybe the discounted price was just part of the sale. Either way, odd not to give a longer chance to get it discounted.

[McLilith]

The intro pricing is already over!?

Looks like I won't be getting it till a Black Friday sale, at the earliest.

In the meantime, I'm going to suck the demo version dry, and party like it's 1999!

[Synthient Sound]

Just found out about F'em...but the launch price was only a few days?

[bhinton]

Sustain cutoff problem seems to be fixed in 1.0.4. yay!
This is really the virtual FM synth that I thought we'd have had from someone many years ago, finally realized and with so much detail made possible! Still, it's missing a few key things that make it difficult to use:

S0... three feature requests and a not-exactly-bug but an issue:
1. This is a big omission - limited external modulation sources. No expression pedal source options, no way to assign CCs and use something like a Touche or a sensel thunder in addition to the sustain/breath control - this synth cries out for real time expression via pedals and controllers that can be easily assigned per patch and configured in the same way as the other mod sources (including the ability to use them in modifiers) - as it is now we are limited to doing this via automation in a host, which is not at all the same as external(physical)>internal modulation routing per patch. Please at least at Expression, Volume, and a couple of CC pedal sources to the modulation sources. I'm sitting here playing it through an RD2000 and a Hydrasynth (as controllers) with their pedal inputs, multiple wheels, etc and no way to use them on a VST that seems otherwise built for them. (but thanks for at least including breath control and especially sostenuto, which so many leave out).
2. Maybe this exists and I've missed it? A button to turn off all "assign" buttons. Once you get into patching controls between operators and such, it's easy to get stuck in assign mode and lose track of where you need to turn it off.
3. Ability to type values into controls. It's painful to get exact values entered into parameters like frequency offset, especially if the values are close to control's default.

Which brings me to the issue:
When operators are in "free" mode they, as expected, begin to click when a key is played in polyphonic mode, getting worse as the number of simultaneous voices play, and even with declicked (or more) EG attacks. This is normal, but since the default is "free", it means resetting every single operator to 0 phase start... which is a gigantic pain (particularly given the need for request #3, above).

An additional issue which doesn't impact me personally since I use bidule and realearn in Reaper which bypasses the need but which I think will be a big problem for others: no midi learn or even midi assignment protocol. I get that there are way too many parameters to include anything but a subset, but at least operator levels, layer mixing, things like that really need to be controllable through midi CCs for many people.

[gentleclockdivider]

Haven't updated to 1.04 , but in the previous version , sample 2 osc ccouldn't be phase modulated ( no difference whatsoever >
Also ,is the envelope bug fixed ( attack portion gets ignored ) ?

[mikoatkvr]

3. Ability to type values into controls. It's painful to get exact values entered into parameters like frequency offset, especially if the values are close to control's default.

This is possible by using ALT-Left_Click.

[bhinton]

This is possible by using ALT-Left_Click.

Excellent! Thanks.
This revealed a new bug though: Typing 0.0 for operator phase just resets it to "free". You can get 0.0 by dragging the rotary (eventually) but the lowest value it will accept typing directly is 0.1

[LismoreMusic]

The CPU overhead is insane. I can’t even run some presets on my new Ryzen 9 system! I don’t know if it’s particular to my system, a bug in the software, or if this synth is designed for threadrippers or something!

All I know is that until now this CPU hasn’t had to work harder than about 20%. With f.’em though, it spikes sharply to 100% and grinds my system to a halt until I force quit f’em (in Waveform 11).

This synth seems slightly more stable in Bitwig, which is odd. You’d expect it to work best in Tracktion’s own DAW.

I’d been looking forward to making a video about this synth. It has so much potential, but if it’s this hard on the CPU for everyone then my first-look video may end up more negative than I’d like. Does it run better in Windows?

[Kott]

With opened synth windows? Try to toggle of OpenGL in F'em settings.

[bhinton]

Where should we be reporting bugs? There are still some fatal ones as of 1.0.4, at least on Mac. Really anxious for this amazingly designed synth to get to the point where it is worth the time to start designing and performing with it - I hope Tracktion is supporting this release to the level it deserves so these can be ironed out.

[Jimothy]

Brilliant synth. I'm currently on a 90 day trial but believe this would be a worthy purchase.

However first thing I've noticed is sine wave artifacts which have an audible effect when modulating 8 by 7 using sines. Very dirty compared to other FM synths. Can be seen in your EQ spectrum analyser.

[bhinton]

Well I'll post one here because it's been driving me batty for the last several hours: after playing fast passages for an extended time, especially if those passages tend to reach polyphony limits for the patch, the filter cutoff EG begins triggering at sustain instead of attack on random notes - regardless of how many voices are being played - until eventually it happens on every key press. You can even get this behavior on the default factory patch (Sweep Synth) after playing using the pedal for a while (not just holding the pedal down, I mean normal syncopated pedaling).
And weirdly, on the CISA factory preset, which has no filter engaged but has pitch eg depth for each operator set at -100, the pitch EG doesn't engage at all until that same point where the filter cutoff EG would stop working in other patches. I've looked and looked and don't see any modulation path that sets a delay for the pitch EG start in this patch.

What's even stranger about this is that if a patch starts exhibiting these behaviors as you play, neither stopping and letting playing voice count go back to 0 nor changing patches and than going back to the patch fixes it. The only option for restoring normal behavior is to reload the entire VST.

These aren't normal voice stealing artifacts - it's not existing voices cutting off, it's envelope weirdness on new voices, and it continues until reloading the VST, even if the count of the number of voices played sinks to 0.

[Wolfram Franke]

The CPU overhead is insane. I can’t even run some presets on my new Ryzen 9 system! I don’t know if it’s particular to my system, a bug in the software, or if this synth is designed for threadrippers or something!

All I know is that until now this CPU hasn’t had to work harder than about 20%. With f.’em though, it spikes sharply to 100% and grinds my system to a halt until I force quit f’em (in Waveform 11).

This synth seems slightly more stable in Bitwig, which is odd. You’d expect it to work best in Tracktion’s own DAW.

I’d been looking forward to making a video about this synth. It has so much potential, but if it’s this hard on the CPU for everyone then my first-look video may end up more negative than I’d like. Does it run better in Windows?

Hi everyone,

sorry but I only just now became aware of this thread. I am not really monitoring KVR since I am busy coding most of the time, so please excuse my huge latency . Or better: if you find a bug or have a question, report it on tracktion.zendesk.com.

Anyway, if F.'em uses too much CPU power in Waveform 11, you might try to switch off Plugin Sandboxing, which you can deactivate in the bottom right corner of Settings > Plugins.

Also, make sure that F.'em has Multi Core enabled in its global settings.

Let me know if any of that was set differently and if changing it helped with the performance.

Best wishes,

Wolfram

[Wolfram Franke]

Well I'll post one here because it's been driving me batty for the last several hours: after playing fast passages for an extended time, especially if those passages tend to reach polyphony limits for the patch, the filter cutoff EG begins triggering at sustain instead of attack on random notes - regardless of how many voices are being played - until eventually it happens on every key press. You can even get this behavior on the default factory patch (Sweep Synth) after playing using the pedal for a while (not just holding the pedal down, I mean normal syncopated pedaling).
And weirdly, on the CISA factory preset, which has no filter engaged but has pitch eg depth for each operator set at -100, the pitch EG doesn't engage at all until that same point where the filter cutoff EG would stop working in other patches. I've looked and looked and don't see any modulation path that sets a delay for the pitch EG start in this patch.

What's even stranger about this is that if a patch starts exhibiting these behaviors as you play, neither stopping and letting playing voice count go back to 0 nor changing patches and than going back to the patch fixes it. The only option for restoring normal behavior is to reload the entire VST.

These aren't normal voice stealing artifacts - it's not existing voices cutting off, it's envelope weirdness on new voices, and it continues until reloading the VST, even if the count of the number of voices played sinks to 0.

Hi,

yes, that's a known bug that I have fixed in V1.0.5. You can find the latest public beta of F.'em here:

https://marketplace.tracktion.com/downl ... hive?v=fem

Note that there will be V1.0.7 quite soon, I just fixed a couple of bugs and made small improvements to envelope stage insertion/removal etc.

Best wishes,

Wolfram