Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

recognize the type of item, audio, midi, video #1066

Open
ranetto opened this issue May 7, 2024 · 18 comments
Open

recognize the type of item, audio, midi, video #1066

ranetto opened this issue May 7, 2024 · 18 comments
Labels
enhancement goodForNewDev This issue is a good candidate for someone new to contributing code to OSARA. p2 Medium priority.

Comments

@ranetto
Copy link

ranetto commented May 7, 2024

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
Copy link
Collaborator

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

@ScottChesworth ScottChesworth added enhancement p2 Medium priority. labels May 7, 2024
@jcsteh
Copy link
Owner

jcsteh commented May 7, 2024

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
Copy link
Collaborator

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

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

@jcsteh
Copy link
Owner

jcsteh commented May 7, 2024

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
Copy link
Contributor

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
Copy link

Lo-lo78 commented May 8, 2024

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
Copy link
Collaborator

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
Copy link
Owner

jcsteh commented May 8, 2024

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);

@jcsteh jcsteh added the goodForNewDev This issue is a good candidate for someone new to contributing code to OSARA. label May 8, 2024
@ranetto
Copy link
Author

ranetto commented May 8, 2024

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
Copy link
Author

ranetto commented May 8, 2024

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
Copy link
Author

ranetto commented May 8, 2024

don't hate me please!

@jcsteh
Copy link
Owner

jcsteh commented May 8, 2024

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
Copy link
Collaborator

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
Copy link
Owner

jcsteh commented May 8, 2024

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
Copy link
Collaborator

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
Copy link
Owner

jcsteh commented May 9, 2024

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
Copy link
Author

ranetto commented May 10, 2024

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
Copy link
Collaborator

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

day-garwood added a commit to day-garwood/osara that referenced this issue May 14, 2024
When navigating through items, the source type (audio, video, midi) is announced when reporting take information (see issue jcsteh#1066).
day-garwood added a commit to day-garwood/osara that referenced this issue May 14, 2024
When navigating through items, the source type (audio, video, midi) is announced when reporting take information (see issue jcsteh#1066).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement goodForNewDev This issue is a good candidate for someone new to contributing code to OSARA. p2 Medium priority.
Projects
None yet
Development

No branches or pull requests

5 participants