libvisual-devel — libvisual mailinglist for developers

Re: [Libvisual-devel] randomness work. fast random double

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

Here we go!...

Dennis, do you have some app to test this random() stuff?

-- 
Vitaly
GPG Key ID: F95A23B9

[Libvisual-devel] Re: xmms plugin, save enable/disable plugin states.

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

> Heya,
> 
> Duilio, I've got a question about the way plugin enable/disable states
> are being saved.
> 
> Snapshot from .xmms/config:
> [libvisual_xmms]
> version=0.1.7
> last_plugin=goom
> icon=/usr/share/libvisual-xmms/libvisual-xmms-vis.bmp
> width=731
> height=501
> color_depth=4
> fps=100
> fullscreen=FALSE
> enabled_plugins=all
> input_plugin=esd
> morph_plugin=flash
> random_morph=TRUE
> lv_dna=TRUE
> lv_gltest=TRUE
> madspin=TRUE
> 
> 
> Well, now what would happen if a plugin is called 'fps'... :)
> 
> I think it's better to save the states in the following manner:
> 
> plugins_enabled=list,of,plugins,that,are,enabled

Exactly, that is on the TODO. In fact there I have said (erroneously)
'remove enabled_plugins key', which must be 'replace when enable/disable
mechanism is ready' :-).

> (you don't need to save which are disabled, because they are if they 
> are not in the plugins_enabled= list.

Is true!


Bye,
Duilio.

[Libvisual-devel] Re: Accept/Ok.

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

> In the xmms config window, I think it's better to rename 'Accept' to 
> 'Ok'. It seems more consistent with other apps and xmms itself.
> 
> Dennis.

I'm agree with that.


Bye,
Duilio.

Re: [Libvisual-devel] Re: xmms plugin

[Dennis S. <sy...@yo...>]

On Sun, 2004-10-03 at 18:17 -0300, Duilio Javier Protti wrote:
> > What are your plans after it's finished ?
> > 
> > Thanks,
> > Dennis
> 
> Well, I want to implement the per-plugin configure dialog, which
> will allow set the values for the param entries.
> 
> I'll do it generating standard widgets depending on the type
> of each entry. I think this would be better than wait VisUI.
> 
> I was thinking about VisUI, and I'm convinced now that we must
> not implement this module. Developers have whithin libvisual 
> framework all what they need to implement his own UI's.
> 
> Without VisUI we have less dependency on the target, and
> less work will be required on a port. But well, is just my
> opinion :-)

I think that parsing just the VisParamEntries won't provide a nice
user interface experience, especially when it comes to big
lists of VisParamEntries. The VisUI module could give some hints
to the UI builder like, grouping, what kind of input entry, lay
restrictions on the input. VisUI won't be complex, or big, it's just
a few extra hints so a way nicer UI can be build.

My 2cents.

Cheers,
Dennis

Re: [Libvisual-devel] Re: the visual_log_error entry.

[Dennis S. <sy...@yo...>]

On Sun, 2004-10-03 at 18:17 -0300, Duilio Javier Protti wrote:
> Ok, this is a good possibility. Another one would be to still raising
> an error after showing the error message, but allow setting the error
> handler, maybe adding to lv_libvisual module:
> 
> void visual_set_error_handler (...);
> 
> and a private function like:
> 
> void lv_abort();
> 
> Probably this approach would be more flexible.

I'm not sure, I personally favor, to just do it in the error_message 
handler. I don't think this is a part of libvisual we want to
overcomplex, and doing it in the message handler is still very
flexible. What do others think ?? :)

Cheers,
Dennis

[Libvisual-devel] Re: gtk-list double click for activate plugin.

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

I will check on this!


Bye,
Duilio.

[Libvisual-devel] Re: xmms plugin

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

> What are your plans after it's finished ?
> 
> Thanks,
> Dennis

Well, I want to implement the per-plugin configure dialog, which
will allow set the values for the param entries.

I'll do it generating standard widgets depending on the type
of each entry. I think this would be better than wait VisUI.

