libvisual-devel

[Libvisual-devel] VisParamContainer question

[Burkhard P. <pl...@ip...>]

Hi,

after a complete rewrite of the Gmerlin visualizer, I'm now able to render
all libvisual plugins I tried. Everything works perfectly up to now.

Now I want to support parameters: As far as I understand, I get a
VisParamContainer from a plugin, which describes all parameters a plugin
accepts. But how can I get a list of all parameters (name, type, limits)?

There is a function visual_param_container_get(), which returns
a VisParamEntry (which is probably what I need), but for that, I need
to know the name. What I miss is something like:

int visual_param_container_get_num(VisParamContainer *paramcontainer);
VisParamEntry * visual_param_container_get_nth(VisParamContainer *paramcontainer, int);

What's the official way to query all supported parameters from a plugin?

Burkhard

Re: [Libvisual-devel] VisParamContainer question

[Dennis S. <den...@gm...>]

Hello!

I am very delighted to see that you are rendering libvisual within the
Gmerlin visualizer, super cool stuff!

Parameters:
There is no nth parameter function because parameters are entered in a
hashmap by their name. You can iterate this hashmap tho!

visual_collection_foreach_do (VISUAL_COLLECTION(&paramcontainer->entries),
VisHashmapChainEntry *entry)
{
 char *name = entry->key.key.string;
 VisParamEntry *paramEntry = VISUAL_PARAMENTRY(entry->data);
} visual_collection_foreach_end;

I have to admit that I didn't test this, and also won't deny that this
should have been much easier.

Another (half completed) feature is the VisUI stuff that plugins can expose
which is an abstract representation of the configuration UI.

you can access the VisUI by calling: VisUIWidget *widget =
visual_plugin_get_userinterface (visual_actor_get_plugin (actor));

There is a not finished gtk driver for this in CVS, lvwidgets package.

Good luck! and if you have more questions please go ahead!

Cheers,
Dennis


On 10/31/07, Burkhard Plaum <pl...@ip...> wrote:
>
> Hi,
>
> after a complete rewrite of the Gmerlin visualizer, I'm now able to render
> all libvisual plugins I tried. Everything works perfectly up to now.
>
> Now I want to support parameters: As far as I understand, I get a
> VisParamContainer from a plugin, which describes all parameters a plugin
> accepts. But how can I get a list of all parameters (name, type, limits)?
>
> There is a function visual_param_container_get(), which returns
> a VisParamEntry (which is probably what I need), but for that, I need
> to know the name. What I miss is something like:
>
> int visual_param_container_get_num(VisParamContainer *paramcontainer);
> VisParamEntry * visual_param_container_get_nth(VisParamContainer
> *paramcontainer, int);
>
> What's the official way to query all supported parameters from a plugin?
>
> Burkhard
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Libvisual-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libvisual-devel
>

Re: [Libvisual-devel] VisParamContainer question

[Burkhard P. <pl...@ip...>]

Hi,

Dennis Smit schrieb:
> Parameters:
> There is no nth parameter function because parameters are entered in a 
> hashmap by their name. You can iterate this hashmap tho!
> 
> visual_collection_foreach_do 
> (VISUAL_COLLECTION(&paramcontainer->entries), VisHashmapChainEntry *entry)
> {
>  char *name = entry->key.key.string;
>  VisParamEntry *paramEntry = VISUAL_PARAMENTRY(entry->data);
> } visual_collection_foreach_end;

That's not for 0.4.0, only for CVS, right? Depending on non-released libs is
not good. Any alternative, which works with 0.4.0? Maybe with
visual_collection_get_iter()/visual_collection_iter_next()?

> I have to admit that I didn't test this, and also won't deny that this 
> should have been much easier.

Indeed :)

> Another (half completed) feature is the VisUI stuff that plugins can 
> expose which is an abstract representation of the configuration UI.

I need to convert the parameter descriptions to gmerlins own format,
which can then be used for saving values in the registry, building GUI
dialogs or passing options on the commandline. Gmerlin plugins never
assume a GUI to be present, they just tell what parameters they have.

Foreign plugins (ladspa or libvisual), get a small wrapper, which lets
them behave exactly as native plugins.

Burkhard

Re: [Libvisual-devel] VisParamContainer question

[Dennis S. <den...@gm...>]

