[fixed] Cloning track group: assigns new colors & other things

Raul · December 3, 2016, 4:53pm

R3.1 Win10 x64

I have experienced very strange things with groups and tracks when clone group (related by track index (sort), and and also, the colors, and when clone track:

7095

EDIT : An example: Attachment 7096 not found.

For some reason the animated gif does not work on the server (390Kb).

Various problems in clone (all seem to be related):

Colors Groups + Tracks. With groups, the color and intensity not clone, in groups and tracks.The desired behavior is for the cloned track to retain the original color.
Colors Tracks only. Clone a loose track.The color and intensity (color blend) of the track is not cloned either. It should be the same (same color, same intensity …)
Sort. Somehow, cloning groups with tracks, there is some fault in the sort.You can experiment with more groups and tracks, and you will find many errors.This should work with 5 levels of groups correctly.
Expand. For some reason, some groups can not expand either after cloning. Remains blocked!
Collapse group with tracks. If FX columns in group = 0 before cloning, when cloning collapse all group with tracks.

The issue of color I think is directly related to the problem of sort. But when cloning tracks or groups, the result must be the same, including the color and color blend. The sort is important, but the color and color blend also.Cloning implies acting like “a mirror”!

I think it’s a serious bug in R3.1.0, which needs a review…Can you fix it?

Thank you very much for your work!

EDITED :I have updated the problem summary…

Raul · December 5, 2016, 11:45am

I’ve done more testing with more groups and clues, and the result is disastrous. I did new tests without using any tools, in case she had something to do. It seems something internal to Renoise.

I think there may also be problems with these codes:

(“FXg” is the effect columns in group)

local song =renoise.song()

song.tracks[song.selected_track_index].collapsed = true --from the group, collapse FXg only

song.tracks[song.selected_track_index - 1].group_parent.collapsed = true --from the track son, collapse FXg (of group) only = collapse FXg Group
3.
song.tracks[song.selected_track_index]. group_collapsed = true --from the group, collapse entire group

In particular with group_collapsed , that depending on where it is used, acts as collapsed or as group_collapsed. A example:

If you use the code:

local group = { }

group.string = { name=‘STRING GROUP’ , color={ 0x2A,0xAA,0x9D },color_blend=30, collapsed = true }

or

group.string = { name=‘STRING GROUP’ , color={ 0x2A,0xAA,0x9D },color_blend=30, group_collapsed = true }

In this case, collapsed and group_collapsed is the same: collapse entire group. From group, exist not a code to collapse FXg only, (you look at points 1 and 3 again).

Maybe it does not work well here with these codes. Maybe, this has to do with the bugs of this topic, related to cloning groups.

Can anyone test this bugs by cloning groups?Thereby is ruled out as an isolated case and is a serious problem.

Does anyone else have this?

danoise · December 7, 2016, 1:53pm

Hey Raul, a quick answer. I tried looking at your examples, and offer you a bit of feedback:

Regarding (1) and (2): Groups and tracks allow you to assign a custom color, yes. But this custom color is gone, the moment you duplicate something.

You could_argue_that it should retain the color, but it’s strictly speaking not a bug.

Luckily, since this is all in the context of your self-developed tool, keeping control of those colors should be completely within reach? Keep track of the … eh, well, tracks, and apply “your” palette to any newly created/duplicated tracks. If you’ve not already done so, what you need to add to your tool is the ability to monitor the tracks themselves, and respond in an intelligent manner when new tracks appear.

As for (3), not sure what you mean by “sort”?

And (3) and (4), is this relating to normal Renoise usage or when only scripting through the API?

Raul · December 7, 2016, 3:36pm

Hey Raul, a quick answer. I tried looking at your examples, and offer you a bit of feedback:

Regarding (1) and (2): Groups and tracks allow you to assign a custom color, yes. But this custom color is gone, the moment you duplicate something.

You could_argue_that it should retain the color, but it’s strictly speaking not a bug.

Luckily, since this is all in the context of your self-developed tool, keeping control of those colors should be completely within reach? Keep track of the … eh, well, tracks, and apply “your” palette to any newly created/duplicated tracks. If you’ve not already done so, what you need to add to your tool is the ability to monitor the tracks themselves, and respond in an intelligent manner when new tracks appear.

As for (3), not sure what you mean by “sort”?

And (3) and (4), is this relating to normal Renoise usage or when only scripting through the API?

Wow! I think commenting on the use of a tool has been a mistake here.

Forget the tools! Focus on internal behavior of Renoise.And forget for a moment the code to build tools…

For 1 and 2), color is a feature of the track, it should be duplicated too, and not force the user to constantly change the color.The sun colors are useful, even for cloning.It’s not a point of view, it’s how it should work (as if you were duplicating “a png image”, clone the name, the notes, the order of the tracks inside the group, all!).I suspect it relates to the following points.

