Off Topic: Metadata Plugin? (Rail, Massey, anyone)

[froyo]

Hello. OK so we have all seen this before. We open up a Pro Tools session from another system and they used plug ins our system does not have. When you click on the plug in all you get is a small window that tells you it is inactive. So this thread is a shout out to all those who are familiar with software coding and programming.

How difficult would it be to create a 'metadata' plug in, so to speak, that would strictly display parameters? No audio would pass through it, it is strictly a data plug in. So for example Session A is started in Studio X and it uses Sony Oxford EQ's. The session then moves to Studio Y that does not have the Sony Oxford EQ's installed. When the session opens up the engineer does not know what the EQ was used for. A good engineer would have session notes or computer screenshots of the plug ins to explain what happened but we know that this does not always happen.

The engineer in Studio Y does not need for the plug in to become active and be bypassed, he just needs to know what the EQ was doing. So all this metadata plug in would do is open up a display that would show that 82 Hz were rolled off on a High Pass by 10 dB on a 24 dB slope, that 2.5 Khz were boosted by 3 dB on a shelf with a wide Q, etc. Now we all know that different EQ manufacturers (software coders in this instance) handle parameters differently. Some rolloffs are different in the High Pass or Low Pass filters, the shelves can be different and the Q's can definitely be different. So nothing would be exact.

But the purpose of the plug ins is to serve as session notes. Just to give the other engineer a starting place. He can then instantiate a plug in to get similar results. It will never be the same because the original plug in is not available, but it will be very, very close in most cases. And the same goes for just about any other plug in. Compression, delay, reverb, etc. There are some wacky plugs in like GRM that have some crazy parameters and fucntions that would be hard to duplicate with other plug ins. But I think 99% of the time the use for this metadata plug in would be for EQ, compression, delay and reverb.

I know that OMF and AAF already do this to an extent. They take the audio in one session from one software and allow it to be opened in another software. Sometimes some parameters come along like volume automation, panning, etc. Other stuff like plug ins of course does not.

How difficult would it be for something like this to exist? Is it a massive endeavor or is it somewhat more simple? I included Rail and Steven Massey in the title thread because they write code and create software, but anyone who knows is obviously welcomed to comment. Digidesign of course is always welcomed to comment.

Think about how useful this would be? And with the added benefit that this would also extend along to other software. Say the session was created in Logic with Waves plug ins. An OMF or AAF is created and the audio regions pop up. Along with them data only, no audio, metadata plug ins that strictly show what the parameters were used for. This session could now be opened in Sonar for example or Ableton Live on a PC with no Waves installed.

Any and all comments welcome. Thank you.

[25ghosts]

This is truly a grand idea -

[Rail Jon Rogut]

It's a huge task.. I actually wrote something like this for another DAW system -- I had to figure out the data structure for every plug-in... since then the number of plug-ins has multiplied exponentially. On top of this the Pro Tools session files are encrypted.. so it's impossible to reverse engineer (at least for me).

Rail

[froyo]

Hello. Thank you Rail for chiming in. It's sad to see that it would be a problem. Let's approach this from another angle. Instead of you having to figure out the data structure to be able to get the information, what if all the plug in developers created a 'session notes' or 'metadata' section, chunk or whatever software coding it refers to here that would pass the information to this plug in. In other words, instead of me having to call 20 people to invite them and make sure they were coming to my party, having all 20 people call me to confirm. That's 20 different people making one call as opposed to one person making 20 calls.

The analogy here would be instead of you having to do all the work you describe, the developers sort of do the work for you and this plug in just receives the info. If that's possible at all. I realize this means more work for the plug in developers, but maybe in their case it would be a simple minor adjustment.

It also occurs to me that plug in developers would earn major, major, major props if they facilitated this sort of thing. In other words if plug in developers would help make things easy (or easier) for whoever would create this plug in, for example Rail, they would earn major brownie points from every user worldwide.

The other path to consider is does AAF (or OMF) have any room to add this sort of metadata to include plug ins used in audio tracks? That of course would be a question for those responsible for AAF like Digidesign and Avid amongst others. Is that possible, or is that also a massive undertaking?

If it's possible could you give us a layman's explanation of what needs to happen in order for this to exist? Thank you.

[jamiecer]

"what if all the plug in developers created a 'session notes' or 'metadata' section, chunk or whatever software coding it refers to here that would pass the information to this plug in"

Absolutely Brilliant!

[Andre Knecht]

Hi Rick,

while the issue is real, and your idea for a solution is a good one (as well as being “noble”) I suspect that it won’t find wide-spread acceptance among plug-in developers. I am not referring to programming issues (not qualified by a long shot), but, rather, those of practicality and marketing strategies.