I was thinking about VisUI, and I'm convinced now that we must
not implement this module. Developers have whithin libvisual 
framework all what they need to implement his own UI's.

Without VisUI we have less dependency on the target, and
less work will be required on a port. But well, is just my
opinion :-)


Bye,
Duilio.

[Libvisual-devel] Re: the visual_log_error entry.

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

> Heya List,
> 
> Now we use callbacks for VISUAL_LOG messages, maybe it's an idea
> to move the raise (SIGTRAP) into the callback. So that in some advanced
> environment an error can be catched and libvisual can be stopped without
> stopping the whole program.
> 
> What do you people think ?
> 
> Dennis

Ok, this is a good possibility. Another one would be to still raising
an error after showing the error message, but allow setting the error
handler, maybe adding to lv_libvisual module:

void visual_set_error_handler (...);

and a private function like:

void lv_abort();

Probably this approach would be more flexible.


Bye,
Duilio.

[Libvisual-devel] infinite.

[Dennis S. <sy...@yo...>]

The infinite plugin now does random color at startup.

Ofcourse in a reproduceable pattern using visual_random_context,
which is normally seeded with VisTime.

But you can override / retrieve the seed.

Cheers,
Dennis

[Libvisual-devel] Accept/Ok.

[Dennis S. <sy...@yo...>]

In the xmms config window, I think it's better to rename 'Accept' to 
'Ok'. It seems more consistent with other apps and xmms itself.

Dennis.

[Libvisual-devel] gtk-list double click for activate plugin.

[Dennis S. <sy...@yo...>]

Heya Duilio,

When you double click in the xmms it's visualisation plugin
list it'll show a config dialog. Thus I've had a look at
the xmms code how it's doing this, and it seems
to use GtkCList... and the following:

        gtk_clist_set_selection_mode(GTK_CLIST(prefswin_gplugins_list),
GTK_SELECTION_SINGLE);
        gtk_signal_connect(GTK_OBJECT(prefswin_gplugins_list),
"select_row", GTK_SIGNAL_FUNC(prefswin_glist_clicked), NULL);
        gtk_signal_connect(GTK_OBJECT(prefswin_gplugins_list),
"unselect_row", GTK_SIGNAL_FUNC(prefswin_glist_clicked), NULL);


It's in prefswin.c in the xmms/ dir within the xmms source
tree. You might want to have a look at this because
right now it's very unclear how you can actually change plugins.

And I eventually want to drop the keybindings so we need a better
and more natural way for this anyway.

I think 'doubleclick' in the list is a good option... If you
or someone else has a better suggestions, please go ahead.

Cheers,
Dennis

Re: [Libvisual-devel] randomness work. fast random double

[Dennis S. <sy...@yo...>]

On Sun, 2004-10-03 at 19:55 +0300, Vitaly V. Bursov wrote:
> the same idea can be used to generate floats.
> 
> should I make a patch?

Yeah sure, go ahead :)

Cheers,
Dennis

Re: [Libvisual-devel] randomness work. fast random double

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

On Sun, 03 Oct 2004 18:11:35 +0200
Dennis Smit <sy...@yo...> wrote:

> On Sun, 2004-10-03 at 18:48 +0300, Vitaly V. Bursov wrote:
> > > I've put some of the randomness request in CVS, not yet finished tho.
> > when you convert unsigned int to float you loose entropy...
> > I think it's ok to add double variant of functions...
> 
> Go ahead :)
OK :)

few bits of code....

==========================
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#define val_a 1664525L
#define val_c 1013904223L
#define RMAX  4294967295U

static unsigned int _lv_randseed = 5415454;