The theme of colors is important, too. If you use a color and a high color blend in all its clues and groups, when cloning, it is absurd that the colors and colors blend disappears.Has no sense.

Imagine that cloning is like copying an image.

“Sort”, order of the tracks: track one is in position 1, track 2 is in position 2, track 3 is in position 3.When you clone a group with tracks, the tracks are reversed.

Everything I written on this topic has to do with the internal behavior of renoise, under the hood, without using tools.

I think there are several related problems, caused mainly by the theme of sorting groups and tracks.

I will try in depth, because I think it is important.

Renoise 3.1. Windows 10 x64 and please, have a little patience.

CASE 1. Perform the following steps:

Start Renoise (a new project)
Insert a Group (A) in pattern editor
Insert several tracks inside the Group (A).Each track occupies a certain position.
Change the colors and up the background blend to 99 in group, and 50 in all tracks inside the group.The checkbox “Apply to all tracks”, must be off, otherwise, all tracks and groups use the same value in background blend, and it is impossible to differentiate.
Clone the Group (A) using the mouse (CTRL + drag and drop with the mouse)

Several unexpected results:

Background blend is not respected (the value in each track and group).
Colors is not respected.
The order of the tracks within the group are reversed. They are upside down.

Clone must be like copying an image png.You get two equal things as a result.Renoise does not get it.

CASE 2.Perform the following steps:

Close and start Renoise (a new project)
Insert a Group (A) in pattern editor
Insert several tracks inside the Group (A)
Collapse FX columns Group (A) (Ctrl+K).This step only collapses the FX columns of Group (A).Do not collapse the whole group (CTRL+J)
Clone the Group (A) using the mouse (CTRL + drag and drop with the mouse).

Several unexpected results:

Cloned Group appears completely collapsed.This makes no sense.
Expanding the group, equally the order of the tracks within the group are reversed. They are upside down.This makes no sense.

Clone must be like copying an image png.You get two equal things as a result.Renoise does not get it.

CASE 3.Perform the following steps (Include more tracks and group levels the result gets worse):

Close and start Renoise (a new project)
Insert a Group (A) in pattern editor
Insert several tracks inside the Group (A)
Insert a Group ( B )in pattern editor
Insert several tracks inside the Group ( B )
Insert a Group ( C ) in pattern editor
Places the Group (A, with their tracks) and (B with their tracks) inside the Group ( C )
Collapse FX columns Group ( C )
Collapse FX columns Group ( B )
Collapse FX columns Group (A)
Change the colors of inserted groups and tracks.You can skip this step if you want.
Change randomly and individually the background blend of each inserted track and group.Be patient (the more tracks you insert, the longer it will cost you this step).
Clone the Group ( C ) using the mouse (CTRL + drag and drop with the mouse)

Several unexpected results:

