Synchro, a simple phase modulation synth

[rubiefawn]

2-oscillator PM synth for creating nasty sounds.

⚠️ Todo

• Add non-automatable UI controls to change oversampling rate
• Use the HIIR library for proper bandlimiting
• Proper monophonic behavior. See Monophonic mode on instrument plugins; portamento #6516
  • Amplitude envelopes
  • Glide/portamento
• Style knobs properly

❓ Optional

• Improve performance. Possible pain points:
  • Heavy use of exp() and pow() during waveform generation
  • The halves of the oversampling double buffer are not guaranteed to be contiguously allocated, which might cause cache issues.
• Use source .svg for background instead of .png, whenever that becomes possible
• Pitch envelopes
• Modulation envelope

❌ Issues

• Line width for waveform preview is too thin. Ideally it would be 2px wide, but gui::Graph doesn't have any logic for line width
• There's currently a bug where the modulator will reset its own phase every time the carrier completes a cycle, although the shape of the modulator in each of those windows is correct. For example, if the modulator is 1 octave below the carrier, it should complete a cycle once per every two carrier cycles, but instead it just plays the first half of its cycle twice.

[BaraMGB]

At first glance you could add an argument in the constructor of the Graph class:
Graph::Graph( QWidget * _parent, graphStyle _style, int _width, int _height, bool readOnly=false )

In the mousePressEvent() you could have an if-statement and test this readOnly-bool.

[BaraMGB]

I love it! It's so simple but you can make very heavy neuro basses with it!

[DomClark]

Graph is a subclass of QWidget, so you can use QWidget's enabled property. Access it with isEnabled() and set it with setEnabled(bool).

[DomClark]

Since you're no longer modifying the graph code, could you revert the formatting changes there?

[DomClark]

I've done a review of the code. I've also got a couple of questions about the synth, but they might just be my unfamiliarity with these sorts of things:

• I'm not quite sure of the advantage of having both "mod" and "mod max" controls. They're functionally identical, their values just being multiplied together. Is this a common thing to have? Can't you get the same result just by not turning "mod" up as high?
• The "sync" control just seems to be a frequency multiplier. From what I've seen, sync usually means one oscillator resets another oscillator every cycle. Is the current behaviour and wording what is intended?

[DomClark]

This can support sample-accurate automation if you get the model's value from its valueBuffer() when it exists. See the amplifier code for an example.

[rubiefawn]

I'm not quite sure of the advantage of having both "mod" and "mod max" controls. They're functionally identical, their values just being multiplied together. Is this a common thing to have? Can't you get the same result just by not turning "mod" up as high?

Yes, but it's harder. Compare it to pitch bend vs pitch bend range. It is slightly redundant, but it increases ease of use, especially in automation.

The "sync" control just seems to be a frequency multiplier. From what I've seen, sync usually means one oscillator resets another oscillator every cycle. Is the current behaviour and wording what is intended?

The current behavior is exactly as intended, but you're right; the wording is a bit off. I'm not sure what to call it exactly, but "sync" seemed closest to the functionality. I am open to suggestions here.

For clarification, the intended functionality is a frequency multiplier, but similar to sync, the phase is still reset every cycle of the base frequency. In addition, the amplitude decreases over time in agreement with the base frequency if the "chop" control is >0, regardless of this multiplier.

[LostRobotMusic]

About sync, I have seen things labeled as "sync" work this way (e.g. Serum). You can think of it as the waveform being "synced" with a waveform with a frequency determined by the Sync knob. In other words, the Sync knob multiplies the frequency of a fake waveform which is causing the real waveform to reset.
(EDIT: This is inaccurate, see my next post below...)

[DomClark]

Yes, but it's harder. Compare it to pitch bend vs pitch bend range. It is slightly redundant, but it increases ease of use, especially in automation.

👍

The current behavior is exactly as intended, but you're right; the wording is a bit off. I'm not sure what to call it exactly, but "sync" seemed closest to the functionality. I am open to suggestions here.

