Judging by the ongoing thread about documenting filters, it seems to me
that (aside from lack of documentation) there are 3 basic problems with
the current method of setting up filters (more specifically, playback
filters):
(1) the "Deinterlace Playback" checkbox 'invisibly' puts linearblend at
the head of the filter chain. If you prefer kerneldeint, you have to
un-check "Deinterlace Playback" and manually specify kerneldeint in the
playback filter chain. This is rather counter-intuitive.
(2) The user is not presented with any options as to what the available
filters are; merely a text box for free-form text entry
(3) Related to (2) (which will be partially solved by the forthcoming
docs (thanks, Andrew)): it's rather difficult for folks using a remote
as their primary Myth input device to type in filter names (this same
issue applies to the visualizations in mythmusic)
I'd say it's high-time for a reasonable GUI interface for building
playback filter chains. I'd say at minimum what would be required
would be:
- self-discovery of available filters
- method for enabling/disabling any individual filter
- method for changing the order of filters in the chain
- (optionally) method for configuring filter-specific options (more
self-discovery)
A quick look at the above list suggests (to me) that some sort of plugin
architecture for filters is called for. A filter plugin could expose:
- name
- description/help text
- number & types of configuration options
The same sort of plugin architecture could be applied to any number of
things within Myth... music visualizations, mythgallery transitions,
mythmusic ripping containers & codecs... the list goes on.
Maybe what's called for is a more generic plugin system, where we would
have the concept of a plugin type. The main type of plugin that we
have now would be a MODULE plugin, then we'd have VIDEOFILTER,
MUSICVIS, GALLERYTRANSITION, etc. Any module or screen that was
interested in a certain type of plugin would simply scan the plugin
directory for plugins of that registered type. This might also open up
more possibilities of plugins not being restricted to their original
modules. For instance, the main menu system could use the transition
effects from MythGallery.
Anyway, I just thought I'd throw this idea out there and see if there's
any interest/thoughts/suggestions.
-JAC
that (aside from lack of documentation) there are 3 basic problems with
the current method of setting up filters (more specifically, playback
filters):
(1) the "Deinterlace Playback" checkbox 'invisibly' puts linearblend at
the head of the filter chain. If you prefer kerneldeint, you have to
un-check "Deinterlace Playback" and manually specify kerneldeint in the
playback filter chain. This is rather counter-intuitive.
(2) The user is not presented with any options as to what the available
filters are; merely a text box for free-form text entry
(3) Related to (2) (which will be partially solved by the forthcoming
docs (thanks, Andrew)): it's rather difficult for folks using a remote
as their primary Myth input device to type in filter names (this same
issue applies to the visualizations in mythmusic)
I'd say it's high-time for a reasonable GUI interface for building
playback filter chains. I'd say at minimum what would be required
would be:
- self-discovery of available filters
- method for enabling/disabling any individual filter
- method for changing the order of filters in the chain
- (optionally) method for configuring filter-specific options (more
self-discovery)
A quick look at the above list suggests (to me) that some sort of plugin
architecture for filters is called for. A filter plugin could expose:
- name
- description/help text
- number & types of configuration options
The same sort of plugin architecture could be applied to any number of
things within Myth... music visualizations, mythgallery transitions,
mythmusic ripping containers & codecs... the list goes on.
Maybe what's called for is a more generic plugin system, where we would
have the concept of a plugin type. The main type of plugin that we
have now would be a MODULE plugin, then we'd have VIDEOFILTER,
MUSICVIS, GALLERYTRANSITION, etc. Any module or screen that was
interested in a certain type of plugin would simply scan the plugin
directory for plugins of that registered type. This might also open up
more possibilities of plugins not being restricted to their original
modules. For instance, the main menu system could use the transition
effects from MythGallery.
Anyway, I just thought I'd throw this idea out there and see if there's
any interest/thoughts/suggestions.
-JAC