Cloned Groups (#C, #A and # Bappears completely collapsed.This makes no sense.
Mysteriously, cloned collapsed groups (#A , # B ) inside the parent group ( #C ), these groups are blocked. You can not expand them!This is very serious.
Background blend is not respected (the value in each track and group).
Colors is not respected.
The order of the tracks within the group are reversed. They are upside down.
The tracks no longer appear within groups.This is very serious.
There is a serious problem with ordering/sort tracks and groups.Renoise does not put the tracks and groups in their correct position.

CASE 4 :Perform the following steps (more groups levels):

Repeat the CASE 3.
Repeat the CASE 3 again (Obviously without restarting renoise).
Insert a Group (D) in pattern editor.
Place the CASE 3 (step 1) and CASE 3 (step 2) inside the Group (D).
You can try more things. Insert more group levels, and play with the settings of each track and inserted group.

Several unexpected results:

A disaster of epic proportions!

Please try all these cases, and check for bugs under the hood of Renoise 3.1.0 which are serious…

Please, “clone” implies copying everything the same: name, color, background color, number of note columns visible, number of fx columns visible, notes, dsp chain, etc. All!And this must be respected when cloning on an individual track, and also on several group levels with many tracks.What the user expects is just that, an identical image , of everything.

On the other hand, Renoise 3.1 needs a deep revision of the behavior regarding color and background color of tracks and groups and clone.Remember, clone = “image”, anything different is a disaster independently of other errors. Otherwise, cloning loses its usefulness.

Note: excuse my English. I may not express myself perfectly

Raul · December 7, 2016, 4:07pm

…

And (3) and (4), is this relating to normal Renoise usage or when only scripting through the API?

Now, speaking aside for the lua code for a tool,I just have some problem with “group_collapsed” in write the code. But it is a subject that I do not want to try here, not to be confused with the internal problems of Renoise.Maybe he’s related.

I remember months ago talking to joule about this theme, and it seemed as if something was not working well, or was wrong with the code, i do not remember the concrete forum.

It has to do with collapsing/expanding groups (entire group or only FX column).To have a reference, is to control with the code, the equivalent to CTRL+J (Collapse/Expand all Group) and CTRL+K (Collapse/Expand FX Columns of Group).

This may have to do with all of the above.I have not created a function to clone a group with multiple tracks, but I’m pretty sure it’s possible to do so.Cloning involves copying everything, not just inserting.But this is another issue.

danoise · December 7, 2016, 4:32pm

Indeed the order of tracks is swapped around. This is surely a bug. Same with the collapsed FX translating into a collapsed group.

Both, I’m pretty sure, are easily remedied.

For the rest, not so sure. My opinion: I wouldn’t mind if the behavior got changed into what you are suggesting. But I my idea of epic proportioned disasters is perhaps a bit different than yours

You should know that there are other things that can change as a result of duplicating grouped tracks - for which there is also no “right” or “wrong” answer.

For example, if you have a track containing a meta-device (e.g. an LFO device) which is linking to it’s own group track, then you could argue that duplicating the group should preserve the “internal” linking and, as a result, the new (duplicated) track should link to it’s new group track. OR you could argue that, no, it’s linking to a specific track so when duplicating the group it will continue to link to the track from which it got cloned.

Wish I could offer an answer that supported you, but it’s not that easy. What you DO have is my support for coming up with smart solutions - via tools or otherwise.

Raul · December 7, 2016, 5:09pm

For the rest, not so sure. My opinion: I wouldn’t mind if the behavior got changed into what you are suggesting. But I my idea of epic proportioned disasters is perhaps a bit different than yours

I mean the final result, not if it is simple to solve.There are several errors together, which offer a result not desired and gets worse by adding more groups or subgroups.The user can not be composing and dealing with this.

You should know that there are other things that can change as a result of duplicating grouped tracks - for which there is also no “right” or “wrong” answer.

For example, if you have a track containing a meta-device (e.g. an LFO device) which is linking to it’s own group track, then you could argue that duplicating the group should preserve the “internal” linking and, as a result, the new (duplicated) track should link to it’s new group track. OR you could argue that, no, it’s linking to a specific track so when duplicating the group it will continue to link to the track from which it got cloned.

This is a more concrete case, which could solve with an option, or not (a checkbox in Preferences/Clonning Options, for example).Actually, the cloned track, you should do exactly the same as the original track.The same if the tracks and groups are related with some device.Perhaps these cases are more complex to solve.Another thing is to ignore it, because solving it can be more complex.

But at least, the basic configurations related to the visual form of each track should be respected (name, color, background color, visual columns, etc… written notes…), as well as the device presents of effects and similar.If there is a complicated case in the chain, it is already a deeper subject that perhaps it is better not to touch.

Thanks for confirming some bugs!Now I know it is not an isolated problem.I was about to reinstall Renoise!

Of course, we will continue to experience things with the creation of tools, this world is beautiful!

Raul · December 8, 2016, 12:53pm

@Danoise and @Taktik (I hope you read this sometime…)

Yesterday check part of the lua code, to look for coherences, and deduction always leads to the same path.The visual way to see each track.Here an example:

local track = {}

track.my_track = {
  name = "MY TRACK",
  color = { 0xFF,0x00,0x00 },
  color_blend = 40,
  visible_note_columns= 1,
  volume_column_visible= true,
  panning_column_visible = false,
  delay_column_visible = false,
  sample_effects_column_visible = false,
  visible_effect_columns = 0
}

local group = {}

group.my_group = {
  name = "MY TRACK",
  color = { 0xFF,0x00,0x00 },
  color_blend = 40,
  --collapsed or group_collapsed = false (are the same?)
  -- --visible_effect_columns?????? (not exist!!!!)
}

The “track” is defined by 9 parameters (If I do not forget something.).These parameters define the visual form of the track.When you clone a track, all parameters are respected except color and color_blend.Cloning should respect all 9 parameters!It’s not my rule, it’s how it should be.The same thing happens with the group, although with fewer parameters. Color and color_blend are the exception.This makes no sense.

@Danoise.We could discuss whether something is correct or incorrect, or that there is not something correct or incorrect, but you have compared a “LFO device” (related to audio), with parameters (related with visual form of the track), and I think it’s a mistake of concept, mixing things up, beat around the bush.If Renoise does not respect the color and color_blend when cloning, Why does Renoise respect the name or visual columns, etc? The color and color_blend, are sacred parameters for visually identifying the track, or group.They should be included in cloning, for consistency, not for a particular desire.

I insist on this, because I think it is important.It is related to the senses of the human being, sight and hearing.When you clone, you see (visual).When you clone, you listen (audio).Renoise 3.1 does not respect the visual section in cloning.But you can clone an empty track, without notes, and not hear anything.It is correct to separate the visual aspect of the audio, and do not mix it.

If the Renoise Team fixes the detected errors, please add the “color” and “color_blend” to the cloning. It is more coherent and better for the composer.

joule · December 8, 2016, 3:19pm

-0.5

Maintaining the variation of colors makes it easier to distinguish tracks. Semantically, a perfect clone would imply cloning all parameters, but this is a case where devs defy “semantic consistency” to make a better decision in regards to UX.

This is really a nitpick, but I think that the general convenience of “automatic rainbowing” overweighs the issue that very few people might have with such behavior.

Raul · December 8, 2016, 4:21pm

-0.5

Maintaining the variation of colors makes it easier to distinguish tracks. Semantically, a perfect clone would imply cloning all parameters, but this is a case where devs defy “semantic consistency” to make a better decision in regards to UX.

This is really a nitpick, but I think that the general convenience of “automatic rainbowing” overweighs the issue that very few people might have with such behavior.

I am surprised by some negative criticism for something so simple and coherent (although it is a -0.5)…

Maybe it’s silly for one who does not use groups + colors + high color_blends.

It’s about cloning a track or group (with tracks inside), not destroying the automatic coloring behavior that has Renoise.Auto coloring is fine when you insert a new track, or when you do not care about colors.In fact, it does not help visually, unless you compose a song with few tracks. Auto coloring does not allow groups to be created by similar colors. Cloning would allow it.If you do not want to repeat a color because it bothers you, insert a new track and use the Matrix Pattern to copy the whole track.

The cloning is different. Renoise should respect the color and the color_blend in cloning (that is, all parameters refer to the visual aspect of the track/group, the 9 parameters).

Use multiple groups and tracks with specific colors and high values in background_blend, and clone the groups.The color intensity disappears (why???), and the original color is not respected (why???).Forces the user to change one by one all the color and color_blend of the tracks and groups.It’s a nuisance when clone groups with tracks inside, with specific colors and specific color_blends.

In any case, include a new preference option (in preferences/clone options, for example) that allows it.Or even a better solution:

7114

This checkbox respects color and color_blend (Background Blend) when duplicating, also!

In any case, not available a option “duplicate” in the drop-down menu of group (equivalent to CTRL+dragging with mouse), neither.This theme seems to be in an underdeveloped point…

taktik · December 29, 2016, 1:26pm

Fixed that now, so that the original track color is retained/copied too. The color actually is a good link to the original track.

There have been a few other issues when cloning group tracks:

pattern content wasn’t copied properly
nested groups didn’t copied properly

Fixed those too.

Raul · December 29, 2016, 2:39pm

Fixed that now, so that the original track color is retained/copied too. The color actually is a good link to the original track.

There have been a few other issues when cloning group tracks:

pattern content wasn’t copied properly

nested groups didn’t copied properly

Fixed those too.

Magnificent! Thank you very much for solving this!I assume you will also add a clone option (“Duplicate”) in the group drop-down menu, when selecting a group in pattern editor (or track, that works correctly for group), or review this too.

Happy new year!