v6.78+dev0317 - March 17 2023

[n997]

Originally Posted by Klangfarben

[...] What were you doing previous to this pre when all the midi items were named "Untitled MIDI Item"?

I had/have this entry in the language file, which removes the "untitled MIDI item" and thusly allows for blank MIDI item names:

[item]
E57128C4770463B2=

Originally Posted by Klangfarben

[...] If you don't like the names, just toggle off display of item names.

Originally Posted by Thonex

[...]
n997 gave an example where blank item names are easier on the eyes. Again, my answer to that is SWS/BR: Options - Toggle "Display media item take name"

With that suggestion, I'd have to toggle item names all the time.
That would make my workflow worse than what I already have [in public releases], which is: possibility to have blank-named MIDI items by default, and naming some of them if/as needed.


***


Also, in general, what I'm trying to say is that we don't have to argue for "the one true way" here. In matters regarding personal workflows, might as well try to claim that some of us should change the way they hold eating utensils - or, perhaps, from which end to break an egg

REAPER being the most customizable closed-source DAW in existence, might be simpler to ask devs for an option to have both kinds of behaviors we've explained here..?

[_Stevie_]

Originally Posted by akademie

I understand, but in many other genres and doing music intuitivelly rather than as predefined rutine such templates are not much of use.
Rather smaller building blocks are usable then, that's for sure, but still, no exact names etc.

Right, but just to understand: what does prevent you from naming your tracks Synth 1, Synth 2, Atmo 1, Collage 1, MAX/MSP, SuperCollider, Recording, you name it... and then go from there?

[vitalker]

Originally Posted by Klangfarben

Right. But consider this. For some of us, at some point, the MIDI item WILL have a file attached to the item as well. It just happens at a later point than with audio. So getting the housekeeping right to begin with is very important. Because if not, later it can become VERY costly.!

If you already have named midi file, how will ruin your workflow? Or you are talking about automatic renaming of all items? I don't think it works like this now.

[vitalker]

@n997 that's why I suggested wildcard system. You could get blank, track name, track number, a combination of them etc.

[akademie]

Originally Posted by _Stevie_

Right, but just to understand: what does prevent you from naming your tracks Synth 1, Synth 2, Atmo 1, Collage 1, MAX/MSP, SuperCollider, Recording, you name it... and then go from there?

Simple, I do not use any of such.
All my sounds are synthesized, using only Reaper FX chains, so there is nothing given prior to building it from a scratch. The track is named after the sound or part being laid out for example (not necessarry exclusive this way, sometimes I may create named track and make a sound or part to it if I feel like that).

I would say that that's the part of unlimited options. If we have 16 track (or 8 track) tape recorder it would be easy - hey name the tracks 1-8(16) and done. Then, in extra paper sheet, fill in what's recorded on track 4 at which places in a song ,...

If I were to record routinely a song be templates, then it would work. Also if it was the band with given instrument line up again this could work. In electronic music of its kind not much.
And 10 unnamed tracks are so easy on eyes than the same 10 tracks named "Untitled" for example. You can try it for yourself how it looks

[akademie]

Originally Posted by vitalker

If you already have named midi file, how will ruin your workflow? Or you are talking about automatic renaming of all items? I don't think it works like this now.

I think Klangfarben means that at some point he exports the MIDI items to *.mid files and they have kind of external indirect reference where are they coming from, not real in project reference. I may be wrong here though.

[vitalker]

Originally Posted by akademie

I think Klangfarben means that at some point he exports the MIDI items to *.mid files and they have kind of external indirect reference where are they coming from, not real in project reference. I may be wrong here though.

Ah, you are probably right, thanks. Then it's still better to somehow name items before exporting. I doubt automatic naming is useful here, unless you can use wildcards.

[Klangfarben]

Originally Posted by vitalker

Yeah, it is you who is not reading. I've already made a statement about exporting items.

So, wildcard solves everything then?

Even though I've done this like 8 times now in this thread I'm going to try and spell this out - again.

You do realize that when exporting midi there are no wildcards, right? You have wildcards in the render window, but those are for audio renders not midi.

So what happens when you send a bunch of correctly labeled files to your orchestrator and accidentally have a few "unknown render 001", "unknown render 002" files in there? Are they supposed to just make sense of it? Guess which instruments they are supposed to be?

What happens when I have 200 some midi items that were all properly named and exported correctly but I forgot I added a new track and was working quickly and forgot to give it a name and an "unknown" file got in there and sent out. Let's say it got sent out to someone in London and you went to bed and now they have to wait hours before you can wake up and solve it for them. Or worse, they don't wait and just toss it out.

What happens when you have a script that filters selection by item name and performs a midi process on them and again, you had a bunch of properly named items and a few that weren't because you were moving quickly and the track didn't get named, thus the items didn't get named? And again, that midi that you *thought* was all correct got sent out for prep and the copyist put it in the score wrong.

What happens when you initially did not name the track, created some midi on that track, renamed the track and then exported that midi? Are you going to be so ace that out of *thousands* of midi items you are going to spot that one bad name? When you already checked that your track is named correctly?

Housekeeping exists for a reason. It is so you don't screw yourself. Now, maybe some users want to screw themselves. Or don't care about screwing themselves. They don't have to ever deliver files, so who cares? Except the difference here is those users aren't being forced to screw themselves with an unintended consequence that you are going to miss by the law of averages. They will never run into any of those scenarios.

All because of something the devs missed when implementing the new midi naming feature. Doesn't make a lot of sense.

[dangguidan]

For a long time, I have used scripts to regularly modify the MIDI take name, with the following format:
ProjectName - [TrackName] #itemnum
I feel very useful myself, inspired by the ancient cakewalk 9.

[n997]

Originally Posted by Klangfarben

So, wildcard solves everything then?
[...]

I believe the solution would be a new option for track naming (with wildcards support), similarly to what was suggested by Odys here: https://forum.cockos.com/showpost.ph...&postcount=120

That is, a field in Preferences / Appearance / Media / Media item appearance / Media item labels:

Name of new MIDI items/takes (wildcards accepted): [ $tracknumber $track $takemarker ]

You could set the name format exactly as required by your orchestrator, client, scripts etc.; and if the field was set blank, the names of new MIDI items would be blank.

[Odys]

Originally Posted by n997

You could set the name format exactly as required by your orchestrator, client, scripts etc.; and if the field was set blank, the names of new MIDI items would be blank.

Exactly that because what is difference between blank name and "untitled midi item" and some random generic name? None of which tell anybody what it is and where it goes. "Untitled midi item render" means exactly the same as "unknown render".

If somebody cares about proper house keeping needs to be diligent and give proper descriptive names to its content.

Originally Posted by Klangfarben

What happens when you initially did not name the track, created some midi on that track, renamed the track and then exported that midi? Are you going to be so ace that out of *thousands* of midi items you are going to spot that one bad name? When you already checked that your track is named correctly?

Bad name is generic name, means nothing.
If U have blank midi item on named track, rendered item will take name of that track, if item is named "untitled midi item" rendered item will be named "untitled midi item render."



I would say that track name is better than random name.

Issue seems to be that exporting script U used so far sucks.

[vitalker]

Originally Posted by Klangfarben

You do realize that when exporting midi there are no wildcards, right? You have wildcards in the render window, but those are for audio renders not midi.

I'll say it for the last time. Exporting midi should also have wildcard system. Not sure why you missed it, I wrote it many times.

[vitalker]

Originally Posted by Odys

Exactly that because what is difference between blank name and "untitled midi item" and some random generic name? None of which tell anybody what it is and where it goes. "Untitled midi item render" means exactly the same as "unknown render".

If somebody cares about proper house keeping needs to be diligent and give proper descriptive names to its content.


Bad name is generic name, means nothing.
If U have blank midi item on named track, rendered item will take name of that track, if item is named "untitled midi item" rendered item will be named "untitled midi item render."

Exactly what I was repeating here. I think that's the end of discussion.

[sockmonkey72]

Originally Posted by Odys

I would say that track name is better than random name.

Of course that's the case, EXCEPT when there's no track name, which is the REAPER default, for better or worse. In that case, ANY name is better than no name.

A generated name based in the track number was the previous behavior for recorded items on no-name tracks, and it was perfectly adequate.

[sockmonkey72]

If you want to provide a straightforward way to template the default track and item (without requiring custom actions/scripts, menu modifications, etc. to get there), then I don't care about the defaults. Anonymous items, etc. are IMO a bad choice, but if my preference can be handled quickly and easily, the default is less critical.

As it is, there's no plausible way to avoid anonymous items in a default new track in the current state. I am forced to write and run scripts, change menu assignments, etc. to get to a sensible starting point. Even then, double-click is going to get me back to the thing I want to avoid.

Forcing users to do more work in order to achieve a sensible outcome (which the old behavior was one example of, if imperfect) in order to accommodate a handful of advanced users' workflows is backward, though.

[Odys]

Originally Posted by sockmonkey72

Of course that's the case, EXCEPT when there's no track name, which is the REAPER default, for better or worse. In that case, ANY name is better than no name.

A generated name based in the track number was the previous behavior for recorded items on no-name tracks, and it was perfectly adequate.

No its not, blank better.

If You start recording with track generic name all midi items will have generic name, renders of those will have generic name even after changing name of track to something meaningful.

Recording on blank track will leave everything blank, change name of a track to something descriptive, all renders of midi items are descriptive.

Order is this:
1 - item has a name - renders with item name
2 - item name is blank - renders with track name
3 - both item and track name are empty - unknown render - user error

[sockmonkey72]

Originally Posted by Odys

Order is this:
1 - item has a name - renders with item name
2 - item name is blank - renders with track name
3 - both item and track name are empty - unknown render - user error

This is PRECISELY my point. The current default behavior creates this "user error" state, right out of the gate. The user will always have to do extra work to fix the situation.

[Odys]

Originally Posted by sockmonkey72

