Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TempoSync doesn't unstream onto FX correctly #1401

Closed
baconpaul opened this issue Dec 6, 2019 · 5 comments · Fixed by #1402
Closed

TempoSync doesn't unstream onto FX correctly #1401

baconpaul opened this issue Dec 6, 2019 · 5 comments · Fixed by #1402

Comments

@baconpaul
Copy link
Collaborator

As reported by @d3p4z

Hi,

I've tried Surge today and I've created a patch that uses a delay FX with tempo sync. Every time I reload the patch, tempo sync is disabled and I have to enable it manually. Also happens after loading in my DAW (Reaper) any project with any Surge instance that had tempo sync enabled.

Steps to reproduce the bug:

Add delay FX to any patch (choose any delay preset, seems that all of them use tempo sync)
In the delay FX options, right click the slider labeled as "right" and check that "Temposync" is enabled in the context menu.
Repeat the same for the slider labeled as "left".
Save the patch using the store button.
Reload the patch using the patch browser | Or save/reload the project using the DAW.
"Temposync" is disabled for both left and right channels (and the delay doesn't sound synced anymore)
System where the bug was experienced:
OS: Windows 10 x64
Surge version: 1.6.4.1 (VST x64)
DAW: Reaper 5.984 x64

Feel free to ask me any additional information.
Keep up the good work, It's a great synth with an amazing sound and tons of versatility.

Thank you in advance.

I asked @d3p4z to attach their .fxp to the issue and will also look.

@baconpaul
Copy link
Collaborator Author

OK yeah so I've just confirmed this on my setup also (with the nightly you can see whether a slider is temposynced so this is clear as day). This is a real bug!

Thank you for the excellent report.

@baconpaul
Copy link
Collaborator Author

OK this is also only a feature on FX not on temposync parameters elsewhere. And luckily it is stored in the patch, so the problem is on unstream not stream.

(p3env) paul:~/dev/music/surge$ ./scripts/patch-tool/patch-tool.py ~/Documents/Surge/Paul/TempoSyncStore.fxp  | grep tempo
		<fx1_p0 temposync="1" type="2" value="-1.000000"/>
		<fx1_p1 temposync="1" type="2" value="0.584962"/>
		<a_portamento temposync="1" type="2" value="-3.584962"/>
		<a_lfo0_rate temposync="1" type="2" value="0.000000"/>

restores with only LFO and portamento temposynced not the delay FX.

@d3p4z no need for your fxp file anymore. I have a good replicating case. Thanks!

@baconpaul baconpaul changed the title TempoSync persistence TempoSync doesn't unstream onto FX correctly Dec 6, 2019
@baconpaul
Copy link
Collaborator Author

Oh I've found it. It is a problem only in the delay.

@baconpaul
Copy link
Collaborator Author

a1f187a

I broke it when cleaning up uninitialized memory in April!

baconpaul added a commit to baconpaul/surge that referenced this issue Dec 6, 2019
In commit a1f187a trying to clean up uninitialized memory I left
in a specious override in the Delay only of temposync. That's
been there since April 2019 but meant that Delay temposync didn't
unstream! So remove that, since the temposync is initlaized in
Parameter::assign properly now, and now it unstreams.

Closes surge-synthesizer#1401
baconpaul added a commit that referenced this issue Dec 6, 2019
In commit a1f187a trying to clean up uninitialized memory I left
in a specious override in the Delay only of temposync. That's
been there since April 2019 but meant that Delay temposync didn't
unstream! So remove that, since the temposync is initlaized in
Parameter::assign properly now, and now it unstreams.

Closes #1401
@baconpaul
Copy link
Collaborator Author

FYI this is fixed now but we are having a hard time getting our nightlies out for windows. I'll tag this issue when we get it running again, or if you go to the website and see a nightly on or after dec 6 it should be correct.
Thanks fr the excellent report.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant