ZynAddSubFx filter frequency set to 127

[bratpeki]

I'm tying this PR to the ZynAddSubFX PR #23. These two PRs aim to disable the default lowpass filter applied to Zyn's three synths, as well as keeping the possibility of filter automation without affecting Zyn internally.

There is only one change in this PR specifically, that being that the filter frequency is set to the maximum value of 127, as per Lost Robot's suggestion in the Discord server.

[super-manis]

Would it be, by any chance, nicer to set the default wave to Power instead of Sine as well?

[bratpeki]

I've noticed that the plugin still treats the filter frequency knob as if it were set to 64. Only when the knob is moved does the change happen.

[bratpeki]

Here a link to an MMPZ file proving that this even stays after saving. Will investigate further.

[bratpeki]

I've saved the MMPZ as an MMP and am reading it.

The first XML entry after each <instrument name="zynaddsubfx">, for all three instances of Zyn, reads the following:

freq set to 64:
<zynaddsubfx portamento="0" resbandwidth="64" bandwidth="64" filterfreq="64" modifiedcontrollers="74," filterq="64" rescenterfreq="64" fmgain="127" forwardmidicc="1">

freq set to 127:
<zynaddsubfx portamento="0" resbandwidth="64" bandwidth="64" filterfreq="127" modifiedcontrollers="74," filterq="64" rescenterfreq="64" fmgain="127" forwardmidicc="1">

knob not touched:
<zynaddsubfx portamento="0" resbandwidth="64" bandwidth="64" filterfreq="127" modifiedcontrollers="" filterq="64" rescenterfreq="64" fmgain="127" forwardmidicc="1">

The first two have had their "Filter frequency" knobs moved (indicated by modifiedcontrollers="74,").

[bratpeki]

plugins/ZynAddSubFx/ZynAddSubFx.cpp, line 123:

connect( &m_filterFreqModel, SIGNAL( dataChanged() ), this, SLOT( updateFilterFreq() ), Qt::DirectConnection );

This would explain why a change to the knob pointed to by m_filterFreqModel would result in the update of the filter frequency.

updateFilterFreq() is defined in the same file, on line 418:

GEN_CC_SLOT(updateFilterFreq,C_filtercutoff,m_filterFreqModel);

The GEN_CC_SLOT macro expands to:

void ZynAddSubFxInstrument::updateFilterFreq() {														 
    sendControlChange( C_filtercutoff, m_filterFreqModel.value() );
    m_modifiedControllers[C_filtercutoff] = true;
}

A hacky approach would be to call updateFilterFreq() from the initialization method of the plugin, although it should be possible to find the root cause of the issue and avoid that call.

[bratpeki]

Indeed, in the same file, in ZynAddSubFxInstrument::ZynAddSubFxInstrument, adding updateFilterFreq(); to the end of the method body fixes the issue.

[bratpeki]

Found the root! It's in plugins/ZynAddSubFx/zynaddsubfx/src/Params/Controller.cpp under Controller::defaults() and Controller::resetall(). I'll update my ZynAddSubFx PR accordingly.

[JohannesLorenz]

Didn't you want to upgrade the submodule? You can reference it right now, assuming we will likely do an FF-merge in the zyn repo.

[bratpeki]

Could you point me to some resource regarding that? I'm failing to understand how I could do that, given that the "zynaddsubfx" PR is not merged.

[bratpeki]

After trying, I was unable to update the LMMS zynaddsubfx submodule. Is it possible for someone more experienced to assist me with this?

[Rossmaxx]

IMO, you should wait till the other PR is merge.

[bratpeki]

Likewise, zynaddsubfx first, then update the submodule, then merge this.

[JohannesLorenz]

This should work (if not we can still fix later):

1. Go to the submodule
2. Checkout the version that you want to use (I assume that the submodule has already been pushed)
3. Go back to lmms
4. git add the submodule
5. git commit
6. git push

[bratpeki]

Attempting to use the method you described prompted me with fatal: 'plugins/ZynAddSubFx/zynaddsubfx' already exists in the index.

To elaborate further, checking out was not possible, because my changes to zynaddsubfx weren't yet approved. I tried using git subdmoule add [url to my fork], which gave me the error above. git rm plugins/ZynAddSubFx/zynaddsubfx followed by git submodule add ... also wasn't successful.