On 10/31/07, Burkhard Plaum <pl...@ip...> wrote:
>
> Hi,
>
> Dennis Smit schrieb:
> > Parameters:
> > There is no nth parameter function because parameters are entered in a
> > hashmap by their name. You can iterate this hashmap tho!
> >
> > visual_collection_foreach_do
> > (VISUAL_COLLECTION(&paramcontainer->entries), VisHashmapChainEntry
> *entry)
> > {
> >  char *name = entry->key.key.string;
> >  VisParamEntry *paramEntry = VISUAL_PARAMENTRY(entry->data);
> > } visual_collection_foreach_end;
>
> That's not for 0.4.0, only for CVS, right? Depending on non-released libs
> is
> not good. Any alternative, which works with 0.4.0? Maybe with
> visual_collection_get_iter()/visual_collection_iter_next()?


You are completely right!!! my mistake.

the example I posted was using macros for:

VisCollectionIterator iter;
visual_collection_get_iterator (&iter, collection);
while (visual_collection_iterator_has_more (&iter)) {
 VisHashmapChainEntry *entry = visual_collection_iterator_get_data (&iter);
 visual_collection_iterator_next (&iter);
 }
 visual_object_unref (VISUAL_OBJECT (&iter));
}


> I have to admit that I didn't test this, and also won't deny that this
> > should have been much easier.
>
> Indeed :)
>
> > Another (half completed) feature is the VisUI stuff that plugins can
> > expose which is an abstract representation of the configuration UI.
>
> I need to convert the parameter descriptions to gmerlins own format,
> which can then be used for saving values in the registry, building GUI
> dialogs or passing options on the commandline. Gmerlin plugins never
> assume a GUI to be present, they just tell what parameters they have.


The same goes for libvisual actually, however there is a system to describe
the potential gui, that is all ;)

Foreign plugins (ladspa or libvisual), get a small wrapper, which lets
> them behave exactly as native plugins.


Sounds good!

Re: [Libvisual-devel] VisParamContainer question

[Burkhard P. <pl...@ip...>]

Hi,

Dennis Smit schrieb:

> You are completely right!!! my mistake.
> 
> the example I posted was using macros for:
> 
> VisCollectionIterator iter;
> visual_collection_get_iterator (&iter, collection);
> while (visual_collection_iterator_has_more (&iter)) {
>  VisHashmapChainEntry *entry = visual_collection_iterator_get_data (&iter);
>  visual_collection_iterator_next (&iter);
>  }
>  visual_object_unref (VISUAL_OBJECT (&iter));
> }
>  

That didn't work either, but I succeeded with

VisParamContainer * params;
int num_parameters;
VisListEntry * list_entry;
VisParamEntry *param_entry;

list_entry = (VisListEntry*)0;

params = visual_plugin_get_params(visual_actor_get_plugin(actor));
while(visual_list_next(&params->entries, &list_entry))
   num_parameters++;

/* ... */

list_entry = (VisListEntry*)0;

for(i = 0; i < num_parameters; i++)
    {
    visual_list_next(&params->entries, &list_entry);
    param_entry = list_entry->data;

    /* ... */
    }

Also I parse the VisUIWidget to get more informations, like limits for
numeric parameters.

One thing could be improved I think: Currently the VisUIWidget adds labels
in addition to the mutators. This makes it difficult to get the label text
corresponding to a mutator without parsing the whole layout of the dialog
(or implemeting a VisUI backend, which is impossible in gmerlin).
If label was a member of VisParamEntry, things would become much simpler.

In fact, gmerlins native parameter definitions are like a mixture of
VisParamEntry and VisUIWidget. The advantage is, that you have all informations
(label, tooltips, ranges, default values etc.) in one statically defined struct.
The disadvantage is that plugin programmers have no control over the actual layout
of the dialog, except the order.

Now the good news: My libvisual wrapper works perfectly now with the
following features:

- All parameter types (using VisParamEntry and VisUIWidget) except
   VISUAL_PARAM_ENTRY_TYPE_PALETTE and VISUAL_PARAM_ENTRY_TYPE_OBJECT
- Mouse, Keyboard and resize events
- Full OpenGL support
- Non-OpenGL plugins render using gmerlins native methods (this means
   in most cases XVideo or OpenGL hardware scaling). A pretty decent software
   scaler is used, if neither OpenGL nor XVideo are present.
- Embeddable into foreign windows using the XEMBED protocol
- Visualizations are run in a slave process, so plugins can link to
   arbitrarily broken libraries, leak memory and crash as much as they want :)
   Communication with the slave process is done via a bidirectional pipe.
