Skip to content

feat: Improve gain curve #1318

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

daslyfe
Copy link
Collaborator

@daslyfe daslyfe commented Mar 31, 2025

changed the default gain curve to x ^ 2, and added a setter function that gain be used example: setGainCurve((x) => Math.pow(x, 2))

@daslyfe daslyfe requested review from yaxu and felixroos March 31, 2025 04:20
@felixroos
Copy link
Collaborator

i see why some people would prefer another curve, but thats seems like a huge breaking change.. i'd prefer to rather add alternative methods like gainx or gain2. the current gain curve is engraved in many peoples minds at this point, so it seems a bit rude to change it

@yaxu
Copy link
Member

yaxu commented Mar 31, 2025

I'm open to breaking changes are good when they're improvements, and I do agree this would be a better default. I don't tend to make 'tracks' though so am biased...

Versioning would be the ideal world but could be a lot of work to get right. For now a short command to get older default behaviour might help - compat('1.1.0'), or maybe a metadata comment // @version 1.0.0 could be added to old patterns in the db?

@daslyfe
Copy link
Collaborator Author

daslyfe commented Mar 31, 2025

True that existing patterns would be affected, but I think this change is an important one. Having a gain curve that is more reflective of how human hearing perceives volume will make strudel much easier to work with for mixing, and I think everyone who makes music with strudel will benefit from improved mixes from better gain parameters. for getting the old behavior back, you can run setGainCurve(x => x) which can also be added to the top of the patterns in the DB if we want to do that.

@yaxu
Copy link
Member

yaxu commented Apr 4, 2025

I wonder about adding a function like this:

function compat(ver) {
  switch(ver) {
    case 'v1.1.0':
    case '1.1.0':
     setGainCurve(x => x);
  }
}

Then just compat('v1.1.0') could be added to the old patterns.. Possibly via a metadata comment // @compat "v1.1.0"

@felixroos
Copy link
Collaborator

I wonder about adding a function like this:

function compat(ver) {
  switch(ver) {
    case 'v1.1.0':
    case '1.1.0':
     setGainCurve(x => x);
  }
}

Then just compat('v1.1.0') could be added to the old patterns.. Possibly via a metadata comment // @compat "v1.1.0"

that already exists, see setVersionDefaults

@yaxu
Copy link
Member

yaxu commented Apr 4, 2025

@felixroos ah great! So can add version to all previous patterns that don't have one? I guess would need to do some version arithmetic to apply it to versions < 1.2 . Would you be happy with the default curve change then?

@felixroos
Copy link
Collaborator

@felixroos ah great! So can add version to all previous patterns that don't have one? I guess would need to do some version arithmetic to apply it to versions < 1.2 . Would you be happy with the default curve change then?

yes, we'd need some sql wizardry to do that in the db.. or export all and do it with a script, then import into a new table. when we add a new v1.1. url then the shared patterns would be frozen in time, which might be desirable
i'm a bit fearful when it comes to this breaking change but maybe we have to do it

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 this pull request may close these issues.

3 participants