change fanchor to 0

[daslyfe]

• kinda breaking change: will change patterns without the fanchor set using fenv to be a bit brighter
• It's time to make this change, it is a source of confusion when giving workshops why the filter env behaves in a bipolar fashion by default. Imagine strumming an instrument harder, and the harmonics fading faster. Bipolar envelopes can also cause clicks if the cutoff dips too low.

[felixroos]

Agreed that 0 is a better default!
It would be handy to have a quick way to repair old patterns. fanchor isn't even documented, so basically all patterns using a filter envelope will sound different. maybe there could be something like setDefault('fanchor', 0.5) .
In superdough, all default values can then be set like { fanchor = getDefault('fanchor') }

[daslyfe]

Agreed that 0 is a better default! It would be handy to have a quick way to repair old patterns. fanchor isn't even documented, so basically all patterns using a filter envelope will sound different. maybe there could be something like setDefault('fanchor', 0.5) . In superdough, all default values can then be set like { fanchor = getDefault('fanchor') }

Cool sounds good :) I added the setDefault function. Im not sure how to go through the db and modify existing patterns though to add the old default

[felixroos]

looks good, thanks for adding! I think the last thing missing is something like resetDefaults, which is called in resetEditor, so defaults from other patterns won't interfere when switching patterns.
For the database, I can try to cook up an SQL query to add setDefaullt?.('fanchor', 0.5) to any pattern that includes then word lpenv

[daslyfe]

What if we had a version tag at the top of the editor? like // @ver 2.15
That way we could have different defaults for different versions if needed and we would not need to update the DB

[felixroos]

What if we had a version tag at the top of the editor? like // @ver 2.15 That way we could have different defaults for different versions if needed and we would not need to update the DB

and no version tag would mean the old defaults are used? not sure if it's good to make the thing we want to standardize opt-in, rather than opt out.. kind of related: #998 (comment)

[felixroos]

continuing now here, because discord is too ephemeral: yep opt-out would also work with the version tag.. so if no version tag is present, use current defaults. if there is one, then use the defaults for that version.

[felixroos]

maybe like this? we might move this to core later as it could be useful for more general feature flagging

[daslyfe]

yes, this makes sense to me 💯

[felixroos]

fixes #1055

[daslyfe]

I'm guessing that you want to do the DB operation for adding the version tag before committing this?

[felixroos]

I'm guessing that you want to do the DB operation for adding the version tag before committing this?

ok, merging now then quickly running the db update when it's deployed

[felixroos]

db fix is out, i've added // @Version 1.0 to the bottom of each pattern in the db. personal patterns might still be off, so I guess we can mention that in the changelog for 1.1 that you can add the version tag to get the og version