CrendKing / avisynth_filter

DirectShow filters that put AviSynth and VapourSynth into video playing
MIT License
108 stars 8 forks source link

GetInputSourcePath #80

Closed flossy83 closed 1 year ago

flossy83 commented 1 year ago

Could we please have a _env->AddFunction("GetInputSourcePath") so we can tell what video is playing so we can make our own per-file/folder scripting rules. i.e same as API_MSG_GET_INPUT_SOURCE_PATH but accessible inside avs script.

CrendKing commented 1 year ago

https://github.com/CrendKing/avisynth_filter/actions/runs/3434003298

flossy83 commented 1 year ago

Thanks a lot, much appreciated.

eg.

AvsFilterSource()

if (FindStr(AvsFilterGetSourcePath(), "Series\Comedy\(2001-2003) The Office") != 0){
    Subtitle("Now playing: The Office")
}
else if (FindStr(AvsFilterGetSourcePath(), "Series\Comedy\(2005-2007) Extras") != 0){
    Subtitle("Now playing: Extras")
}
else {
    AvsFilterDisconnect()
}

#FindStr() is case-sensitive
Nuihc88 commented 1 year ago

This is a very minor detail, but i think it would be better to have a more consistent naming scheme, like either: AvsFilterGetSourcePath() & VpsFilterGetSourcePath or AvsFilterSourcePath() & VpsFilterSourcePath Otherwise people who use both AviSynth & VapourSynth are going to be getting it wrong half the time.

CrendKing commented 1 year ago

Reason is, AviSynth is a function, VapourSynth is a variable. It doesn't make sense to have a verb in a variable name.

The AvsFilterSource API is slightly different, that I'm following the existing convention in the avs world (e.g. AviSource, DirectShowSource). Otherwise, I'd name it AvsFilterGetSourceClip().

Nuihc88 commented 1 year ago

Reason is, AviSynth is a function, VapourSynth is a variable. It doesn't make sense to have a verb in a variable name.

Fair enough.

The AvsFilterSource API is slightly different, that I'm following the existing convention in the avs world (e.g. AviSource, DirectShowSource). Otherwise, I'd name it AvsFilterGetSourceClip().

Not quite sure i get what you mean by existing convention here, but many AviSynth-functions i know of, have names that lack the verb entirely. (e.g. ScriptFile() VersionString() Time("%#d/%#m/%y") )

So based on the ScriptFile() example, AvsFilterSourceFile() & VpsFilterSourceFile would also be consistent with AVS convention as i understand it.

CrendKing commented 1 year ago

Time("%#d/%#m/%y")

So without reading document, will user be able to tell if this sets time or gets time in specified format? Will user know VersionString() gets version or sets version with default value?

There is a good reason most coding style guides recommend having verb + subject form as function name for clarity. Like I said, the only reason AvsFilterSource was such named is because many avs functions do not have verb in their names. I have no idea why such convention was set, but I personally dislike it and consider wrong.

Since AvsFilterGetSourcePath is a new API and I believe very few people will use it, I think it's better to just do it the correct way.

Nuihc88 commented 1 year ago

So without reading document, will user be able to tell if this sets time or gets time in specified format? Will user know VersionString() gets version or sets version with default value?

I think in the context of AviSynth-scripting, the purpose of 'GetString'-type functions can be inferred, since most 'SetString'-type functions never need to be accessed from the scripting-interface, but i get why it would be bad for a project that needs to set time or spoof version info.

There is a good reason most coding style guides recommend having verb + subject form as function name for clarity. Like I said, the only reason AvsFilterSource was such named is because many avs functions do not have verb in their names. I have no idea why such convention was set, but I personally dislike it and consider wrong.

I suspect it was done in part for the sake of brevity and in part to create more of a separation between backend-code and user-side-scripting, but i get now what you mean.

Since AvsFilterGetSourcePath is a new API and I believe very few people will use it, I think it's better to just do it the correct way.

Ok, fair enough.