Old 07-24-2015, 01:33 AM   #1
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default Implement a way to discover plugin's technical info

When trying out new plugins, I constantly find myself wondering about two things, regardless of how the plugin sounds on the material:

1) Does this plugin oversample?
(or does it introduce aliasing into signal?)
2) At what bit depth does this plugin work internally?

I think these two things are too important to leave unknown. We all use plugins, basically they shape the sound of our work. So I figure many people would appreciate if some way got implemented to figure it out automatically, or if that's impossible then pull that data from a user-managed database.

Cheers!

Vote on the issue tracker:
http://forum.cockos.com/project.php?issueid=5633

Last edited by innuendo; 07-24-2015 at 02:45 AM.
innuendo is offline   Reply With Quote
Old 07-24-2015, 02:22 AM   #2
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,594
Default

There's absolutely no way for host to know about that kind of stuff. DSP implementation doesn't matter to the host.
EvilDragon is online now   Reply With Quote
Old 07-24-2015, 02:38 AM   #3
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Quote:
Originally Posted by EvilDragon View Post
There's absolutely no way for host to know about that kind of stuff. DSP implementation doesn't matter to the host.
If a third-party plugin can do it, why the host can't?
http://www.stillwellaudio.com/plugins/bitter/

There is no question that it is possible to tell at what bit depth a given plugin outputs the signal, and that is a very strong cue to guess about its internal processing.
Probably oversampling is trickier to guess, but people who do host dsp coding might come up with something clever. And in case that is indeed impossible as you say, a viable option would be fetching that info from user-generated database.
innuendo is offline   Reply With Quote
Old 07-24-2015, 02:54 AM   #4
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,594
Default

That's not the same thing! Internally, plugin can process stuff in whatever format internally (it can all be 64-bit floats, it can be 32-bit floats, whatever), different from the output audio format! Internal processing does not equal audio format that plugin outputs.

So, there's no way for ANYTHING really to know that for certain. Not the host, nor a different plugin.
EvilDragon is online now   Reply With Quote
Old 07-24-2015, 03:02 AM   #5
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Quote:
Originally Posted by EvilDragon View Post
That's not the same thing! Internally, plugin can process stuff in whatever format internally (it can all be 64-bit floats, it can be 32-bit floats, whatever), different from the output audio format! Internal processing does not equal audio format that plugin outputs.

So, there's no way for ANYTHING really to know that for certain. Not the host, nor a different plugin.
I think you misread what I wrote. I didn't say internal processing bit depth equals output bit depth. I said that the latter is a very strong cue to guess the former. Why would someone write a plugin that processed the signal in 64 bits and then truncated it let's say to 24 bit on the output?
innuendo is offline   Reply With Quote
Old 07-24-2015, 03:09 AM   #6
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,594
Default

Greater precision of calculation, obviously. In any case - that kind of stuff IS being done on a regular basis. When you see that the plugin has "full 64-bit internal processing", this doesn't relate to the plugin format being 64-bit, but actual internal processing, all variables used for calculation are 64-bit (floats usually). Doesn't matter what's used for the audio output of the plugin. And no, you cannot guess if they used oversampling via this.


In any case, personally I voted "no" for this, because save for the fact that it's damn near impossible to know this stuff, I also don't find it useful to know in any way. Just go with your ears. There are other more pressing matters that need developer attention as far as Reaper is concerned.

Last edited by EvilDragon; 07-24-2015 at 03:14 AM.
EvilDragon is online now   Reply With Quote
Old 07-24-2015, 03:17 AM   #7
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Quote:
Originally Posted by EvilDragon View Post
Greater precision, obviously. In any case - that kind of stuff IS being done on a regular basis. When you see that the plugin has "full 64-bit internal processing", this doesn't relate to the plugin format being 64-bit, but actual internal processing, all variables used for calculation are 64-bit (floats usually).
So if the plugin developer wants the user to have that greater precision, why would they output the signal with a lesser precision?

Can you be specific about what plugins actually do it?
To reiterate, I am certainly not a dsp developer (not counting some Max/MSP programming), so I might be completely wrong, however I would like to see some facts before I let go of common sense.
innuendo is offline   Reply With Quote
Old 07-24-2015, 03:19 AM   #8
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,594
Default

Same reason you'd oversample then downsample (that's also a signal with "less precision" after downsampling!). Except this time it's about precision of math operations executed on the signal, not about aliasing per se.
EvilDragon is online now   Reply With Quote
Old 07-24-2015, 05:15 AM   #9
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

Quote:
Originally Posted by EvilDragon View Post
Same reason you'd oversample then downsample (that's also a signal with "less precision" after downsampling!). Except this time it's about precision of math operations executed on the signal, not about aliasing per se.
AFAIK vst plugin has to output at sampling rate dictated by the host. Which does not apply to bit depth. If you have any verified information to share, please go ahead.

Otherwise in case this is impossible to implement, I'm sure the devs can mark it as so. The FR is about the idea, not the implementation. If you don't like it, you are most welcome to vote against, as you have already done.

Personally I think this kind of information is important to know. As important as knowing your microphone's polar response. Trust your ears but know your gear.

Last edited by innuendo; 07-24-2015 at 05:33 AM.
innuendo is offline   Reply With Quote
Old 07-24-2015, 05:26 AM   #10
innuendo
Human being with feelings
 
Join Date: Nov 2013
Location: Jerusalem, Israel
Posts: 659
Default

BTW technically I think it should be possible to test a plugin for aliasing since we can test it in isolation and because aliasing has a very specific pattern. Input a series of sine waves at arbitrary high frequencies, measure the output, analyze the result.

Last edited by innuendo; 07-24-2015 at 06:00 AM.
innuendo is offline   Reply With Quote
Old 08-15-2015, 09:47 PM   #11
ad
Human being with feelings
 
Join Date: May 2011
Posts: 83
Default

That doesn't make any sense. You can produce exactly the same result as aliasing using sum+difference for example and there is absolutely no way for the host to get the information you say you need.

(In fact you can produce identical spectra in a large number of ways. There exists no practical means to identify partials making up an aliased signal as such.)

If you feel you need this information, can you justify it?

What reason do you need this?

It should require someone with significant skill to make measurements and learn anything in such a situation.

The fact you overlooked that your argument is flawed due to a property which should be common knowledge demonstrates you lack such skill.

What makes you think lacking this sort of skill that you can make any valid argument to support your assertion that such a feature is needed or even possible?

If the plugin you linked claims to do this, why not purchase that plugin and use it?

Assuming it is technically feasible to implement this and have it work reliably, can you demonstrate exactly how that would be accomplished?

Lastly, why did you post this to FR after EvilDragon clearly explained why it isn't practical and before you bothered to argue he was wrong?

Just because you "think" this information is important to know does not mean it is important for others, practical to implement or even possible.
ad is offline   Reply With Quote
Old 08-15-2015, 09:54 PM   #12
ad
Human being with feelings
 
Join Date: May 2011
Posts: 83
Default

A very, very simple proof I think you will understand:

It is impossible to identify aliased partials. No means exists by which you can remove such partials from a signal once present.

If you could identify aliased partials you could remove them with a filter.

Q.E.D.
ad is offline   Reply With Quote
Old 08-15-2015, 10:12 PM   #13
ad
Human being with feelings
 
Join Date: May 2011
Posts: 83
Default

I'll also try to be more helpful.

What you need to do is find something that already does this. Test it, demonstrate it.

Then your request becomes that REAPER should implement something that is actually possible. We know it is possible, you can prove it by demonstrating the tool that performs this.

I think a time machine should be possible because there is no reason it shouldn't be. I think we all agree it would be useful to everyone, for example you could go back in time and convince yourself to reconsider this FR.

That doesn't mean REAPER should implement time travel or that it would be a valid FR to post.
ad is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 02:54 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.