BREAK COLOURS

Hi

Would it be at all possible to have an option where we can set a colour for an automation break.

Currently its possible to do it individually but i like them to be a certain colour always so it would be really useful if we could set it so they are always a certain colour. Hope that makes sense.

Is it possible?

Hallo, you can write this in the playlist (*.mld)

BREAK #FF8000

Hi Torben, would a BreakRowColor (in the skin.ini) option solve this?

Kind Regards Tony

As people will want to have this feature for other special items types (streams, silence, …) as well, I can only image two possible “clean” solutions:

  1. Add respective RowColor settings to skin.ini. This is probably the “cleanest” way, as you do not touch the items but only define how they should look like. Pretty much like the stylesheet stuff in HTML. However, the problem here is that it adds another dimension to the skin configuration, and it may also conflict with the per-player-state colors. (When you have defined both a color for stream items and a color for items loaded into a player, which color will a loaded stream item have?)

  2. Rely on the existing method of assigning colors through the Properties dialog, and offer the ability to specify default color for each type. Any newly created item of that type will then have the respective default color.

What do you think?

I think the first option is much better.
In this context I would also like to emphasis that I would appreciate an option which visualizes the different types of playlist items (especially the dummies and music items). To my mind changing the font colour of these items in skin.ini would be very nice, e.g. “DummyFontColor=000000”.
Torben, perhaps it is possible to implement this as well.

i like the idea of the first idea also.

basically, all i want is to be able to add an AUTOMATION BREAK into the playlist and for it to be the colour i want it to be, rather than having to individually change every single break point.

When doing it in this way, you have to save as local, is it not possible to simply allow it to be save to METADATA FILE?

CHEERS

A break note is no (audio) file, so it has no associated MMD file. It only lives within a playlist.

Of course, the color setting is saved when you save the playlist.

The problem about all these different color and font settings it the one I have mentioned above: Right now, there is no way to determine which of two “conflicting” settings has priority.

Perhaps I could extend the semantics of skini.ini in way that the order of the settings is taken into account. That means, whenever the color and font settings of a particular item is to be determined, the skini.ini section is processed line by line, and each line matching the item’s properties and player state is “collected” and applied.

For example, imagine the following skin.ini:

[Playlist0] RowColor=#00FF00 StreamRowColor=#0000FF LoadedFileRowColor=#FFFF00 PlayingRowColor=#FF0000

Now imagine we have a stream item which is currently playing in a player and we want to determine the color of that item. The default value for a row is white. We set our temporary variable to “white”.

  • The first line “RowColor” matches for any item in any state, so it overrides the default row color, and we set our variable to #00FF00.

  • The next line “StreamRowColor” matches our item, because it is a stream. So the variable is set to #0000FF.

  • The next line “LoadedFileRowColor” does not match our item, so it is skipped.

  • The final line “PlayingRowColor” matches our item, because it is playing in a player. So we set our variable to #FF0000, which will be the color of our row.

If we swapped the “StreamRowColor” and “PlayingRowColor” lines, the “StreamRowColor” would be processed later and thus have priority.

The problem is that the color and font settings need to be determined very frequently, and processing the skin.ini in this way would be very inefficient, at least when we compare the strings all the time. So I need to find a way to cache the entries in way that they can be effiently evaluated.

Ok, I have started to implement this. Seems to work pretty well. Will be available as of v2.1.38.

I have updated the article in the Wiki: http://wiki.mairlist.com/index.php/Changes_in_mAirList_2.1#Playlist_Skin

Does that mean that I can finally change the font colours according to the type of item in the playlist? That sounds really great! =)

Yes, you can.

I’m really looking forward to the new version. Again: mAirList is the greatest freeware I know so far! :stuck_out_tongue:

mAirList is not freeware :wink:

Well… for me, it definitely is! :wink:

Ask a silly question, I’ve been through the Wiki and can’t see an obvious solution… But, how do I KEEP my existing colours as specified via the MMD files ? Everything is WHITE at the present, although I have been in and set the COMMANDS to a different colour - but my existing MMD colours are ignored…

It’s a bug.

Implementing the new skin.ini handling, I totally forgot about the individual colors …

By the way, should the individual colors always have priority over whatever you set in skin.ini? Or the other way around? Or even configurable?

I think it depends, doesn’t it? Normally the playlist shows the individual colour. But when I highlight the item it has to change to FocusedSelectionColor set in skin.ini. Or for example when I have given an item a green colour but skin.ini says that PlayingColor is red then it has to turn into red when it is started in a player.
But perhaps the configurable way is the best for all. :wink:

I would say that specific files’ MMD properties should take priority as they have been “user defined”. That way, new items can default to the skin.ini settings. I would like all non-audio items like Dummy, Command, Break Notes etc to appear as a globally-set colour (unless, say, they are opened from an MLP playlist where I can overright that colour). So any “new” files are shown according to the skin.ini settings.

I’d rather agree with Charlie. However, be aware that the player state specific settings (PlayingRowColor etc.) are also ignored once an item is assigned a specific color.