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

Automatic FX-mixer strip management #1215

Open
unfa opened this issue Oct 15, 2014 · 6 comments
Open

Automatic FX-mixer strip management #1215

unfa opened this issue Oct 15, 2014 · 6 comments

Comments

@unfa
Copy link
Contributor

unfa commented Oct 15, 2014

The problem
Right now, to use the FX-mixer the user has to manually add, assign and rename strips, before he can use the mixer. I've got used to do this, and I use minimal instrument names ("K" for "Kick" etc.) to cut down the time I spend just getting the mixer up and running. I think many operations can be automated and the user could just use the mixer creatively, not wasting time on setting it up every time from scratch.

The solution
The idea is to create, assign and rename one FX-mixer channel for every instrument the user adds. Since we have two instrument spaces (B+B and Song) I advise to make it first B+B instruments, then the Song instruments. Possibly we could use the colors to indicate the type of mixers strips (see #1214).

All strips should have an "automatic" flag (a boolean property). None of the automatic functions below should work if the strip has the "automatic" flag FALSE (manually created or modified strips should be kept intact).

  1. When the user adds an instrument, create an FX-mixer strip and connect it with the created instrument; set the "auto" flag TRUE.
    If the instrument is added into B+B editor, scan the mixer to find the first Song instrument strip, and insert the new strip before it (shift all other strips). If the instrument is added into Song editor, add it at the end of the mixer.
  2. When the user renames an instrument, rename the FX-mixer channel that it's connected to;
  3. When the user moves an instrument, move the FX-mixer channel accordingly so the orders match in Sequencers and Mixer;
  4. If the user deletes an instrument, delete the corresponding channel strip.
  5. If the user creates or modifies (rename, move) a mixer strip, set the "automatic" flag to FALSE; Muting, moving the fader, modifying strips sends, and modifying the effects stack should not remove the "automatic" flag.
  6. Let the user right click on a strip and set/unset the "automatic" flag so he can manually re-enable auto or disable it if he wants.
  7. Let the user disable/enable this system in the options immediately (no restart required) possibly with a on/off button in the FX-mixer window.
  8. If the system is enabled while the session is not empty, flag all channels as "manual" and only manage channels for new instruments.
  9. Mark the automatically created and managed channels visually in the FX-mixer window, so the user knows what is what.
@tresf
Copy link
Member

tresf commented Oct 15, 2014

#48 #921

@diizy
Copy link
Contributor

diizy commented Oct 15, 2014

On 10/15/2014 06:17 PM, unfa wrote:

The problem
Right now, to use the FX-mixer the user has to manually add, assign
and rename strips, before he can use the mixer. I've got used to do
this, and I use minimal instrument names ("K" for "Kick" etc.) to cut
down the time I spend just getting the mixer up and running. I think
many operations can be automated and the user could just use the mixer
creatively, not wasting time on setting it up every time from scratch.

The solution
The idea is to create, assign and rename one FX-mixer channel for
every instrument the user adds. Since we have two instrument spaces
(B+B and Song) I advise to make it first B+B instruments, then the
Song instruments. Possibly we could use the colors to indicate the
type of mixers strips (see #1214
#1214).

Sounds good, now all we need is more developers.

@Sti2nd
Copy link
Contributor

Sti2nd commented Oct 16, 2014

Another solution we all should make more use of: Save templates. It is the perfect way for exactly YOU, and me

@unfa
Copy link
Contributor Author

unfa commented Oct 19, 2014

I'm trying to put together a LMMS hackaton. My talk showing LMMS in action
gott people excited, Maybe I could earn us some new devs. I just should know
LMMS' code a bit ;)
15-10-2014 20:27, "Vesa V" notifications@github.com napisał(a):

On 10/15/2014 06:17 PM, unfa wrote:

The problem
Right now, to use the FX-mixer the user has to manually add, assign
and rename strips, before he can use the mixer. I've got used to do
this, and I use minimal instrument names ("K" for "Kick" etc.) to cut
down the time I spend just getting the mixer up and running. I think
many operations can be automated and the user could just use the mixer
creatively, not wasting time on setting it up every time from scratch.

The solution
The idea is to create, assign and rename one FX-mixer channel for
every instrument the user adds. Since we have two instrument spaces
(B+B and Song) I advise to make it first B+B instruments, then the
Song instruments. Possibly we could use the colors to indicate the
type of mixers strips (see #1214
#1214).

Sounds good, now all we need is more developers.


Reply to this email directly or view it on GitHub
#1215 (comment).

@tresf
Copy link
Member

tresf commented Jan 30, 2015

@unfa can we close this out in lieu of #1572 which offers "Assign to new FX channel" option?

@badosu
Copy link
Contributor

badosu commented Jan 30, 2015

@tresf I don't guess so, @unfa's request is an umbrella that encompasses many issues related to the workflow related to mixer management.

@Umcaruje Umcaruje added the ux label Jul 2, 2015
@husamalhomsi husamalhomsi removed the ux label Jul 31, 2019
spechtstatt added a commit to spechtstatt/lmms that referenced this issue May 15, 2022
a first draft of an automatic mixer strip management - works so far, but
the sorting is not implemented yet.
spechtstatt added a commit to spechtstatt/lmms that referenced this issue May 20, 2022
rebasing/resolved conflicts
spechtstatt added a commit to spechtstatt/lmms that referenced this issue May 24, 2022
spechtstatt added a commit to spechtstatt/lmms that referenced this issue May 24, 2022
spechtstatt added a commit to spechtstatt/lmms that referenced this issue May 24, 2022
spechtstatt added a commit to spechtstatt/lmms that referenced this issue May 24, 2022
spechtstatt added a commit to spechtstatt/lmms that referenced this issue Jun 23, 2022
rebasing/resolved conflicts
spechtstatt added a commit to spechtstatt/lmms that referenced this issue Jun 23, 2022
spechtstatt added a commit to spechtstatt/lmms that referenced this issue Jun 23, 2022
spechtstatt added a commit to spechtstatt/lmms that referenced this issue Jun 23, 2022
spechtstatt added a commit to spechtstatt/lmms that referenced this issue Jun 23, 2022
spechtstatt added a commit to spechtstatt/lmms that referenced this issue Jul 16, 2022
rebasing/resolved conflicts
spechtstatt added a commit to spechtstatt/lmms that referenced this issue Jul 16, 2022
spechtstatt added a commit to spechtstatt/lmms that referenced this issue Jul 16, 2022
spechtstatt added a commit to spechtstatt/lmms that referenced this issue Jul 16, 2022
spechtstatt added a commit to spechtstatt/lmms that referenced this issue Jul 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants