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

FX-mixer strip color indicating it's type #1214

Closed
unfa opened this issue Oct 15, 2014 · 27 comments
Closed

FX-mixer strip color indicating it's type #1214

unfa opened this issue Oct 15, 2014 · 27 comments

Comments

@unfa
Copy link
Contributor

unfa commented Oct 15, 2014

mockup

The idea is to make the mixer aware of some strip categories, and colour the strips accordingly to make it easier for the user to see what is what.

Rules for colouring:

  1. Color as submix (yellow) if the strip has more than 1 instruments or sends assigned;
  2. Color as B+B instrument (violet) if has an instrument assigned that belongs to B+B space;
  3. Color as Song instrument (green) if has an instrument assigned that belongs to Song space;
  4. Color with default if none above criteria is met (unassigned strips, master strip)
@unfa unfa changed the title FX-mixer strip color indicating the strip type FX-mixer strip color indicating it's type Oct 15, 2014
@diizy
Copy link
Contributor

diizy commented Oct 15, 2014

On 10/15/2014 05:53 PM, unfa wrote:

The idea is to make the mixer aware of some strip categories, and
colour the strips accordingly to make it easier for the user to see
what is what.

Seems complicated. What if I have bb-tracks and song editor tracks in
the same FX channel? What if I have an FX channel that gets input from
another FX channel, and a bb-track/instrument track?

Probably a better solution would be to let the user set the colours
themselves manually, but then that gets problematic because we currently
allow setting the appearance of mixer strips in the theme, and we allow
setting gradients and such there... perhaps the strips could be marked
with coloured icons, small coloured rectangles or something.

@tresf
Copy link
Member

tresf commented Oct 15, 2014

Yeah, I think if we were to transfer colors, they couldn't be single-state colors.

Mockup attached:

(note, depicts currently impossible uses of FX routing, but you get the drift)

image

@mikobuntu
Copy link
Contributor

thanks Mikobuntu ;)

The idea is to make the mixer aware of some strip categories, and

colour the strips accordingly to make it easier for the user to see

what is what.

Seems complicated. What if I have bb-tracks and song editor tracks in

the same FX channel? What if I have an FX channel that gets input from

another FX channel, and a bb-track/instrument track?.......................................................................................
this is tricky i agree!

.....................................

Probably a better solution would be to let the user set the colours

themselves manually, but then that gets problematic because we currently

allow setting the appearance of mixer strips in the theme, and we allow

setting gradients and such there... perhaps the strips could be marked

with coloured icons, small coloured rectangles or something.

...............................................................................................how about having an overlay of a gradient foreground > alpha, this would still allow the user set or factory set mixer strips to maintain " most " of their original color. Im thinking the gradient would have a high opacity: setting much like one of unfas mockups.


Reply to this email directly or view it on GitHub. =

@Spekular
Copy link
Member

With all the talk of needing more devs, I wanna take a shot at this. Unfortunately my old C++ environment is long gone and I can't set it up again. If I found time/figured out how to do this, I'd need someone to provide a windows build for me to test, or test themselves, which is a really big favor to ask. If anyone's up for it, let me know and I'll try and get to work.
EDIT: Can someone explain the function naming? The google styleguide uses ClassName::FunctionName, but I see both bbTOC and bbTOCView in bb_track.cpp.
EDIT 2: I'm assuming bbTrack and bbTCO and bbTCOView are different classes. Now I just have to figure out where my code would/should go.
EDIT 3: Doing well so far, need to figure out how to add an element/icon.

@diizy
Copy link
Contributor

diizy commented Oct 16, 2014

On 10/16/2014 08:49 AM, Spekular wrote:

With all the talk of needing more devs, I wanna take a shot at this.
Unfortunately my old C++ environment is long gone and I can't set it
up again. If I found time/figured out how to do this, I'd need someone
to provide a windows build for me to test, or test themselves, which
is a really big favor to ask. If anyone's up for it, let me know and
I'll try and get to work.

Well no, that's not going to work. LMMS doesn't even build on Windows.

What you do is install some Linux distro, perhaps Ubuntu, run it in a
virtual box or as dual boot, whatever strikes your fancy, use whichever
editor you like (I use Geany), edit the code, use the github client.
Compile on Linux, test on Windows. Sounds cool?

@Spekular
Copy link
Member

@vesa sounds confusing :P . I have LMMS running on my computer right now,
and tons of our users are on windows, so I don't see why it wouldn't be
possible to make it run on windows?

@diizy
Copy link
Contributor

diizy commented Oct 16, 2014

On 10/16/2014 11:33 AM, Spekular wrote:

@vesa sounds confusing :P . I have LMMS running on my computer right now,
and tons of our users are on windows, so I don't see why it wouldn't be
possible to make it run on windows?

You can. You just can't compile it on windows. You need a Linux build
environment for building both the Linux and Windows binaries.

@Spekular
Copy link
Member

Well there's another reason I can't compile it :/
I don't suppose you have time? Right now I only have prepwork done, but if
I could make sure it compiles right and doesn't break anything that would
be good. I'll still go ahead otherwise (time permitting), so if you'd
rather not spend time on a build that doesn't change anything (other than
FX Channel widths, hopefully) I get that.

@diizy
Copy link
Contributor

diizy commented Oct 16, 2014

On 10/16/2014 11:58 AM, Spekular wrote:

Well there's another reason I can't compile it :/

Sure you can. Just install Ubuntu on a vm or dual boot. It's not hard.
If you're able to write C++, you should be able to set up Ubuntu.

@Spekular
Copy link
Member

I can't write C++, it is hard, I have limited space on both my computers,
one is a weak laptop and I'm not admin on the other. I borrowed a laptop
running some linux distro once and it took me a day to get logged in and
get the internet working.

@musikBear
Copy link

look at unfa's picture
then look at tresf
unfas design is clean, it is calm for the eyes, it really makes sense, and is easy to 'read'
Eg one glance, and your brain has read the information
tresf' tyny colored square, is confusing for the eyes. Its break the color visibility abrubtly, it is not pleasent for the eyes
Eg Your brain will have to strain it self, in order to read out the information

This is facts.
The nexts are speculative and raises a fundamental question:
Almost Every time i see a design idea that will make lmms more intuitive and user-friendly, it is topedoed with one sentence:
This is not possible, because of themes
So heres my question:
Are themes that important?
That is -Are themes so important that really good design is less important?
Perhaps this is discussion better suited for other fora, but think about it. Here in mixer design, yet another clean design enhancement, are deemed not possible solely on ground of breaks themes!
Imo, themes should be secondary to intuitive and user-friendly design -Always
At least considder something like this
paste
The benefit is that the color-code is not broken up by the background, and has a continued 'band' of information, that is resonably easy to decode for the brain
(here i think red pads, blue plucs, green percussion etc, but that would be user decides)

In respect to Spekular part of the thread:
diiz - Could you make a thoughroly and detailed list of the prerequests for getting started with lmms coding?
What inviroment are that sufficient for something as complicated as lmms- i have no idea.. Especially for linux enviroments..
But most important: What API's and where to find them (newest, correct version aso)
Know that Qt is involved, but that looks like a very confusing family.
I know its a lot to ask, but in context of perhaps getting more budding devs to work on minor stuf, and pushing the project forward, perhaps the time spend, could be gained later.
Of cause a guide could expand this https://github.com/LMMS/lmms/wiki, and perhaps an update on information is needed too?

@Spekular
Copy link
Member

@musikBear +1

On Thu, Oct 16, 2014 at 12:39 PM, musikBear notifications@github.com
wrote:

look at unfa's picture
then look at tresf
unfas design is clean, it is calm for the eyes, it really makes sense, and
is easy to 'read'
Eg one glance, and your brain has read the information
tresf' tyny colored square, is confusing for the eyes. Its break the color
visibility abrubtly, it is not pleasent for the eyes
Eg Your brain will have to strain it self, in order to read out the
information

This is facts.
The nexts are speculative and raises a fundamental question:
Almost Every time i see a design idea that will make lmms more intuitive
and user-friendly, it is topedoed with one sentence:
This is not possible, because of themes
So heres my question:
Are themes that important?
That is -Are themes so important that really good design is less
important?
Perhaps this is discussion better suited for other fora, but think about
it. Here in mixer design, yet another clean design enhancement, are deemed not
possible
solely on ground of breaks themes!
Imo, themes should be secondary to intuitive and user-friendly design -
Always
At least considder something like this
[image: paste]
https://cloud.githubusercontent.com/assets/6662066/4661172/6798fac2-5520-11e4-9b20-f001697915b2.png
The benefit is that the color-code is not broken up by the background, and
has a continued 'band' of information, that is resonably easy to decode for
the brain


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

@diizy
Copy link
Contributor

diizy commented Oct 16, 2014

On 10/16/2014 01:39 PM, musikBear wrote:

The nexts are speculative and raises a fundamental question:
Almost Every time i see a design idea that will make lmms more
intuitive and user-friendly, it is topedoed with one sentence:
/This is not possible, because of themes/

Oh get off it.

You're exaggerating quite a bit here. I've personally written about a
dozen or more /functional UI improvements/ for LMMS, all without
compromising other functionality such as themes. Yes, we have theming
functionality, and no, it's not the highest priority of LMMS, but it is
yet another piece of the puzzle, in a hell of a big codebase, in a hell
of a complex software project, where every part needs to function with
every other part smoothly and without conflict.

That is -Are themes so important that really good design is /less/
important?

Themes /are /good design. We've chosen themes as the primary means for
UI customization, and thus any features for UI customization have to
take themes in account and work with them.

The reason why Unfa's suggestion was "torpedoed" (which is even wasn't)
was not themes at all, but the simple fact that the idea lacks all
detail on how we're supposed to implement the logic for the mixer to
"guess" which strip should be which colour. We don't have channels with
discrete functions, every channel can be used in multitudes of ways, and
the flexibility of the mixer means any one channel can be doing and
being many things at once.

As for colouring the entire mixer strip being somehow objectively
better, well, that's your opinion, not an objective fact. Personally I
think a small-ish coloured area within the strip would be a much more
elegant solution, since it doesn't make the entire mixer look like a
harlequin on LSD.

@diizy
Copy link
Contributor

diizy commented Oct 16, 2014

On 10/16/2014 01:30 PM, Spekular wrote:

I can't write C++,

Then what was the point of this???

@tresf
Copy link
Member

tresf commented Oct 16, 2014

This bug report has split into three questions/topics, only one of which is on-topic and of benefit to this particular bug report.

  1. How to visualize which instruments are sending to which mixer channels
  2. How to get involved in LMMS development
  3. Why do all of our good ideas keep getting shut down?

Here are the three answers:

  1. Good proposals for @unfa's original problem have been illustrated above. Included in this good feedback is some questions by our main UI developer about how to implement them which are also valid and on-topic and have yet to be addressed.
  2. Build Instructions for

    Linux: https://github.com/LMMS/lmms/wiki/Compiling-lmms

    Windows: https://github.com/LMMS/lmms/wiki/Compiling-lmms-(Windows)
  • Note: We can start a thread on the forums to hash out why Linux is necessary and how to get started. The developers are very happy to get more people started with development, regardless of their skill level. Ubuntu can be booted from a USB drive, so there isn't much reason not to get involved!!! If you are going to college for programming, don't wait for a class in C++ to get involved, get ahead of the curve.
  1. Features vs simplicity of the UI. They fight eachother. It's no single person's fault, just logic and we need help. The bug tracker already has some good recommendations on UI improvements, but we try to base them on logical function and ease of integration. If this makes you upset, it's understandable, getting shut down over and over is disheartening. It's also disheartening for the developers to get flooded with hundreds of bug reports, so this frustration is valid and from both sides. Feel free to air your feelings about this in the message boards. The forums were intended for this back-and-forth conversation. The bug reports aren't really intended for arguments or lengthy conversations, as they convolute the OP's request.

🐦

@Spekular
Copy link
Member

@vesa someone said on another issue that even if you don't know the
language, tweaking things until they work is a valid way to contribute and
to learn (which is kinda what inspired me). I'm also learning java and
tried to learn C++ once, so I'm not totally illiterate when it comes to
programming :P. I've already forked and done some coding, so now I want to
see if my "tweaking and hoping" actually works. I suppose I'll see if I can
get ahold of that laptop again to build.

@tresf
Copy link
Member

tresf commented Oct 16, 2014

@Spekular for about 35 Euro (45 Dollars) you can buy a USB stick and install Ubuntu to it. You can then carry it with you and develop wherever you have access to a computer.

http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-windows

Again, this conversion is better suited for our forums. 🍻

-Tres

@Spekular
Copy link
Member

@tresf sorry for going off topic. Anyways, I have some ideas for this:
The original suggestion, the entire mixer changes color based on the types tracks in it:
When multiple types of tracks are in the channel, we can:
*__Have a separate color for this
*
*Display all the colors, horizontally
Display small squares on the right
*The squares would havd some sort of icon or frame based on track type
*The color would be based on the track color for bbtracks
Display lines on the bottom:
*There could be a stack of these lines to represent multiple tracks.

@mikobuntu
Copy link
Contributor

@tres that's quite expensive for a usb stick, my 1st search on ebay showed an 128gb usb for £7.99 with free postage. I believe tho 4gb perhaps 8gb even is quite ample to install ubuntu and have persistant partition to save files/changes etc.

thanks Mikobuntu ;)

Date: Thu, 16 Oct 2014 07:29:47 -0700
From: notifications@github.com
To: lmms@noreply.github.com
CC: chrissy.mc.1@hotmail.co.uk
Subject: Re: [lmms] FX-mixer strip color indicating it's type (#1214)

@Spekular for about 35 Euro (45 Dollars) you can buy a USB stick and install Ubuntu to it. You can then carry it with you and develop wherever you have access to a computer.

http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-windows

Again, this conversion is better suited for our forums.

-Tres


Reply to this email directly or view it on GitHub. =

@tresf
Copy link
Member

tresf commented Oct 16, 2014

*When multiple types of tracks are in the channel, we can:

Yes, this is why I proposed the small square idea. Not as a long-term design solution, but rather as a functional solution to the multiple channel problem.

tresf' tyny colored square, is confusing for the eyes. Its break the color visibility abrubtly, it is not pleasent for the eyes

It's just a conceptual mock-up, it's not meant to be pleasant. A more pleasant mock-up may look like this:

image

@tresf
Copy link
Member

tresf commented Oct 16, 2014

@tres that's quite expensive for a usb stick, my 1st search on ebay showed an 128gb usb for £7.99 with free postage.

Great, even cheaper then. :)

I believe tho 4gb perhaps 8gb even is quite ample to install ubuntu and have persistant partition to save files/changes etc.

The mingw32 and mingw64 libraries weigh in at about 1.5GB combined, but going the mingw route you can't test your code changes without a Windows box (or Wine). To build on Linux, you may choose to install Wine and Wine-dev. Add this to the existing Linux depends and you can get close to 8GB very quickly. But in today's age, I wouldn't recommend anyone spend money on removable storage under 128GB. He may want to start storing his VirtualBox images on there, or his sample library, or some movies. :)

You are right, if he has an 8GB drive he might be able to swing it, but when he runs out of space, he'll have to uninstall packages or upgrade to a larger drive and create it all over again. 👍

@tresf
Copy link
Member

tresf commented Oct 16, 2014

@diizy what if we rethink the colors and allow the FX channel color to drive the instrument color?

This way if two instruments send to the same channel they MUST be the same color, or use routing to circumvent the color limitation.

The effect of setting a color on a channel would in effect change the color of the FX channel assigned to it. If no FX channel is assigned, it overrides the color of master.

@diizy
Copy link
Contributor

diizy commented Oct 16, 2014

On 10/16/2014 05:08 PM, Spekular wrote:

@vesa someone said on another issue that even if you don't know the
language, tweaking things until they work is a valid way to contribute and
to learn

Sure. But you still have to know the basics of how programming works.
You need to know the syntax, semantics, program flow and that kind of
stuff. If you've never coded any C-like language there will be a
learning curve.

@MartyLake
Copy link

Color coding informations is IMHO a good idea, but if the user can't easily modify them, it may become a problem for color-blinded people (8% of male population)
and for visually stressful environment (a live in a nightclub ! I don't know if it's the typical LMMS use-case, but better safe than sorry =D)

If it's automatic, I suggest to add some icons as well. for example 🎵 musical note for miditrack and 〰️ simple waveform for soundtack

@unfa
Copy link
Contributor Author

unfa commented Oct 23, 2014

Actually, every instrument has it's own icon (audio tracks too), so maybe using that icon in the mixer strip would do... but if there are 3 instruments of different type assigned to a channel - how to display all that in the limited space? Scaling down and showing a grid? Making an icon-sandwitch combined with scaling down the whole thing?

This was referenced Jan 19, 2015
@Spekular
Copy link
Member

@tresf to be consolidated into #1665 as this has to do with user definable colors. (Better message?)

@tresf
Copy link
Member

tresf commented Jan 21, 2015

This bug report has been consolidated (at least for now) into a placeholder #1665 for better color handling in general. Feel free to update this bug report or the parent bug as needed.

As part of a pruning effort, this enhancement request is archived into a dedicated "Better Workflow" checklist here #4877.

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