search

surge-synthesizer / surge

Synthesizer plug-in (previously released as Vember Audio Surge)
https://surge-synthesizer.github.io/
GNU General Public License v3.0
3.09k stars 395 forks source link

Lock parameters while changing patches #7380

Open Andreya-Autumn opened 9 months ago

Andreya-Autumn commented 9 months ago

You know how many reverbs have a lock switch on the wet/dry param which prevents it from changing when you page through presets? User nicokaniac on Discord had the idea that it could be fun to have such a switch but that locks tempo-sync engaged on all relevant params, effectively rounding the saved value to a nearby tempo-synced one.

It's an interesting idea. My thinking is for some parameters (EG's, Formula and MSEG Rate, maybe others too) it would be such a toss-up whether the tempo-sync rounding would sound cool or just break the patch completely that those should probably be omitted. But for delay times, sequencer rates, and most LFO rates, it might actually work great.

Andreya-Autumn commented 9 months ago

Further discussion with @mkruselj on Discord:

EvilDragon — Idag 14:03 a generic lock feature could be useful indeed but it can def wreak havoc with contextual parameters (all osc and FX) Andreya — Idag 14:18 Yeah I agree, for most Surge parameters it makes no sense at all that I can see. But the tempo sync idea actually might work. EvilDragon — Idag 14:29 it would make sense to lock whole sections tho Andreya — Idag 14:34 Hmm... which ones? I can't really think of any that aren't very intertwined with everything else. Except maybe FX. EvilDragon — Idag 14:35 say lock an oscillator lock a filter lock an effect or a whole effect chain lock an LFO could be curious accidents obv lock pitch bend range lock AEG to keep the output envelope the same there's fun to be had there Andreya — Idag 14:37 Effects I can kinda see. Oscillators I'm less sure. Like, they can affect each other with FM. And the window between "do nothing fun" and "obnoxiously scream at you" is kinda narrow there. 😅 You could lock the whole oscillator block maybe. EvilDragon — Idag 14:37 TBD but I see it both ways Andreya — Idag 14:38 Pitch Bend range makes total sense though. EvilDragon — Idag 14:38 it won't always produce a usable result just like how randomizer wouldn't either Andreya — Idag 14:38 And AEG too I guess. Yeah I suppose it's the same discussion really - it's hard to gauge how the cost/benefit will play out. EvilDragon — Idag 14:38 yep but it doesn't sound like it would be a super huge thing to implement there basically needs to be a flag in Parameter class that if true doesn't update its value when loading another patch Andreya — Idag 14:39 Sure.

RustoMCSpit commented 4 months ago

this would be very useful for locking surge to audio input mode so latch and audio in

RustoMCSpit commented 4 months ago

Discord discussion

for an audio only use case, it's about experimenting and going through them fast seeing which ones work which dont it's fine if many are broken it doesnt effect anything the only technical limitation is that youll have to tell all the skin designers they need to incorporate a "locked" color does that make sense

it makes sense to categorise what can and cant be used with audio in even if audio in isnt the default oscillator so an audio compatible tag and then people can param lock to audio and latch but obviously param locking can be done with anything and this should be the only "compatible" tag i cant imagine a use case needing another and they should be able to take multiple tags so Bass; Audio Compatible; Grungy but again, audio compatible doesnt mean it's by default having an audio oscillator that would just be the Audio tag https://github.com/surge-synthesizer/surge/issues/2359 so Audio isnt Audio Compatible and vice versa

mkruselj commented 4 months ago

it makes sense to categorise what can and cant be used with audio in

I am not sure this is true. Who's to say what is supposed to work with what, it is up to the user to explore and find out. Experimentation is key to sounding different, rather than being a copycat. Also the suggested wording of such a tag is confusing as well. So, overall I don't think this is a particularly useful idea regarding tagging.

RustoMCSpit commented 4 months ago

it makes sense to categorise what can and cant be used with audio in

I am not sure this is true. Who's to say what is supposed to work with what, it is up to the user to explore and find out. Experimentation is key to sounding different, rather than being a copycat. Also the suggested wording of such a tag is confusing as well. So, overall I don't think this is a particularly useful idea regarding tagging.

some patches literallt do not produxe sound in audio mode