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

Jump to bottom

Replace the linear ADSR with an exponential ADSR #1

Closed
wants to merge 1 commit into from
Closed

Replace the linear ADSR with an exponential ADSR #1

wants to merge 1 commit into from

Conversation

shanipribadi
Copy link

The exponential ADSR is based on a single-pole low pass filter.

Note, this patch changes the sound of every preset because of the difference in ADSR type.
Exponential ADSR change smoothly, especially for the AMP ENV, whereas the linear ADSR causes AMP ENV to change abruptly (notable on presets with short release that are meant for keys; e.g. Pianola from BrianBanks1).
This behaviour is said to be similar to classic analog synths.

Unfortunately since both AMP ENV and FILTER ENV uses the same ADSR class, the FILTER ENV is also changed.
For me personally, exponential ADSR is always preferable for AMP ENV, while for FILTER ENV linear ADSR is different, but not less preferable.

Would it be better to have both? if so then there should be a way of choosing between them.
I could think of two ways of switching,

  • a switch between the old linear or newer exp,
  • or a knob where linear behaviour is simulated with having large overshoot and scaling.

Thoughts?

@shanipribadi
Replace the linear ADSR with an exponential ADSR
a3a3e3b 
The exponential ADSR is based on a single-pole low pass filter.
@nickdowell
Copy link
Member

Hi, thanks for the patch! :-D

My preference would be to have the ADSR type be switchable, so that existing presets will not be affected, but based on what you said make exponential the default for newly created presets.

Would you mind implementing support for this in the ADSR class via a setType(...) or similar method?
I can then take care of hooking that into the UI and preset system (unless you fancy taking that on too!)

P.S. do you think there are there any other ADSR types that it might be interesting to support in the future?

@audetto audetto mentioned this pull request Mar 11, 2018
Closed
@nickdowell nickdowell closed this Jan 9, 2021
@nickdowell nickdowell deleted the branch amsynth:master January 9, 2021 13:55
AnClark added a commit to AnClark/amsynth that referenced this pull request Mar 27, 2022
@AnClark
Future Dev 08: Program: fix redirection when loading preset from host
51aaa93 
Hosts support saving current plugin state as user presets. And some
hosts like REAPER will set program index to 0 when loading them. At this
time, if plugin still load factory program #0, users won't get their own
presets.

One of the best solutions is: reserve factory program #0 as "initial
program". No matter when host or user set to this value, plugin state
will always stays untouched.

Then, correspondingly, move factory programs forward by one item. Always
keep in mind that programs displayed in host's menu is independent, as
it's enumerated by effGetProgramNameIndexed when loading plugin instance.

So, we can just let factory programs display from item amsynth#1, then when user
choose factory programs, reduce choice index by 1 in effSetProgram, and
this is the actual preset index kept by Amsynth preset manager.
AnClark added a commit to AnClark/amsynth that referenced this pull request Mar 27, 2022
@AnClark
Future Dev 08: Program: fix redirection when loading preset from host
25b55fc 
Hosts support saving current plugin state as user presets. And some
hosts like REAPER will set program index to 0 when loading them. At this
time, if plugin still load factory program #0, users won't get their own
presets. Such a "redirection" is unexpected.

One of the best solutions is: reserve factory program #0 as "initial
program". No matter when host or user set to this value, plugin state
will always stays untouched.

Then, correspondingly, move factory programs forward by one item. Always
keep in mind that programs displayed in host's menu is independent, as
it's enumerated by effGetProgramNameIndexed when loading plugin instance.

So, we can just let factory programs display from item amsynth#1, then when user
choose factory programs, reduce choice index by 1 in effSetProgram, and
this is the actual preset index kept by Amsynth preset manager.
AnClark added a commit to AnClark/amsynth that referenced this pull request Mar 27, 2022
@AnClark
Future Dev 08: Program: fix redirection when loading preset from host
4a273b4 
Hosts support saving current plugin state as user presets. And some
hosts like REAPER will set program index to 0 when loading them. At this
time, if plugin still load factory program #0, users won't get their own
presets. Such a "redirection" is unexpected.