- Tested with all plugins from libvisual-plugins-0.4.0 (except Gdkpixbuf) as
   well as ProjectM. No crash observed until now.
- Uses gmerlins method of scanning plugin directories and checking only the
   modules, which have a changed file timestamp (to save startup time).
   The actual dlopen()ing is done by libvisual.

The wrapper code is here:

http://gmerlin.cvs.sourceforge.net/gmerlin/gmerlin/lib/bglv.c?view=markup
http://gmerlin.cvs.sourceforge.net/gmerlin/gmerlin/include/bglv.h?view=markup

The gmerlin-visualizer is also in good shape.

I'll now finish my libvisual port of lemuria. When I'm done, I'll give you some
CVS links, for those who want to try all this.

Burkhard

Re: [Libvisual-devel] VisParamContainer question

[Dennis S. <den...@gm...>]

On Nov 6, 2007 3:07 PM, Burkhard Plaum <pl...@ip...> wrote:

> Hi,
>
> Dennis Smit schrieb:
>
> > You are completely right!!! my mistake.
> >
> > the example I posted was using macros for:
> >
> > VisCollectionIterator iter;
> > visual_collection_get_iterator (&iter, collection);
> > while (visual_collection_iterator_has_more (&iter)) {
> >  VisHashmapChainEntry *entry = visual_collection_iterator_get_data
> (&iter);
> >  visual_collection_iterator_next (&iter);
> >  }
> >  visual_object_unref (VISUAL_OBJECT (&iter));
> > }
> >
>
> That didn't work either, but I succeeded with
>
> VisParamContainer * params;
> int num_parameters;
> VisListEntry * list_entry;
> VisParamEntry *param_entry;
>
> list_entry = (VisListEntry*)0;
>
> params = visual_plugin_get_params(visual_actor_get_plugin(actor));
> while(visual_list_next(&params->entries, &list_entry))
>   num_parameters++;
>
> /* ... */
>
> list_entry = (VisListEntry*)0;
>
> for(i = 0; i < num_parameters; i++)
>    {
>    visual_list_next(&params->entries, &list_entry);
>    param_entry = list_entry->data;
>
>    /* ... */
>    }
>
> Also I parse the VisUIWidget to get more informations, like limits for
> numeric parameters.
>
> One thing could be improved I think: Currently the VisUIWidget adds labels
> in addition to the mutators. This makes it difficult to get the label text
> corresponding to a mutator without parsing the whole layout of the dialog
> (or implemeting a VisUI backend, which is impossible in gmerlin).
> If label was a member of VisParamEntry, things would become much simpler.


The VisParamEntry its name might be describing enough in most cases tho
(which should be seen as a label).


>
>
> In fact, gmerlins native parameter definitions are like a mixture of
> VisParamEntry and VisUIWidget. The advantage is, that you have all
> informations
> (label, tooltips, ranges, default values etc.) in one statically defined
> struct.
> The disadvantage is that plugin programmers have no control over the
> actual layout
> of the dialog, except the order.
>

I like to have the UI control, but I agree that limits should move to
VisParam. I did some of that work on the 060 branch, but that died since I
ran out of time a year ago ;(.


>
> Now the good news: My libvisual wrapper works perfectly now with the
> following features:
>
> - All parameter types (using VisParamEntry and VisUIWidget) except
>   VISUAL_PARAM_ENTRY_TYPE_PALETTE and VISUAL_PARAM_ENTRY_TYPE_OBJECT
> - Mouse, Keyboard and resize events
> - Full OpenGL support
> - Non-OpenGL plugins render using gmerlins native methods (this means
>   in most cases XVideo or OpenGL hardware scaling). A pretty decent
> software
>   scaler is used, if neither OpenGL nor XVideo are present.
> - Embeddable into foreign windows using the XEMBED protocol
> - Visualizations are run in a slave process, so plugins can link to
>   arbitrarily broken libraries, leak memory and crash as much as they want
> :)
>   Communication with the slave process is done via a bidirectional pipe.
> - Tested with all plugins from libvisual-plugins-0.4.0 (except Gdkpixbuf)
> as
>   well as ProjectM. No crash observed until now.
> - Uses gmerlins method of scanning plugin directories and checking only
> the
>   modules, which have a changed file timestamp (to save startup time).
>   The actual dlopen()ing is done by libvisual.
>

That is really really neat!

Cheers,
Dennis