Mixer solo buttons?

[unfa]

We've got the mute, but could we add the solo too? Pleeeease :smile:

[diizy]

On 10/15/2014 04:12 PM, unfa wrote:

We've got the mute, but could we add the solo too? Pleeeease :smile:

We could, if we had some more developers.

[grindhold]

is someone already working on this? if you wish i could try to tackle this one.

[tresf]

Please do!

[grindhold]

Will do :)

[musikBear]

After (slowly) having gained understanding of the send-mixer, solo on channels would be a fantastic tool Big :+1: for unfa' sugestion!

[grindhold]

wee. some new solobuttons:

But i have a question. the dependence structure of the fx-channels seems to be tree-ish. What exactly is the desired behaviour?

if channel 1 depends on channel 2 and i toggle solo on channel 2 in an analoguous manner to the current implementation in the tracklist, it makes no sense. because channel 1 will be muted and thus no one will hear a thing from channel 2. if i am right, the solution would be to not-mute any parent of the solo'ed channel. any ideas?

[tresf]

It should behave identically to changing the volume of that mixer channel to zero in its current functionality. Correct, don't mute parents (assuming a child "sends to" parents).

-Tres

[tresf]

Also, sorry to pick on aesthetics, but the spacing of the LEDs should be a bit further apart. :+1: Very excited to see progress on this!!!

[diizy]

On 10/30/2014 07:42 PM, Tres Finocchiaro wrote:

It should behave identically to changing the volume of that channel to zero in its current state. Correct, don't mute parents (assuming a child "sends to" parents).

Solo should be identical to muting all other channels.

As for not muting parents... well, that's where it gets tricky, right? Even if we don't mute the parent... what if the chain is longer? Care needs to be taken here to prevent slowing down... we can't evaluate this every period.

[diizy]

Which is why possibly a simple implementation would work best. Don't worry about the parents at all - if the parent gets muted by solo, the user can just unmute that manually... after all, the same thing happens when using mute - if you mute a channel, then all the dependencies of said channel also get muted.

[grindhold]

@diizy : I currently attempt to do the following on a click on a solo button:

1. mute everything
2. unmute the channel the solobutton was clicked on
3. recursively unmute every channel the solo'ed channel sends to

this way, the recursion will only be necessary only once (on click). not every period.

[diizy]

On 10/30/2014 10:59 PM, grindhold wrote:

@diizy https://github.com/diizy : I currently attempt to do the following on a click on a solo button:

1. mute everything
2. unmute the channel the solobutton was clicked on
3. recursively unmute every channel the solo'ed channel sends to

this way, the recursion will only be necessary only once (on click). not every period.

sounds reasonable, doesn't

Sure, that just leaves a couple of questions to answer

• How is the mute-status of the channels restored when the solo is disabled?
• What happens if you solo multiple channels? To be consistent with track behaviour, this should switch solo to the second channel, while still preserving the mute status of all channels, to be restored when solo is disabled

I suggest looking at how this is handled in tracks, to replicate the same logic.

[grindhold]

@diizy have a look at the solution. i left open a TODO, if we decide to actually unmute the send channels automatically. @tresf also i have set the leds further apart

[diizy]

On 10/31/2014 12:47 AM, grindhold wrote:

@diizy https://github.com/diizy have a look at the solution. i left open a TODO, if we decide to actually unmute the send channels automatically.

Looks good so far.

Some coding style notes... we usually leave space inside parens, eg. function( parameter ); not function(parameter). Also, we usually don't use the this-> pointer for calling methods within the same class, as it's not actually needed in C++.

[grindhold]

derp. i knew i'd forget something. apparently i paid too much attention on putting braces after method signatures into newlines :D fix coming up in 3..2..1..

[grindhold]

and it's done

[Umcaruje]

Ok so this is awesome, but here is a little problem: when you solo your FX channel it mutes the Master channel too, so actually you can never hear your solo channel.

[grindhold]

@Umcaruje : quote @diizy

Which is why possibly a simple implementation would work best. Don't worry about the parents at all - if the parent gets muted by solo, the user can just unmute that manually...

[tresf]

^-- Yeah, I can't think of any situation where a button labeled as "solo" making no noise would be what a user intended.

[unfa]

Awesome, man! Can't wait to see it in action on my machine :) Many thanks for scratching this itch! 30-10-2014 18:34, "grindhold" notifications@github.com napisał(a):

wee. some new solobuttons: [image: solobuttons] https://camo.githubusercontent.com/aa7d269a850e8b3e640d115fb6c5920dca054c5c/68747470733a2f2f696d6775722e636f6d2f677872384c37392e706e67

But i have a question. the dependence structure of the fx-channels seems to be tree-ish. What exactly is the desired behaviour?

if channel 1 depends on channel 2 and i toggle solo on channel 2 in an analoguous manner to the current implementation in the tracklist, it makes no sense. because channel 1 will be muted and thus no one will hear a thing from channel 2. if i am right, the solution would be to not-mute any parent of the solo'ed channel. any ideas?

— Reply to this email directly or view it on GitHub https://github.com/LMMS/lmms/issues/1211#issuecomment-61134321.

[tresf]

Closed via #1590