double rnd()
{
#if 0
	union {
		unsigned int a[2];
		double d;
	} val;
	unsigned int t;

	/* EXECUTION TIME
	 * alu maths = 5 clocks
	 * fsub = 4 clocks
	 * TOTAL: 9 for double
	 * WARNING: numbers should be ieee754 compliant
	 */

	t = _lv_randseed = val_a * _lv_randseed + val_c;
	val.a[0]=(t<<20);
	val.a[1]=0x3ff00000U | (t>>12);

	return (*(double*)&val.d)-1.0;
#else
	unsigned int t;
	double x;

	/* EXECUTION TIME
	 * fild - load int to fpu = 4 clocks
	 * fdiv - normalize result = 16/20/24 clocks for signle/double/ext prec.
	 * TOTAL: 24 for double
	 */

	t = _lv_randseed = val_a * _lv_randseed + val_c;
	x = (double)t/RMAX;
	return x;
#endif
}

double x = 0.0;

int main()
{
	unsigned int i, t=1000000000;

	for (i=0;i<t;i++){
		x += rnd();
	}

}
==========================

the same idea can be used to generate floats.

should I make a patch?

-- 
Vitaly
GPG Key ID: F95A23B9

Re: [Libvisual-devel] randomness work.

[Dennis S. <sy...@yo...>]

On Sun, 2004-10-03 at 18:48 +0300, Vitaly V. Bursov wrote:
> > I've put some of the randomness request in CVS, not yet finished tho.
> when you convert unsigned int to float you loose entropy...
> I think it's ok to add double variant of functions...

Go ahead :)

> and one more thing... regarding to visual_random_int_range()
> we should not use modulo operation unless we want to get _short_
> repeating sequence. This function will be used mostly (i think)
> to select some config profile like

Thanks for the demo program and for pointing this out, it has
been fixed in CVS.

Cheers,
Dennis

[Libvisual-devel] Congrats Salsaman!

[Dennis S. <sy...@yo...>]

>From the whole libvisual team (I assume atleast),

Congrats Salsaman, author of LiVES with his birthday!! :)

Cheers,
Dennis

Re: [Libvisual-devel] randomness work.

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

On Sat, 02 Oct 2004 13:35:13 +0200
Dennis Smit <sy...@yo...> wrote:

> I've put some of the randomness request in CVS, not yet finished tho.
when you convert unsigned int to float you loose entropy...
I think it's ok to add double variant of functions...


and one more thing... regarding to visual_random_int_range()
we should not use modulo operation unless we want to get _short_
repeating sequence. This function will be used mostly (i think)
to select some config profile like

load_new(configs[visual_random_int_range(0, sizeof(config)/sizeof(*config)-1)]);


we must use division op. here. smth like
uint32_t visual_random_int_range (int min, int max)
{
        return (visual_random_int () / (RANDOM_MAX/(max - min + 1))) + min;
}

Yes, it's slow but works better.

To check it compile&run

===============
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#define val_a 1664525L
#define val_c 1013904223L
#define RMAX  4294967295U

#define X (1<<3)

static unsigned int _lv_randseed = 5415454;

unsigned int rnd()
{
	unsigned int a;
	a = _lv_randseed = val_a * _lv_randseed + val_c;
	a = a%X;
//	a = a/(RMAX/X);
	return a;
}

int main()
{
	unsigned int i, t=256;

	for (i=0;i<t;i++){
		printf("%d ", rnd());
		if (i%X == 0)
			printf("\n");
	}

}
===============
;)


-- 
Vitaly
GPG Key ID: F95A23B9

[Libvisual-devel] More things, on the agenda :)

[Dennis S. <sy...@yo...>]

Hey Salsaman,

On your personal list of 'FIX THIS FOR ME OR DIE' I found:
4) add to visual_input_list, make a visual_input_list_multithreaded

While most issues you've listed have been fixed last week, some have 
not.

Regarding this one, can you explain what you exactly mean here ?

Cheers,
Dennis

[Libvisual-devel] xmms plugin, save enable/disable plugin states.

[Dennis S. <sy...@yo...>]

Heya,

Duilio, I've got a question about the way plugin enable/disable states
are being saved.

Snapshot from .xmms/config:
[libvisual_xmms]
version=0.1.7
last_plugin=goom
icon=/usr/share/libvisual-xmms/libvisual-xmms-vis.bmp
width=731
height=501
color_depth=4
fps=100
fullscreen=FALSE
enabled_plugins=all
input_plugin=esd
morph_plugin=flash
random_morph=TRUE
lv_dna=TRUE
lv_gltest=TRUE
madspin=TRUE


