11-05-2021, 04:55 PM | #1 |
Human being with feelings
Join Date: Dec 2012
Posts: 7,272
|
Why is video processor so different?
Specifically, why is it different from JS plugins. I'm willing to accept that they do in fact need to work differently on the back end, so that they're not exactly interchangeable and we have to do some weird things with gmem to get information back and forth. If somebody wanted to explain why that actually is, I'd be happy to hear it, but that's not really my question. My question is more in how we create and implement the things.
First, like, why is it that we have this one plugin called Video Processor that actually does nothing by itself, and all the code to do whatever we want to do is included in presets for that one plugin? In JS, each of these "presets" would be its own plugin, for which we could have any number of actual presets for different values of parameters. Why do the parameters allow us to define defaults if their actual values are saved with the "preset" which should actually be its own plugin? As it is now, if we want easy access to the same code but different starting values for specific different tasks, we either end up with a whole bunch of presets in the list, many of which are identical except for parameter values, which is just ugly and will become pretty tough to navigate before too long. The alternative being to actually save it as an FX chain, but that's a bit of a different thing, too. It's clunky and inconsistent with the behavior of just about everything else we do. But then, too, the sort of half-assed knobby things that we get for a GUI are pretty wonky and unfriendly and just weird. The window for the FX itself is mostly code, and we have to be careful about parameter names and descriptions and things because you can only actually see so many characters. Want something like a dropdown with multiple options? Yeah... Want to be able to type in specific values? Sorry. Even if it was the basic GUI like we have in JS, with sliders and dropdowns and the code hidden behind an Edit button, it would be sooooo much better. If there was a way that we could create "real" GUIs like we do in JS, that would be even better, but I guess I can see where there might be some collision in the gfx processing or something. There is actually nothing stopping us from just making a dummy JS as a front end and then either coopting the multichannel video peaker or just using gmem to control parameters in the video processor itself, but that's a bit of a hinkey hack. We might, also, be able to program the VP preset itself to give us at least some feedback in the video window, but can that be used to capture mouse and/or keyboard inputs? Really, that's just kind of a weird way to do it anyway, but it would be better than nothing. So yeah, why is this so different? Is there anything we can do to make it better and preferably more consistent with our other plugin experiences? Does any of this bug anybody else as much as it bugs me, or have people found ways around the limitations that I haven't yet found?
__________________
Lorenzo's Tractor is Everywhere --- Ash's Tube --- Join the Partnership for a Drum Free Amerika Last edited by ashcat_lt; 11-05-2021 at 05:00 PM. |
11-06-2021, 06:02 AM | #2 | |
Human being with feelings
Join Date: Aug 2020
Location: Brasil
Posts: 679
|
Your observations on the video processor are pertinent: numerous times have I struggled with its limitations (and poor documentation)! I am speculating that since Reaper is a DAW (and a very good one) that keeps evolving over 6 majors versions without being a mess, the developers must have designed from the start an excellent data/programmatic model for audio processing. I am presuming that this model does not apply well to video processing so they quickly "grafted" this "video processor FX" that contains all the video processing abilities and moved the coding in a giant "text field". BTW video and audio are 2 very different animals: audio has very a limited number of channels (less than 100 typically 2,4,6) with a very high temporal resolution (sampling rate ex. 48khz, 96khz) and video on the contrary has massive number of channels (millions of pixels!) with low temporal resolution (24hz to 120Hz = frame rate).
Quote:
I hope they eventually come up with more elegant solution for video in v7... |
|
11-06-2021, 08:21 AM | #3 |
Human being with feelings
Join Date: Jul 2009
Posts: 7,570
|
I would also like an improved video processor.
- saving the code as a new plugin - code hidden behind edit button - UI that has fast and slow knob movement and numeric entry - knob/slider/toggle/dropdown UI elements
__________________
REAPER Video Tutorials, Tips & Tricks and more at The REAPER Blog
|
11-06-2021, 09:25 AM | #4 | |
Human being with feelings
Join Date: Aug 2020
Location: Brasil
Posts: 679
|
Quote:
And also a better base model of which video layer gets the priority and what scope a video presets apply to (eg. cumulative track, current item, current fx chain). Having coded several video transforms, there is always a confusing choice about what the transformation should fx apply to. On more than one occasion I had to combine 2 presets in one to make sure it applies to the right video layer. So my additions to that list: - Video preset scope control Last edited by papagirafe; 11-06-2021 at 09:37 AM. |
|
11-06-2021, 09:37 AM | #5 |
Human being with feelings
Join Date: Dec 2012
Posts: 7,272
|
papagiraffe- I do appreciate what you’re saying. That part of things is not super intuitive. I kind of feel like it’s getting a bit beyond the scope of my post here. To an extent, you’re starting to talk about some fundamental changes to the engine itself. What I’m talking about is more kind of just cosmetics, or at least I’m hoping that’s true and therefor it might be a bit easier to get implemented.
Also, I think there are ways to do what you’re looking for here via careful project layout and some thoughtful coding. Again not always intuitive, easy, or friendly, but mostly doable without actually rebuilding the engine.
__________________
Lorenzo's Tractor is Everywhere --- Ash's Tube --- Join the Partnership for a Drum Free Amerika |
11-06-2021, 09:42 AM | #6 | |
Human being with feelings
Join Date: Aug 2020
Location: Brasil
Posts: 679
|
Quote:
|
|
11-06-2021, 09:54 AM | #7 |
Human being with feelings
Join Date: Dec 2012
Posts: 7,272
|
Oh I understand. Kind of intrigued how you intend to use gmem for that, so let us know when you get it happening. For most of what I do, I end up with a track of just some solid color (usually black or green) between all my actual tracks so that things have a harder time “leaking” through.
__________________
Lorenzo's Tractor is Everywhere --- Ash's Tube --- Join the Partnership for a Drum Free Amerika |
11-06-2021, 11:16 AM | #8 | |
Human being with feelings
Join Date: Aug 2020
Location: Brasil
Posts: 679
|
Quote:
Code:
// test fill_rect several times on the same spot //@param1:bg 'bg?' 0 0 1 0.5 1 bg?(bg=input_info(0);gfx_blit(bg)):(gfx_set(0,0,0,1,0,-1);gfx_fillrect(0,0,project_w, project_h)); gfx_set(1,1,1,0.1,0x10000,-1); maxi=18; offy=200; i=0; loop(maxi, gfx_fillrect(i*100,offy,maxi*100-i*100,400); i+=1;); gfx_set(0,0,0,0.1,0x10000,-1); i=0; loop(maxi, gfx_fillrect(i*100,offy+200,maxi*100-i*100,400); i+=1;); |
|
Thread Tools | |
Display Modes | |
|
|