I ended up using git submodule set-url plugins/ZynAddSubFx/zynaddsubfx https://github.com/bratpeki/zynaddsubfx. This has updated .gitmodules. Is this what you had in mind? If not, I will make further changes.

My assumption is that, if the zynaddsubfx changes are excepted, then I can update the lmms submodule accordingly. The zynaddsubfx repo is waiting on your approval.

[bratpeki]

My fork of LMMS is now pointing to the master commit of my fork of Zyn!

[JohannesLorenz]

I ended up using git submodule set-url plugins/ZynAddSubFx/zynaddsubfx https://github.com/bratpeki/zynaddsubfx. This has updated .gitmodules. Is this what you had in mind? If not, I will make further changes.

Sorry, I forgot that this requires switching the forks. It is not good to set the URL of the submodule to your fork, because in the end, it should point to ours. I now pushed branch filterfreq to our fork, with the content of your branch. If you manage to link to that from this branch (probably this requires you again to set-url back to our fork), then it should be alright...

[bratpeki]

That should be it! Here's a link to the tree, to make things easier!

[JohannesLorenz]

This PR seems buggy. I do this:

1. Open LMMS
2. Add a Zyn instance to the instruments
3. Open Zyn UI, go to global AD synth, look at Filterfreq

Observations:

1. The knob is not at maximum (as the PR suggests?)
2. The knob does not behave linear, but rather logarithmic (or exponential?)

Can this be confirmed? Or did I do anything wrong? At least, the behavior is correct on branch lv2-ui, which is very close to master.

[bratpeki]

Your statements are correct, the change in the frequency relating to LMMS is only in regard to the FREQ knob in the Zyn LMMS UI (red box in the image at the top). Lost checked that 100 is the best value for the ADDSynth, SUBSynth and PADSynth filter, as it makes sense in the context of automation as well as not making the signal lowpassed, so I set them to 100. The change that should be noticed is that none of the synths are lowpassed, as was the case previously.

The change to ADD-, SUB- and PADSynth is in the zynaddsubfx repo, of course.

[JohannesLorenz]

I don't understand. Can you reproduce my issue? If yes, IMO this should be fixed. I can't imagine that Lost planned that?

[bratpeki]

I'll try to explain.

By default, Zyn's synths are lowpassed, with Add having a filterfreq vaule of 94, IIRC. Understandably, having the signal lowpassed implies that the signal has been edited from the standard sine wave before you did anything. I aimed to correct that. Initially, I set all the filterfreq's to 127, but Lost pointed out that that would not allow for neatly automating the signal, as made evident by these Discord messages:

Lost Robot — 07/13/2024 7:24 PM
Approximately values 80-127 from LMMS's FREQ knob will have no impact by default if ZynAddSubFX's internal knob value is set to 127 by default.

Lost Robot — 07/13/2024 7:27 PM
Yes. I recommend all three of those having a default value of 100 and LMMS's FREQ knob having a default value of 127.

I did as Lost suggested, which is what the two PRs I made are.

Tres made it clear that this is changed in Zyn-Fusion, so this is simply a small patch to make Zyn more user-friendly until it's is updated.

[bratpeki]

This should now really be it! Both here and in the Zyn repo.

[JohannesLorenz]

Testing and Code OK.

While awaiting the latest build, can you please formulate a commit message for squash? Like

one-line description
<empty line>
optional
longer
description

Thanks.

[bratpeki]

Same as in the other repo, I am terribly sorry for misunderstanding your comment.
The commit message is:

Made it so ZynAddSubFx isn't lowpassed by default

In this repo, the only changes made are updating the according submodule
and changing the FREQ knob in ZynAddSubFx's LMMS GUI.

[bratpeki]

After the Zyn PR is merged, the submodule here has to be updated, after which this can be merged as well.

[JohannesLorenz]

OK, please update the submodule reference now.

[JohannesLorenz]

I think that went wrong? I guess it should point to 9499523f70322b6034673566898300e7543fdf3e now, because this is the repo's master?

[bratpeki]

I believe it does, here's the tree of my fork.

[JohannesLorenz]

Now I see it, thanks.