I am working on a tool that I call “Track Clips”. It will treat a track per pattern as a clone to whatever others you want, meaning it will copy its content to the cloned tracks whenever data is being entered in any of them. These “clone pools” are being managed by the custom track (slot) color - meaning all slots in the pattern matrix with the color #853962 will always have the same content.
The biggest challenge is the usability - to make people actually implement it into their workflow. Luckily (or not), the slot color is being copied whenever you copy/paste a track - so you won’t have to set a custom color too much.
I want to avoid making a GUI. If someone finds this interesting, I am open to suggestions and ideas how to make it as good as possible.
I was thinking about making it more advanced with a patterneditor-menu like this:
– Insert track from pool -> submenu with available pools
– Create new pool from track
– Unbind track from pool
The visualization will be track color only. Since everything is being managed from the custom track color, I would be grateful if anyone could hint on how to generate random colors that are good and diverse enough.
It also occured to me that pools might even be able to name, by using some seldom used value holder in renoise.song().patterns[].tracks[]… Then perhaps it is better to use that as an identifier and make a GUI, instead of cluttering the pattern matrix with custom track colors.
That’s called Alias Regions (or something) in Logic. I can understand Alias easier than Track Clips.
With Track Clips, I was hoping you were going to implement “Instrument specific multi-length Patterns”, up until I took the time to read what you wrote.
Here’s my question:
If you have a 16 row Track Clip in the tool, and that is used over the course of a song of 512 row pattern length, would these 16 rows be looping inside the 512 row patterns, and if I then enlarge the 16 row track clip to be 32 rows, would the 512 row pattern length which has the 16 rows loooping for the duration of the pattern, change accordingly?
I.E., could I start with a really short pattern, build a track over that drumbeat, and then decide, “no, I wanna have 16 variations of this short pattern”, edit the original 16 row pattern, switch it to a 256 row pattern, do my variations, and watch them be switched all over the full song, and be able to trust it’s functionality?
I think that’s a good suggestion and the way it should work. That would be a lot better than a “cannot bind track to pool due to different pattern length”-warning.
Alias is a good term. I’m not sure what to call it yet.
It occurred to me that maybe the easier way to define diverse and somehow reasonable random colors would be to generate the colors with HSL - colordefinition and transform that to RGB. That way you could in a straightforward manner ensure sufficient diversity in hue, but still keep the saturation&lightness values in control. Never done that myself, but it seemed like something to check out, maybe?
Another thought I had about the color system is that whether the matrix block colors denoting clips are generated randomly or not, the clip family’s color should be also user controllable. Meaning that you should be able to define the color for a clip family.
BTW: really anticipated to see this tool idea being realized!
Changing colors afterwards should be possible - and copied to all track clones. That means it will have to keep track of the pools in an up-to-date table (initialized on song load). It’s good getting opinions like this because it helps a lot when it comes to using the right methods programming wise.
Another feature i just thought of is “auto-generate pools”. When run it will define track pools by binding all tracks that are already equal.
Not sure I fully understand this tool, from the first post I thought I did but the subsequent discussion confuses me.
I assume when you say Clone and Equal you are referring to Note Data really. Different DSP and automation do not come into it, arguably Instrument Number may also be ignored.
The reason I say this as the instant use I thought of was when I layer sound to make, for example my hats, I may use a few different sound but then have different effects with different automations or LFOs meaning that Render To Sample to capture the single layered sound is not sufficient. But when later adding variation or extending the song I would want to have more than one track written/changed at once. Being able to have Instrument used in each track different would definitely help for this.
You can already used Advanced Edit to Copy and entire Track in the Song and then Remap Instrument number for the new track. What is mainly lacking is the ability to do it while entering notes. I also wouldn’t overly want to to then treat the tracks as still being an alias (IE updating old data) if I turn it off and on to add some variations to one track/part and not the other to vary the texture. Maybe others would though…
And if I’m reading the tool right I would say Track Aliasing/Aliases seems to make most sense for a name. Track Pool sounds more like a Clips idea…
I think it should be optional if a track (patterntrack really) pool will “contain” automation or just the patterndata. Good point. The DSP chain will never be affected though - (when I write track I really mean patterntrack). Patterntrack is not a very common term. “Slot pool” might be technically better but “track pool” is more explanatory imo.
Although at first glance your idea seems more elaborate, bit different, thought I’d mention there already is an auto-clone pattern tool if you didn’t know? Maybe you can get some inspiration from the script: http://tools.renoise.com/tools/auto-clone-patterns
Yep, but that’s just a brute-force copy-sequence-selection-to-new-orderlist&new patterns type solution… This one would be more akin to how Alias Regions work in Logic.
