recognize the type of item, audio, midi, video

[ranetto]

Hi everyone, I don't know if this problem has already been dealt with, it frequently happens to me that I don't recognize a type of item at all, as a reaper, I often call frizzy items which are actually audio midi freeze. To recognize them, I try to open them with the midi editor, if they don't open they will be audio, then with control f2 I try to see their properties and if it gives me the properties of a wave file, then it means that I am in the presence of an audio item. Would it be possible to make sure that when I select an item after the name and everything that is announced it could tell us if it is an audio item, a midi item, or a video item? Furthermore, this would also be more consistent with the behavior of the automation items which are actually announced as such.

[ScottChesworth]

I don't know whether this is possible, can imagine it being useful information to hear though. Nice idea.

[jcsteh]

Where do you imagine this would get reported in the item info? I'm concerned this would make that report longer, taking more time to get to info users might want quickly.

I'm not certain, but this can probably be done by:

1. Getting the take.
2. Getting its PCM_source by calling GetSetMediaItemTakeInfo with P_SOURCE.
3. Calling GetType() on the PCM_source.

There are open questions though:

1. GetType() can return WAV, MIDI, etc. However, I suspect it will return something different if, for example, the source is an MP3. We don't want to have to learn about all those cases separately.
2. Maybe we could call GetSampleRate() on the PCM_source instead. That should return 0.0 for MIDI.
3. I have no idea at all what happens with video items. I still don't really understand how video items work in REAPER. Are they separate from the audio or is the audio and video combined? If combined, I don't think we can detect them this way.

[ScottChesworth]

Where do you imagine this would get reported in the item info?

After dynamic things like mute/group/lock, before take name.

[jcsteh]

Is it okay to hear "WAVE", "MP3", etc. or must it be "audio"? Note that the former would not be translatable. But also: what do sighted users see here; e.g. for a wav item vs an mp3 item? Do they look any different?

[jennykbrennan]

Been pondering this one. For me who use primarily audio, and work with huge numbers of items, I'm not sure. I agree, this would be a good idea. But after experimenting a bit it gives me pause.
As I understand it, the report would be something like
7 wav Chorus-45.wav 6 takes bar 87 beat 2 86%
Maybe the difference is tiny, It goes from verbose to a tiny bit more verbose, It would annoy me. Especially since the item name already includes the .wav.
And in classic solipsistic manner, me working with primarily audio, I'd be happier to have midi and/or Video items tell me what they are as then I know all the rest is audio.
And those who work mostly in midi would voice the very opposite argument.

But it's all I've got guys. I'm not so sure about this.

I just got thinking there is probably already a way to customize how item names are displayed and that it's something I should know, silly me.
so this might be a pointless objection.
Reassure me or ignore me. I don't have any alternative suggestions.

Been a long week. :) :

[Lo-lo78]

Why not think of a modular choice?
With an action you could also add the type of item to the classic message for an item.
A simple toggle.
In this way, problems of verbosity do not arise if there is no need to know which items are used in the project.
For this reason I would have separated the transport state from the action:
"OSARA: Report edit/play cursor position and transport state".
I don't know if OSARA can actually intervene by adding other information to messages that can be bypassed if it is not needed.
It could be done like when we activate:
"Report FX when moving to tracks/takes"
It does not clear the track number and name message and more information is added.
The translation seems a little crazy. :)
We hope that the gist of the speech was understood.

[ScottChesworth]

I can see how it makes sense for this to be optional, it would be useful to people who often work with mixed content, probably unnecessary otherwise. We already have some stuff in Config shaping reports as we navigate tracks and items, IMO this is comparable to those.

[jcsteh]

Here's the work in progress patch for this that just reports the source type (WAVE, MP3, etc., not just audio). I'm not super keen to put time into making this a config setting, but I guess I don't have any objective argument against it, so I won't fight it if someone wants to do it.

Patch

diff --git a/src/reaper_osara.cpp b/src/reaper_osara.cpp
index 3000e9a..5936b6a 100644
--- a/src/reaper_osara.cpp
+++ b/src/reaper_osara.cpp
@@ -3234,6 +3234,10 @@ void moveToItem(int direction, bool clearSelection=true, bool select=true) {
 		}
 		MediaItem_Take* take = GetActiveTake(item);
 		if (take) {
+			if (auto* source = (PCM_source*)GetSetMediaItemTakeInfo(take, "P_SOURCE",
+					nullptr)) {
+				s << " " << source->GetType();
+			}
 			s << " " << GetTakeName(take);
 		}
 		int takeCount = CountTakes(item);

[ranetto]

I would say that audio or midi or video would be enough, sighted people see a waveform for audio, they see a key for midi, and clearly they see a screen for video. I think it would be useful for everyone, because when the synths freeze they don't always put the name of the audio file but they put frozen midi and so you don't understand what it is unless you make other moves. Certainly if you don't see the synth inserted into the track, you would understand that it is not midi or realtime, but when you send to a synth track from a midi track it is much more difficult to understand. I also say that in some situations it is possible to record two elements of different types, audio or midi, on one track and therefore this would simply speed up the work. I don't think it's useful to specify which audio or midi format we're talking about, as you can check this if you're interested from the properties of the element itself, but only the type. I'll give another example to support my thesis: for example you are recording the output of a synth, it would be useful to know if that synth gave you its audio as output and therefore you created an audio item or its midi as an example a sequence of notes from one of his arpeggios. This is just another example that tries to support my thesis. Thank you.

[ranetto]

I believe that the information should be listened to last, so after everything else, I also say that regarding the translation, audo or midi, I believe they are terms used in all languages, in Italian, my language, I say audio or midi as you say in English and I think it's the same for everyone, they are terms that don't have a translation but the generic English and American ones are used in all languages. As regards the video items, they are treated by reaper like the audio ones, but their properties with control f2, say video properties, or the non-wave, non-flac, non-mp3, non-caf, in short non-audio format, make it clear that they are an item video. This is a summary of what it gives in the properties, in case some API can give it to examine it: Video: [email protected], Aspect=1.00, Decoding format=I420/YV12
Audio: 48000Hz 2ch 16bps

Using Windows Media Foundation v2 decoder for video and audio

Encoded video format: H264
Encoded audio format: AAC

Metadata:
Frame height: 1080
Channels: 2
Video compression: {34363248-0000-0010-8000-00AA00389B71}
Audio sample size: 24
Duration: 7077120000
Media created: 2022/04/15:10:06:12.000
Audio Format: {00001610-0000-0010-8000-00AA00389B71}
Audio sampling rate: 48000
Frame rate: 59940
Frame width: 1920
Video orientation: 0
Protected: 0
Spherical: 0
Stereo: 0
Data rate: 44983696
Bit rate: 189200
Overall bit rate: 45172896
Thank you!.

[ranetto]

don't hate me please!

[jcsteh]

Okay. Reporting just "audio" instead of "WAVE", "MP3", etc. will require additional code for whoever works on this. There's no way to get that information directly, so we'll need to do one of two things, unless there's a way I'm missing:

1. Compare the PCM source type string. MIDI always seems to be "MIDI", the one video file I tried was "VIDEO", but audio could be "MP3", "WAVE", etc. I guess audio can be the exceptional case, unless we discover other MIDI or video source types.
2. Check the sample rate of the PCM source. For MIDI, this will always be 0. Unfortunately, for video, the sample rate is the audio sample rate, so video can't be distinguished that way. We'd need to use the source type to distinguish video.

[ScottChesworth]

Seems like the conditionals for this get simpler if we only report MIDI and video, essentially treating audio as the default. Given that audio items have the file extension included in their names by default, arguably that's extraneous verbeage anyway. Thoughts?

[jcsteh]

If we're going down that path, I think video gets the extension included as well, so is it really just MIDI we need to report?

[ScottChesworth]

Experimenting with REAPER 7.15, MIDI takes get named track number, virtual instrument Dash MIDI by default. So, do we need to do any of this? Seems default naming for MIDI takes has been improved since I last examined them.

[jcsteh]

What about frozen items, audio or MIDI? Though I'm curious as to how a frozen MIDI item looks visually anyway, since it's effectively an audio item with special state.

[ranetto]

it actually looks like a wave, but one of the parameters to identify it could be: Originator: REAPER: this is what reaper says in the properties.

[ScottChesworth]

we couldn't use that to identify, it's a BWF tag that won't always get written, depends on local settings.