Targeting track rename

[robenestobenz]

Hi Jo,

I imported a project from M2 to M3 and realised, after being confronted with 4 tracks of automation all unhelpfully named "TAL-Bassline", that you can no longer rename tracks if they have a target set. Would it be possible to add this feature back in?

[MuTools]

There is a FR stop for some time, sorry. Bugs and problems will be fixed though. Also support continues of course. The FR stop is purely so to be able to concentrate on some other vital aspects. Hope you understand.

[robenestobenz]

Argh. Yeah, I do understand that. Although when you can even rename VST instances in racks, renaming tracks seems like such a fundamental ability that I almost don't.

//edit: I've just noticed that the title also returns to what you renamed it to after you remove a track target. Is this behaviour deliberate, or an accident introduced during your experiments with the track-targeting?

Trying to sneak it into the bug / problem category is not at all what I'm doing. Honestly

[MuTools]

First of all, i hope my message didn't sound too obstructive/negative, not meant like that at all. What i mean is that i need some time away from the details now, travelling back to sky/overview mode, which will be the first step towards m4. No more, no less

Regarding the track names:

If a track is connected to a target module, then the track name is fixed to that target module's name. (so to avoid any confusion) If the track is unconnected from its target, then you can (re)name the track again.

[robenestobenz]

First of all, i hope my message didn't sound too obstructive/negative, not meant like that at all. What i mean is that i need some time away from the details now, travelling back to sky/overview mode, which will be the first step towards m4. No more, no less

Nah, don't worry -- I didn't get any sense of negativity from what you wrote.

Regarding the track names:

If a track is connected to a target module, then the track name is fixed to that target module's name. (so to avoid any confusion) If the track is unconnected from its target, then you can (re)name the track again.

I think that if a user names a track something they're already going to know what it is and name it something indicative of that.

Whereas with multiple automation tracks, or audio tracks sharing the same destination (neither case too rare, I doubt) having the same name across all tracks is very likely to cause confusion, unless a user names their parts. Which is possible, but the wrong level for a description that is likely to apply to the entire content of a track, such as "vox - high" or "cutoff" or whatever.

Anyway, I can always name the track parts. I'll let you get back the big picture

[MuTools]

Isn't it indeed more relevant to give the parts the specific names as they do contain the efective content (notes, parameter automations, audio, ...)?

[robenestobenz]

Isn't it indeed more relevant to give the parts the specific names as they do contain the efective content (notes, parameter automations, audio, ...)?

In one sense. But it's typical practice in track-based sequencing to have one sonic character per track, and in this case I think it's better to be able to have track names relevant to their function in the song rather than their destination.

I can appreciate the autoname makes sense for sequence tracks targeting instruments where the nature of the relationship between track content and target is pretty well described by the target name. Even without part naming, if I see a bunch of parts with notes in a track named Moon Bass, I know what is being sent and where.

In the case of automation with one param per track however, only half of the relationship is always clear - you know 'where', but unlike the note scenario, you don't know exactly 'what' without part naming.

It's even less clear in the case of audio, because the relationship between 'what' and 'where' is different to begin with. E.g. I have two audio tracks, one of acoustic guitar and one of my cheapo ukelele. There's not a lot going on at this point in the track so I want a dry, full bodied sound with a bit of room. So I send the tracks to the same reverb and as a result my ukelele and guitar tracks are now both called EpicVerb. Without part naming, the 'what' is completely unclear.

It's not a huge deal... but not very helpful at a glance. In future, I'll just name parts -- but as I'm importing a load of projects to M3 at the moment this issue has come up a lot -- and it does seem counterintuitive in the case of audio.

[liquidsound]

In one sense. But it's typical practice in track-based sequencing to have one sonic character per track, and in this case I think it's better to be able to have track names relevant to their function in the song rather than their destination.

I don't know if I understand exactly this but when I need to name a Track that is targeted to PlugIn I rename the PlugIn as: Bass[Albino] and so the Track reflects that name.

Do I follow your argument or I'm off?

[robenestobenz]

In one sense. But it's typical practice in track-based sequencing to have one sonic character per track, and in this case I think it's better to be able to have track names relevant to their function in the song rather than their destination.

I don't know if I understand exactly this but when I need to name a Track that is targeted to PlugIn I rename the PlugIn as: Bass[Albino] and so the Track reflects that name.

Do I follow your argument or I'm off?

No, I agree with you the autoname works in this case. It's if you have audio, say guitar, routed to a shared plugin and your track of guitar is now called MuVerb or RetroDelay. Or if I have 3 tracks of automation, to take your example they will all be called Bass[Albino]. Which doesn't reflect the function of these tracks in the song. It's for these quite common scenarios that I think a user-given name should override the destination name inheritance (plus I reckon that if a user WANTS to rename a track, they probably have a good reason for doing so in their project).

[liquidsound]

Agree on those points.
The only (crazy) way to have a indipendent Label is to assign a SubTrack to a Track and use it as a Label which you can simply click expanding it for reference.
An inverted folder system

[Eggu]

I also think the autoname function does not work properly.
I have a track with a target module and a Mulab plugin (realbass),
autoname gives track and rack the name realbass --> ok up to this point.
Then I added a 2nd rack, added a new vst plugin to realbass rack, moved the realbass plugin to the new rack (parking slot), and by doing these steps names of track and racks changed in a way I don't understand, track name no longer the same as the target rack, .. very confusing.

[MuTools]

There indeed is a little bug there. The updated names are not immediately refreshed. Will be fixed.