One of the best solutions is: reserve factory program #0 as "initial
program". No matter when host or user set to this value, plugin state
will always stays untouched.

Then, correspondingly, move factory programs forward by one item. Always
keep in mind that programs displayed in host's menu is independent, as
it's enumerated by effGetProgramNameIndexed when loading plugin instance.

So, we can just let factory programs display from item \amsynth#1, then when user
choose factory programs, reduce choice index by 1 in effSetProgram, and
this is the actual preset index kept by Amsynth preset manager.
AnClark added a commit to AnClark/amsynth that referenced this pull request Mar 27, 2022
@AnClark
Future Dev 08: Program: fix redirection when loading preset from host
4b724b6 
Hosts support saving current plugin state as user presets. And some
hosts like REAPER will set program index to 0 when loading them. At this
time, if plugin still load factory program #0, users won't get their own
presets. Such a "redirection" is unexpected.

One of the best solutions is: reserve factory program #0 as "initial
program". No matter when host or user set to this value, plugin state
will always stays untouched.

Then, correspondingly, move factory programs forward by one item. Always
keep in mind that programs displayed in host's menu is independent, as
it's enumerated by effGetProgramNameIndexed when loading plugin instance.

So, we can just let factory programs display from item amsynth#1, then when user
choose factory programs, reduce choice index by 1 in effSetProgram, and
this is the actual preset index kept by Amsynth preset manager.
AnClark added a commit to AnClark/amsynth that referenced this pull request Mar 28, 2022
@AnClark
Future Dev 08: Program: fix redirection when loading preset from host
1684f7e 
Hosts support saving current plugin state as user presets. And some
hosts like REAPER will set program index to 0 when loading them. At this
time, if plugin still load factory program #0, users won't get their own
presets. Such a "redirection" is unexpected.

One of the best solutions is: reserve factory program #0 as "initial
program". No matter when host or user set to this value, plugin state
will always stays untouched.

Then, correspondingly, move factory programs forward by one item. Always
keep in mind that programs displayed in host's menu is independent, as
it's enumerated by effGetProgramNameIndexed when loading plugin instance.

So, we can just let factory programs display from item amsynth#1, then when user
choose factory programs, reduce choice index by 1 in effSetProgram, and
this is the actual preset index kept by Amsynth preset manager.
AnClark added a commit to AnClark/amsynth that referenced this pull request Mar 29, 2022
@AnClark
Future Dev 08: Program: fix redirection when loading preset from host
bc09e49 
Hosts support saving current plugin state as user presets. And some
hosts like REAPER will set program index to 0 when loading them. At this
time, if plugin still load factory program #0, users won't get their own
presets. Such a "redirection" is unexpected.

One of the best solutions is: reserve factory program #0 as "initial
program". No matter when host or user set to this value, plugin state
will always stays untouched.

Then, correspondingly, move factory programs forward by one item. Always
keep in mind that programs displayed in host's menu is independent, as
it's enumerated by effGetProgramNameIndexed when loading plugin instance.

So, we can just let factory programs display from item amsynth#1, then when user
choose factory programs, reduce choice index by 1 in effSetProgram, and
this is the actual preset index kept by Amsynth preset manager.
AnClark added a commit to AnClark/amsynth that referenced this pull request Apr 15, 2022
@AnClark
Future Dev 08: Program: fix redirection when loading preset from host
944dda9 
Hosts support saving current plugin state as user presets. And some
hosts like REAPER will set program index to 0 when loading them. At this
time, if plugin still load factory program #0, users won't get their own
presets. Such a "redirection" is unexpected.

One of the best solutions is: reserve factory program #0 as "initial
program". No matter when host or user set to this value, plugin state
will always stays untouched.

Then, correspondingly, move factory programs forward by one item. Always
keep in mind that programs displayed in host's menu is independent, as
it's enumerated by effGetProgramNameIndexed when loading plugin instance.

So, we can just let factory programs display from item amsynth#1, then when user
choose factory programs, reduce choice index by 1 in effSetProgram, and
this is the actual preset index kept by Amsynth preset manager.
@ondinegreen ondinegreen mentioned this pull request Jan 14, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@shanipribadi @nickdowell