libvisual-devel

[Libvisual-devel] Re: Re: Changes in libvisual

[Jan de R. <psi...@ho...>]

Heya Vitaly, thanks for your reply!

Looks quite good, tho I've got some questions.

____
struct _VisPluginInfo {
	uint32_t struct_size;
	uint32_t api_version;
	VisPluginType plugin_type;

	const char *name;
	const char *author;
	const char *version;
	const char *about;
	const char *help;

	/* VisPluginData* will be allocated by Libvisual.
	 * Plugin only needs to init priv, if necessary.
	 */
	int (*init)(VisPluginData*);
	int (*cleanup)(VisPluginData*);

	union {
		struct {
			int (*x)();
		} actor;

		struct {
			int (*x)();
		} input;

		struct {
			int (*x)();
		} morph;
	} preferences;
what are these preferences for ?

/*
// count defaults to 1

const VisPluginInfo *get_plugin_info(int *count)
{
	const VisPluginInfo info[] = {
		/ * blah-blah-blah * /
	};
	*count = sizeof(info)/sizeof(*info);
	return info;
}
What is count for ?

Besides these questions, it looks good, if you can create a patch for this 
and put
it on the list, it would be great!

Also, I've been VisMemizing most of libvisual yesterday and also added a new 
tool
'lv-inspect' that gives all information about a plugin.

(A question regarding this, how can I build a tool that needs libvisual to 
compile
but resides in the same buildtree and should be installed on make install ?)

Thanks and cheers,
Dennis

_________________________________________________________________
Nieuwe cursus MS Word on-line. Ook met opleidingscheques! 
http://www.msn.be/msnacademy/

[Libvisual-devel] Re: Changes in libvisual - episode II

[Duilio P. <dp...@fc...>]

> Also, I've been VisMemizing most of libvisual yesterday and also added
> a new  tool
> 'lv-inspect' that gives all information about a plugin.
>
> (A question regarding this, how can I build a tool that needs libvisual
> to  compile
> but resides in the same buildtree and should be installed on make
> install ?)

Sorry about the last incomplete mail, I'm using a web interface
to write this, because I'm on a conference now (until weekend).

Like I was saying, this way you do not interfere with the
libivisual_PRIMARY targets. However, probably other things will
be needed to be adjusted for this to work. I can help on this
when I come back from conference, next monday.


Bye,
Duilio.

Re: [Libvisual-devel] plugin api. preview.

[Vitaly V. B. <vit...@us...>]

> ____
> 	union {
> 		struct {
> 			int (*x)();
> 		} actor;
> 
> 		struct {
> 			int (*x)();
> 		} input;
> 
> 		struct {
> 			int (*x)();
> 		} morph;
> 	} preferences;
> what are these preferences for ?

These will contain some plugin's requirements, like depth.
Probably placing function pointers here could be nice idea.


> /*
> // count defaults to 1
> 
> const VisPluginInfo *get_plugin_info(int *count)
> {
> 	const VisPluginInfo info[] = {
> 		/ * blah-blah-blah * /
> 	};
> 	*count = sizeof(info)/sizeof(*info);
> 	return info;
> }
> What is count for ?
It will make possible to create one library for multiple plugins.
For example, morph plugins can be separated to a simplier ones by depth
or make actor plugins with common codebase but very different appearance,
or all-in-one :)

These not plugins anymore, they are plugin libraries! :)

> Besides these questions, it looks good, if you can create a patch for this 
> and put
> it on the list, it would be great!
OK, here's a first patch. Sorry, it's againts old cvs tree.
Sorry, it's a dirty patch.

But it works. At least it's capable to run two ported plugins --
alsa and lv_dna.

No morph stuff is ported, but it's easy to do:
1. s/VisMorphPlugin/VisPluginData/ in lv_plugin.h
2. fix lv_morph.[ch]
3. port plugin[s].

Looks like that's all for now. I'm going on vacation for a week or two
starting monday or so. I won't be available.

Anyway, everybody is welcome to try this patch, fix something ;) and
send a report!

-- 
Thanks,
Vitaly
GPG Key ID: F95A23B9