This is PRECISELY my point. The current default behavior creates this "user error" state, right out of the gate. The user will always have to do extra work to fix the situation.

In what way shape or form, one generic name like "record of track 3" is better than other generic name like "unknown render"? Both describe user error, that nothing was properly named.

Blank item will at least follow new name of track. "Burned in" generic item name will stay after track name change.

If move my track 3 or name it "chord track" or something items will remain "record of track 3" and now I have to change all of them.
The user will always have to do extra work to fix the situation.

[sockmonkey72]

Originally Posted by Odys

In what way shape or form, one generic name like "record of track 3" is better than other generic name like "unknown render"? Both describe user error, that track wasn't named.

Blank item will at least follow new name of track. "Burned in" generic item name will stay after track name change.

If move my track 3 or name it "chord track" or something items will remain "record of track 3" and now I have to change all of them.
The user will always have to do extra work to fix the situation.

Now you are just being deliberately illogical to argue for your desired outcome.

The defaults cause the "user error" situation you described every time, without manual intervention. That means it's not user error, rather that it's a poor, user-hostile default.

[Odys]

Yes I'm illogical "recorder on track 3" properly describes content of an item no mater what it is and fulfills everybody needs reliving them from naming anything.

Originally Posted by sockmonkey72

The defaults cause the "user error" situation you described every time, without manual intervention. That means it's not user error, rather that it's a poor, user-hostile default.

So it nullifies this ?

Originally Posted by sockmonkey72

This is PRECISELY my point. The current default behavior creates this "user error" state, right out of the gate.

Great !

[Phazma]

Wow this thread exploded...

I think the following set of preferences should make everyone happy:

- Name newly created tracks automatically [Default: ON]
- Append current track index to track names [Default: OFF]
- Name newly created MIDI items automatically [Default: ON]
- Sync item names to track names [Default: OFF]

IMPORTANT: None of these should apply if the user intentionally renames tracks or items. These are SOFT, TEMPORARY names that serve the purpose of avoiding unnamed tracks or items and help with keeping things named as meaningfully (to the individual user) as possible, provided the user desires this help. Also preferences like "Automatically name unnamed tracks on media import" should override these generic names.

---------------------------------------------

Name newly created tracks automatically

This preference would come with a text field to specify the default track name with wildcards. Examples:

"Track $tracknumber" = Track 01
"$tracknumber" = 01
"Track" = Track
"" =
"$folders$tracknumber"= Brass02

The $tracknumber wildcard would be set when the track is created and NOT be updated when reordering. This would be how it works in most DAWs I know.

---------------------------------------------

Append current track index to track names

This preference would append the current track index to the track name, indipendent of the auto-naming preference described previously. Examples (same as before to be clear):

"Track $tracknumber" = Track 01 01
"$tracknumber" = 01 01
"Track" = Track 01
"" = 01
"$folders$tracknumber"= Brass02 02

Unlike the $tracknumber wildcard, the number added by this preference would update on reordering tracks to correspond to the current track index. So if a user wants his tracks be named like "Track 01" but with the number always corresponding to the track number he/she would not use "Track $tracknumber" but only "Track" and let this preference do the numbering instead.

As this preference can lead to confusion if the user is not aware of its existence, it should default to OFF.

---------------------------------------------

Name newly created MIDI items automatically

This preference would come with a text field to specify the default MIDI item name with wildcards. Examples:

"$track" = Track 01 ....(supposing this is the track name)
"$tracknumber" = 01
"" =
"Item" = Item
"untitled MIDI item"= untitled MIDI item

The name would be set when the item is created and not updated when the item is moved to a different track or the track renamed.

EDIT: This preference should be ON by default and probably default to $track. Whether turning it off leads to unnamed items, "untitled MIDI item", or any other logic the devs come up with is up for debate.

---------------------------------------------

Sync item names to track names

This preference would make sure that item names are always updated to follow track names. Note again: This applies ONLY if the user has not named the items and overrides the generic name.

An example to show how this is useful:

Let's say we have a track called "Horns" and add a MIDI item to it. If the preference "Name newly created MIDI items automatically" is on and the wildcard set to "$track", the item will be named "Horns", directly indicating the instrument which will play the MIDI, without having to check the TCP.
If we now move the item to a track called "Viola", without "Sync item names to track names" we would now have an item called "Brass" triggering a Viola sound. If we want to keep our project tidy we would have to pay attention to immediately rename the item correctly, something that many people in practice don't do. The preference to "Sync item names to track names" would do this housekeeping for us automatically while we can focus on creative tasks like trying out different orchestrations.

I would very happily use this preference as to me (not implying what others need) the only use an item name has is indicating what sound the item triggers and I couldn't care less how the first original track was called where the item originated from which might even no longer exist.

But of course this preference can also lead to unexpected changes and thus confusion for users not aware of its existence, so it should default to OFF.

---------------------------------------------

Let me know if any user demands can not be met by this set of preferences. It allows both to avoid or enforce unnamed tracks and/or items, flexible or rigid track index or no index at all, etc..

[Reflected]

oops