From a practical standpoint, I imagine that describing EQ and compressor functionality by way of listing a handful of parameters isn’t all that complicated. But what about complex plug-ins such as a SoundToys Time/Pitch Blender, or an Eventide H3000 Factory, etc. And these all run on TDM chips, which “limits” the amount of functionality a developer can include in the plug. RTAS plugs, which aren’t limited in that way, open the door to even more complexity. (Native Instruments “Reaktor” comes to mind.)

Another practical hurdle which would need addressing is the mapping of parameter automation, complicating even the “simple” examples above (i.e. EQ and dynamics).

Last, and most importantly, I suspect that few developers will see much value in allocating resources to an effort which — in essence — negates the need for ownership of their own products.

But yes, it would be helpful.

[RobMacki]

Last, and most importantly, I suspect that few developers will see much value in allocating resources to an effort which — in essence — negates the need for ownership of their own products.

But yes, it would be helpful.

Excellent point Andre.

Maybe Digi will see the benefit in users having at least something like a "Save Screen Shots of All Plug-Ins" command upon closing. At least that way a user could still call up the screen shot to see the treatment of a given plug-in.
I could have used that feature last week at another studio.

[froyo]

Hello. I disagree that this would negate the need for ownership of the plug in. Remember this is for cases where the plug is not in the system and will not be in the system. We have all dealt with many, many, many sessions where plug ins opened up inactive and we had to replace that plug in with another one on our system. In other words I have never been part of a session where, let's say for example, a Waves Req6 opened up inactive which forced me or anybody to buy it. It was simply replaced by whatever Eq was available in the system. The only thing that would happen here is that another plug in would open up showing what parameters were used.

Again I have never, ever, ever, never bought a plug in strictly because it opened up inactive on a session. I don't know anyone who has. Maybe I am wrong about this, but I dare say very, very few people buy plug ins in this specific scenario.

All we want is the metadata, what parameters where used, so that we can approximate them with what we have.

It also occurs to me that this could also happen within what's already available in Pro Tools systems. You know when you take a TDM session with 70 tracks to an LE system the 70 tracks will open up, you will be able to see the regions, the region edits, the fades, the region names, etc. The extra 38 tracks will just be inactive. Basically we just need the equivalent. Have the plug in GUI open up and just be inactive. Or have the inactive plug in create a generic plug in that just describes the parameters. This could be the Dragnet plug in, just the facts ma'am.

All we need is the information though. Forget a plug in. It could even be a text file. EQ--> High Pass Filter -12dB @ 24 rolloff, Compressor--> Threshold -14 dB, Ratio 4:1, etc. Again, this could be some addition to AAF. Either as a text file or as a simple GUI plug in that pops up and passes no audio at all, it just graphically represents the parameters used.

The 'Export Session As Text' already does this in a sense. Whenever, a session would open up and see an inactive plug in it would generate this 'Metadata' plug in. It already does this ahead of time when it opens up that window that tells you what plug ins will open up inactive. All that needs to happens is for the information to pop up. Either under the actual GUI from the plug in itself, as a generic plug in GUI or even as a text file.

As I said before there are many plug ins that are so specific the parameters would be difficult to even describe. But as I also mentioned, EQ, compression, delay and reverb all use the same parameters and these are the ones that most people use on their session and the ones most users would benefit from 98% of the time.

I hope some of the other software coders will pop in. Maybe Digidesign will pop in and comment.

By the way I like Rob's idea. Digidesign already creates a Wave Cache file which stores all the waveform graphics associated with a session. Now this command could be 'Export Session Inserts as Jpegs' This would create a jpeg for each insert on the session. That's all we need. To see what parameters were used so that we can approximate those with our plug ins. That's it.

[Jimmix]

Hello All

Great idea and very needed.

What about automated parameters?
I think it could be a lot simpler than Jpegs and text files though they would both be nice to have.
The user with the off line plug-in should still be able to see the parameters and values in the automation view.....just like a volume curve. I think it would be simple for Digi to add this and it would take care of automated moves as well. I don't know if it is an issue where the session is unaware of what paramenters are even avaiable but I would think the session would know if all the paramenter were declaired available for automation.

just my thought

Jim

[froyo]

Hello. What about this idea? Digidesign sells you the Metadata Plug In Bundle or the Plug In Metadata Toolkit, say for $100. When someone buys and installs this toolkit on their system, and they open a session which includes a plug in not installed on the system, the plug in GUI will open yet be inactive. It will not pass audio, but the plug in window will open to reveal the parameters. The price the consumer pays for this bundle will cover Digidesign's and the developer's efforts. How does that sound?