Morphex - A Spectral Morphing Synthesizer [open-source plugin]

Morphex - A Spectral Morphing Synthesizer

Hello dear JUCE mates,

I’ll get to the point, I’ve created a plugin as part of my master thesis project. The plugin is called Morphex - A Spectral Morphing Synthesizer, and it morphs two sounds. Right now I am on the final phase, user testing and I was wondering if any of you would be so kind to download the plugin, testing it and fill a very short form:

In September, once I deliver the thesis, I will upload the two repositories of this project (research in python and development in JUCE/C++) to GitHub and made them open-source, so all of you will be able to download the software, criticize it and maybe contribute to fix it. I hope this plugin may help those who are starting with JUCE and want to make a synthesizer.

This is what has been done so far:

  • Morphing the harmonics of two sounds (frequencies + magnitudes).
  • Methods of harmonic transposition to be able to play the instrument (“Real Fundamental Tracking” and “Predominant Fundamental Normalization”).
  • Feature extraction of the sounds (by now, only the predominant fundamental).
  • Magnitudes normalization (pre-synthesis).
  • Design and implementation of the graphical interface.
  • XY pad component to explore and control the matrix interpolation.
  • MIDI control over the synthesis engine of the plugin.
  • Automations of the parameters of the plugin from a DAW.
  • Be able to load sounds “on the fly” with the sound browser using the left and right arrow keys of the keyboard.
  • Polyphony up to 5 simultaneous voices.
  • Preset management system (new, load and save).

I am aware of the following bugs:

  • ADSR parameters do not work well (ADSR it’s not fully implemented on the code).
  • The synthesis of the stochastic component does not work correctly, everything is implemented but it does not work as expected, so this feature needs a bit more effort to make it work.
  • Pitch bend has stopped working when adding the 5 voices.
  • When multi instantiating the plugin in a DAW, only one instance work at a time.

The plugin and everything you need to know is inside this “”.

Download Link

Thank you all and hope to see you soon! :smile:


The plugin’s repository is now publicly available here:

You can also take a look at the research repository if you are interested:

Thank you all for your interest and feedback :slight_smile:

1 Like

Question on this style:

    mAttachment =
    new AudioProcessorValueTreeState::
    SliderAttachment(stateToControl, parameterID, *this);


class SMTParameterSlider
    public Slider

Were you required to follow a specific style guide by your advisors or something?

It was really up to me, I left this code there for future updates.

Ok. If you’re going to be using this repository after graduation as a “here’s what my code looks like” for any prospective employers, you might spend a few hours and make it conform to this:

You’d be surprised how much this matters in the eyes of people who might hire you! I sure was…

Thank you for showing me this page and for your advice. I try to follow the guidelines as much as I can. I was using a custom slider class since the beginning, so to remove it was not worth the time because the styling is likely to be changed in the near future.

I will read the whole story and see how I can improve the code.

Thank you again and nice to meet you :slight_smile:

Specifically JUCE coding standards, or just a consistency throughout the code base?

I can see the value of the latter (and with automatic code formatting, it’s not even something you have to think about), but is the former really a thing? Personally I find JUCE standard ugly and annoying, in my work (on a JUCE project) we agreed on a very slightly modified Mozilla standard, and every other job I worked at (different languages) always chose some existing standard for which there were auto-formatting tools available.

afaict the JUCE standard is a standard only for JUCE, additionally the clang-format fork that exists doesn’t quite cover all the rules, so you have to waste effort adhering manually.

Sounds great! It’s basically the same concept of a product I released years ago for NI Reaktor:

1 Like

Hello @zioaxiom, awesome plugin I didn’t know it! Nice atmospheric demo :smile:

1 Like

Demo Video

If you want to see the plugin live you can take a look at this video:

In the video you can hear some presets of the plugin. External plugin effects such as distortion and reverb are used at the end of the video to see what kind of sounds can we get when using the plugin within a DAW in a music production use case.

A consistency in coding style. I personally hate foo (arg1, arg2); and much prefer foo( arg1, arg2 ); So i don’t even stick to the JUCE coding standard, but there are parts of it that I follow.

@reuk comments? you’re a clang-format wizard and know if this is true or not.

1 Like

That’s probably my fork, and it’s definitely doesn’t produce 100% JCS-compliant formatting.

I’m a great believer in clang-format, but I’m discovering that it only really works if everyone on the team is on-board (or the style guidelines are sufficiently normal/vague that clang-format’s output consistently complies with them). Unfortunately, I think that my clang-format fork reached a point where fixing the remaining issues would cause me more pain than just fixing my spacing manually, which is why I haven’t been maintaining the fork. In fact, I stopped using clang-format at work because the frequency of ‘mistakes’ that it made was similar to that of my muscle-memory anyway.

If I had free reign to pick my own coding standard, then I’d definitely be using clang-format to enforce style rules, and I’d recommend that others do too, on code that they oversee. But I don’t think clang-format is a good choice for projects that already have complex formatting rules.