Well, now what would happen if a plugin is called 'fps'... :)

I think it's better to save the states in the following manner:

plugins_enabled=list,of,plugins,that,are,enabled

(you don't need to save which are disabled, because they are if they 
are not in the plugins_enabled= list.


Thanks,
Dennis

[Libvisual-devel] Flags,

[Dennis S. <sy...@yo...>]

Heya list,

What kind of behavior do we want on the VISUAL_PLUGIN_FLAG_SPECIAL 
flag ?

This flag is used for plugins like 'webcam' 'gdkpixbuf' and
other special purpose plugins which shouldn't be used in regular plugin
rotations like used in the xmms plugin.

However now we have this flag I'm not sure what the correct behavior
from libvisual would be.

Anyone suggestions on this ?

Cheers,
Dennis

[Libvisual-devel] plugin flags.

[Dennis S. <sy...@yo...>]

I've got a partial plugin flags implementation in CVS.

I've added a field 'flags' to the VisPluginInfo data structure.
if 'VISUAL_PLUGIN_FLAG_NOT_REENTRANT is orred to that field this
plugin loader will refuse to load it twice.

Cheers,
Dennis

Re: [Libvisual-devel] xmms plugin

[Dennis S. <sy...@yo...>]

On Sat, 2004-10-02 at 18:34 -0300, Duilio Protti wrote:
> The configure dialog on xmms plugin is almost finished, so please check
> the CVS and test it when you have some time, and update translations too.

It looks VERY good, very nice Duilio!

If we could just get this 'double click on plugin, start' thing 
working... I'll research that for a bit as well..

What are your plans after it's finished ?

Thanks,
Dennis

[Libvisual-devel] xmms plugin

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

The configure dialog on xmms plugin is almost finished, so please check
the CVS and test it when you have some time, and update translations too.
Bye,
Duilio.

[Libvisual-devel] CVS api/abi changed.

[Dennis S. <sy...@yo...>]

Everyone who runs from CVS, you need to rebuild everything, ABI/API 
changes ;)

Cheers,
Dennis

[Libvisual-devel] the visual_log_error entry.

[Dennis S. <sy...@yo...>]

Heya List,

Now we use callbacks for VISUAL_LOG messages, maybe it's an idea
to move the raise (SIGTRAP) into the callback. So that in some advanced
environment an error can be catched and libvisual can be stopped without
stopping the whole program.

What do you people think ?

Dennis

[Libvisual-devel] Re: log verboseness

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

> I'm very happy with the system you implemented, I've got 1 comment
> and 1 question. First, there is no enum yet to entirely disable
> visual_log output, I think that VERBOSENESS_NONE should be really
> none verbose.

Is true. Now the levels are:

typedef enum {

        VISUAL_LOG_VERBOSENESS_NONE,    /**< Don't show any message at
					all. */

        VISUAL_LOG_VERBOSENESS_LOW,     /**< Show only VISUAL_LOG_ERROR
					and                                        
					VISUAL_LOG_CRITICAL messages. */

        VISUAL_LOG_VERBOSENESS_MEDIUM,  /**< Show all log messages
					except VISUAL_LOG_DEBUG ones. */

        VISUAL_LOG_VERBOSENESS_HIGH     /**< Show all log messages. */

} VisLogVerboseness;


> One more question, I really like the message handle system, I wonder
> if it would be possible to also have a 'all messages' handler that
> can be optionally set. This would be nice for an app that just wants to
> redirect ALL output. Another thing is that the handler set function 
> should accept a void *priv, if the app wants the handler function to 
> handle a private. Let's say a GtkWidget in which text has to be printed.

Ok, the signature of the message handler was moved to:

void visual_log_message_handler_func_t (const char *message,
                                 const char *funcname, void *privdata);

and there is a new function visual_log_set_all_messages_handler().

Thanks a lot for the suggestions!


Bye,
Duilio.