OpulenZ and Watsyn call it "mul", with the tooltip "frequency multiplier". (At least I think those knobs are equivalent to this one, correct me if I'm wrong.)

About sync, I have seen things labeled as "sync" work this way (e.g. Serum). You can think of it as the waveform being "synced" with a waveform with a frequency determined by the Sync knob. In other words, the Sync knob multiplies the frequency of a fake waveform which is causing the real waveform to reset.

But it's not playing part of the waveform at normal speed then resetting it, it's playing the whole thing but faster. Plus, I recall you mentioning that some of the other labels on Serum are less than accurate. 😉

[LostRobotMusic]

Sorry for all the messups in the previous posts, I'm super scatterbrained right now. I deleted some posts, now I will speak as if I actually have a brain. =)

The Sync knob is a frequency multiplier, but that waveform is being synced with a hypothetical waveform of the original frequency. So if you're playing a note at 440 Hz with a Sync value of 1.5, then the result is the waveform at 660 Hz being synced at 440 Hz. With integer Sync values, this is identical to pure frequency multiplication, but with non-integer values, it creates a drastically different sound.

I've seen this feature in multiple synthesizers, Serum's just the only one that came to mind. I think I recall some synthesizers from FL Studio also having that feature.

If you use a Sync value of 1.5 (or any other non-integer value), you should hear a drastically different timbre rather than just a frequency multiplication. Note that the copy of Synchro I have is from before this PR was made, let me know if this is no longer true...

[DomClark]

It doesn't look to me like the modulator gets synced back to the original frequency any more. Here's the only place where the modulator's phase is modified, and it's just moved forward by the adjusted frequency (mod 2pi), without being reset:

lmms/plugins/Synchro/SynchroSynth.cpp

Lines 86 to 89 in f8dfb32

	//Find position in modulator waveform
	sample_index[1] += sampleRatePi * DetuneOctaves(nph->frequency(),
	modulator.Detune);
	while (sample_index[1] >= F_2PI) { sample_index[1] -= F_2PI; } //Make sure phase is always between 0 and 2PI

(I may well be wrong - I'm only getting this from the code. My last build of this PR is from before fractional sync was supported, so I can't test it right now.)

[LostRobotMusic]

I think the while (sample_index[1] >= F_2PI) { sample_index[1] -= F_2PI; } part would cause the phase reset. It sets the phase to 0 (ish) whenever the original waveform (ignoring sync) reaches its end, which would interrupt the synced waveform when using fractional frequency multiplications.

[rubiefawn]

The frequency multiplication happens in the waveform generation function, so the phase is automatically reset as part of that.

[DomClark]

Ah yes, I see. I thought sample_index[1] was the phase after sync had been applied, but it's the phase before. Thanks for clearing that up.

[PhysSong]

@iansannar I fixed the merge conflict for you. Please pull it before you go further.

[LmmsBot]

🤖 Hey, I'm @LmmsBot from github.com/lmms/bot and I made downloads for this pull request, click me to make them magically appear! 🎩

Linux

• Linux (AppImage): lmms-1.2.0.717-linux-x86_64.AppImage (build link)

Windows

• Windows 64-bit: lmms-1.2.0.717-mingw-win64.exe (build link)
• Windows 32-bit: lmms-1.2.0.717-mingw-win32.exe (build link)

🤖

{"platform_name_to_artifacts": {"Linux": [{"artifact": {"title": {"title": "(AppImage)", "platform_name": "Linux"}, "link": {"link": "https://302-204106384-gh.circle-artifacts.com/0/lmms-1.2.0.717-linux-x86_64.AppImage"}}, "build_link": "https://circleci.com/gh/iansannar/lmms/302?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}], "Windows": [{"artifact": {"title": {"title": "64-bit", "platform_name": "Windows"}, "link": {"link": "https://303-204106384-gh.circle-artifacts.com/0/lmms-1.2.0.717-mingw-win64.exe"}}, "build_link": "https://circleci.com/gh/iansannar/lmms/303?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}, {"artifact": {"title": {"title": "32-bit", "platform_name": "Windows"}, "link": {"link": "https://299-204106384-gh.circle-artifacts.com/0/lmms-1.2.0.717-mingw-win32.exe"}}, "build_link": "https://circleci.com/gh/iansannar/lmms/299?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}]}, "commit_sha": "915c3a535cb69b58b34808c19e45f38592b50939"}

[PhysSong]

It seems like you removed the SynchroNote destructor accidentally. You should either restore it on the source file or add = default in the header file to fix the undefined reference error.

[PhysSong]

To prevent compiler warnings, you should make the order of declaration and initialization consistent.

[PhysSong]

@iansannar Do you want to add something more here? Or, can I start review?

[rubiefawn]

Ah. I have no idea how I did that, but clearly I didn't rebase properly and now the commit history is duplicated 😓

Anyways, after re-examining this, it's clear that it's not even close to finished. I've updated the todo comment at the top.

[michaelgregorius]

I have resolved the merge conflicts by merging master and have fixed all compilation problems that have amassed over time with commit d67a3ed.

Hope this might revive development. The synth still works. 🙂