VisParamContainer question

View: New views
7 Messages — Rating Filter:   Alert me  

VisParamContainer question

by Burkhard Plaum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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
Libvisual-devel@...
https://lists.sourceforge.net/lists/listinfo/libvisual-devel

Re: VisParamContainer question

by Dennis Smit :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 <plaum@...> 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
Libvisual-devel@...
https://lists.sourceforge.net/lists/listinfo/libvisual-devel


-------------------------------------------------------------------------
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
Libvisual-devel@...
https://lists.sourceforge.net/lists/listinfo/libvisual-devel

Re: VisParamContainer question

by Burkhard Plaum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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(¶mcontainer->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


-------------------------------------------------------------------------
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
Libvisual-devel@...
https://lists.sourceforge.net/lists/listinfo/libvisual-devel

Re: VisParamContainer question

by Dennis Smit :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



On 10/31/07, Burkhard Plaum <plaum@...> 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!
 



-------------------------------------------------------------------------
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
Libvisual-devel@...
https://lists.sourceforge.net/lists/listinfo/libvisual-devel

Re: VisParamContainer question

by Burkhard Plaum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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(¶ms->entries, &list_entry))
   num_parameters++;

/* ... */

list_entry = (VisListEntry*)0;

for(i = 0; i < num_parameters; i++)
    {
    visual_list_next(¶ms->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


-------------------------------------------------------------------------
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
Libvisual-devel@...
https://lists.sourceforge.net/lists/listinfo/libvisual-devel

Re: VisParamContainer question

by salsaman-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


> Today's Topics:
>
>    1. Re: VisParamContainer question (Burkhard Plaum)
>
>
> The wrapper code is here:
>
> http://gmerlin.cvs.sourceforge.net/gmerhttp://gmerlin.cvs.sourceforge.net/gmerlin/gmerlin/lib/bglv.c?view=markuplin/gmerlin/lib/bglv.c?view=markup

> Burkhard
>
>


Thanks for that, Bukhard. I'll see if I can use some of it in the LiVES
libvisual wrapper !

http://lives.cvs.sourceforge.net/lives/lives-plugins/weed-plugins/libvis.c?view=markup

Salsaman.
http://lives.sf.net



-------------------------------------------------------------------------
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
Libvisual-devel@...
https://lists.sourceforge.net/lists/listinfo/libvisual-devel

Re: VisParamContainer question

by Dennis Smit :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



On Nov 6, 2007 3:07 PM, Burkhard Plaum <plaum@...> 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


-------------------------------------------------------------------------
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
Libvisual-devel@...
https://lists.sourceforge.net/lists/listinfo/libvisual-devel