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

create macro params for oscillators #1181

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

Conversation

daslyfe
Copy link
Collaborator

@daslyfe daslyfe commented Sep 6, 2024

The intention is to make generic macro params z1-z4 for synth sounds. this concept has been used very successfully in mutable instruments modules as well as electron boxes.

@daslyfe daslyfe requested review from yaxu and felixroos September 6, 2024 04:19
@felixroos
Copy link
Collaborator

felixroos commented Sep 6, 2024

do i understand it correctly, that each z param has a named counterpart, and it is mostly a shortcut + a way to see surprise yourself? I generally like the idea, but I wonder how this should be documented best, especially if some sounds have it and some don't

@felixroos
Copy link
Collaborator

also, i think we need to be careful that the range doesn't differ much between z controls, too prevent something like

  1. you start with sound A and z1(400)
  2. you switch to sound B, your ears will fall off because z1 400 for that sound is massively out of the pleasant range

not sure how to do this, maybe let 0-1 be the safe range? would that mean we have to rescale z params to their named counterpart? just some thought

@daslyfe
Copy link
Collaborator Author

daslyfe commented Sep 7, 2024

also, i think we need to be careful that the range doesn't differ much between z controls, too prevent something like

1. you start with sound A and z1(400)

2. you switch to sound B, your ears will fall off because z1 400 for that sound is massively out of the pleasant range

not sure how to do this, maybe let 0-1 be the safe range? would that mean we have to rescale z params to their named counterpart? just some thought

I think normalizing the z parameters between 0 and 1 is a great idea. I updated the pr. Also, I think sometimes they will refer to existing params where it makes sense (like with supersaw). However, there might be times when having a specific control for an oscillator might not make sense in which case you would only use z to control it.

@Bubobubobubobubo
Copy link
Contributor

Bubobubobubobubo commented Sep 14, 2024

you switch to sound B, your ears will fall off because z1 400 for that sound is massively out of the pleasant range

The beauty of Elektron boxes or Mutable is that this never happens. Whatever mode you switch into, the same set of parameters will still produce something that you can work with, albeit different. Of course, the difference can be drastic if you jump from a tonal VS atonal sound source, but given that you are using an envelope and filter, it will still be usable.

I wonder how this should be documented best

Some of the models used in macro-oscillators are kind of "self-documented". You can imagine having a model called "3osc" whose macros will help you jump between different frequency tunings around a central frequency (z1), handle the oscillator detune (z2), interpolate between waveforms (z3) and whatever (z4). It will still be 3-oscillator voice nonetheless.

The downside of this approach is that you need a lot of carefully written and optimized DSP to generate a pleasant collection. In this regard, the Mutable code itself could help.

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