libvisual-devel Mailing List for Libvisual (Page 38)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Thanks to the new lv_endiannes.h module of Vitaly, 
I have seen that lvconfig.h was nos installed
at all on default include dir. But the problem
was fixed.

Bye,
Duilio.

Em Tuesday 13 July 2004 13:28, Dennis Smit escreveu:
> On Mon, 2004-07-12 at 22:13 -0300, Gustavo Sverzut Barbieri wrote:
> > Hello,
> >
> > I've commited a new input plugin: mplayer. It can use data exported by
> > mplayer audio filter "export" (mplayer -af export).
> >
> > After 3 commits (sorry! I'm really distracted today) it's stable.
> >
> > I also did small changes to esd and alsa. The focus was to ensure
> > pointers were not null and to use visual_log() instead of fprintf().
> >
> > Any comments?
> >
> > PS: There is a way to get input plugin parameters? I'll need that.
>
> Hello,
>
> Thanks a LOT for commiting your mplayer plugin and for replacing the
> fprintfs with visual_logs!
>
> However you've forgotten to update the ChangeLog file, please do update
> it ! :)

Done!

> Plugin parameters is being worked out, but the lack of time is slowing
> me down. But it'll be there soon!

Ok.

> Btw, please don't do too much NULL checking within the plugins. If
> someone goes wrong all down at this layer something is majorly borked
> within libvisual itself or the user is creating hacky code. The
> abstraction system, VisInput, VisMorph, VisActor do handle most of the
> situations. Thanks anyway ;)

That's why I always do NULL checking, to know if there's something wrong. If 
everbody code it right we are not humans... so errors may appear and better 
catch them as soon as possible.

Since most of segfaults are caused by null pointers I think worth checking for 
them always...

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

On Mon, 2004-07-12 at 22:13 -0300, Gustavo Sverzut Barbieri wrote:
> Hello,
> 
> I've commited a new input plugin: mplayer. It can use data exported by mplayer 
> audio filter "export" (mplayer -af export).
> 
> After 3 commits (sorry! I'm really distracted today) it's stable.
> 
> I also did small changes to esd and alsa. The focus was to ensure pointers 
> were not null and to use visual_log() instead of fprintf().
> 
> Any comments?
> 
> PS: There is a way to get input plugin parameters? I'll need that.

Hello,

Thanks a LOT for commiting your mplayer plugin and for replacing the
fprintfs with visual_logs!

However you've forgotten to update the ChangeLog file, please do update
it ! :)

Plugin parameters is being worked out, but the lack of time is slowing
me down. But it'll be there soon!

Btw, please don't do too much NULL checking within the plugins. If
someone goes wrong all down at this layer something is majorly borked
within libvisual itself or the user is creating hacky code. The
abstraction system, VisInput, VisMorph, VisActor do handle most of the
situations. Thanks anyway ;)

Cheers,
Dennis

> 
> 
> Here is the first revision with a bit more explanation:
> 
> revision 1.1
> date: 2004/07/12 23:51:12;  author: gsbarbieri;  state: Exp;
> Added mplayer input plugin.
> 
> Background:
>         Mplayer has an export filter which export it's buffer to a file
>         using mmap().
> 
> TODO:
>         * Implement option to change shared file. Current implementation
>           uses default mplayer value (~/.mplayer/mplayer-af_export)
>         * Support different number of channels (current is fixed to 2),
>           different buffer size (current is 512 samples) and different
>           format (current is 16bits signed).
> 
> BUGS:
>         * Some mplayer audio output system changes the rate mplayer calls
>           its export filter, leading to low update rate. Know problematic
>           output system: esd. Know to work right: alsa, oss. This is not
>           a big issue since you can use libvisual own esd input plugin and
>           get it right. NOTE: This is a mplayer bug.
> =============================================================================
> 
> 

I've commited a russian translation for libvisual-xmms,
changed LINGUAS and configure.ac.

-- 
Vitaly
GPG Key ID: F95A23B9

Great! I can get to CVS again :)

I've commited several patches including dealign one with
endianess issues. Can somebody test it please?

ALSA input patch tries to use a large buffer. This can make
it work a lot better.

-- 
Vitaly
GPG Key ID: F95A23B9

Hello,

I've commited a new input plugin: mplayer. It can use data exported by mplayer 
audio filter "export" (mplayer -af export).

After 3 commits (sorry! I'm really distracted today) it's stable.

I also did small changes to esd and alsa. The focus was to ensure pointers 
were not null and to use visual_log() instead of fprintf().

Any comments?

PS: There is a way to get input plugin parameters? I'll need that.

Here is the first revision with a bit more explanation:

revision 1.1
date: 2004/07/12 23:51:12;  author: gsbarbieri;  state: Exp;
Added mplayer input plugin.

Background:
        Mplayer has an export filter which export it's buffer to a file
        using mmap().

TODO:
        * Implement option to change shared file. Current implementation
          uses default mplayer value (~/.mplayer/mplayer-af_export)
        * Support different number of channels (current is fixed to 2),
          different buffer size (current is 512 samples) and different
          format (current is 16bits signed).

BUGS:
        * Some mplayer audio output system changes the rate mplayer calls
          its export filter, leading to low update rate. Know problematic
          output system: esd. Know to work right: alsa, oss. This is not
          a big issue since you can use libvisual own esd input plugin and
          get it right. NOTE: This is a mplayer bug.
=============================================================================

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

This is like a little roadmap to the gettext's notion
of i18n, for people that known about this, just skip
this message, will be boring :-).

There are four different views related to i18n stuff
with gettext:

The programmer's view
=====================

Instead of showing a string on the sources through
something like:

printf ("Hello world\n");

we use this:

#include "gettext.h"

printf (gettext("Hello world\n"));

here gettext() will try to retrieve the corresponding
translated string according with the locale (if it is
set) from a program's catalog of translated strings
(if any). If all this fail, or if i18n was disable on
building time, passing --disable-nls to configure script,
it is showed the string that appears on the source line
above.

To avoid enlarge the code with gettext() calls, the macro
'_(String) (gettext(String))' is defined on gettext.h.

The maintainer's view
=====================

He is the responsible for to update building related files
when new catalogs are added or when new sources that contains
translatable strings are added/deleted from the project.
The maintainer will NEVER touch translation files, but instead
notify to the corresponding translator or translation team.

The translator's view
=====================

All the strings to be translated are kept on a file called
libvisual-xmms.pot on the po directory. This file must never
be modified by hand. The translatable strings here are
extracted directly from the source files listed on 'POTFILES',
using the program 'xgettext'.

The different catalogs must be kept in sync with this template
file, again not by hand, but using the program 'msgmerge', which
takes 'libvisual-xmms.pot' file and a given catalog, say 'es.po',
and update all accordingly, adding new translatable strings or
deleting old one's (in fact msgmerge doesn't remove old strings,
but mark it as deprecated; the translator must decide if it is
removed from the catalog, possibly asking first to developers).

The good point here is that all this is automatically done
when we run 'make update-po' inside po directory (or when we
run 'make dist' at top level).

So the procedure is simple:
- cvs update
- cd po and make update-po
- (edit my-language.po)
- cvs commit my-language.po

and that's all!

The user's view
===============

When the user install the package, by default are installed all
the available catalogs, unless the user set the LINGUAS environment
variables to the set of catalogs they want before to configure.
I.e.:

export LINGUAS="pt_BR fr"
./configure

will build and install only brazilian an french catalogs.

After install, end user can use any installed catalog setting his
environment accordingly.
I.e:

export LANG=pt_BR
xmms

Now the configure window of Libvisual XMMS plugin will be a 
brazilian one.

If any question, please don't keep it, just ask on this list!

Regards,
Duilio.

Thanks a lot JC!!!

Have put it in CVS HEAD.

On Mon, 2004-07-12 at 23:35 +0200, Jean-Christophe wrote:
> Here is the french translation.

Here is the french translation.
On Mon, 2004-07-12 at 23:44 +0300, Vitaly V. Bursov wrote:
> On Mon, 12 Jul 2004 18:20:25 +0200
> Dennis Smit <sy...@yo...> wrote:
> 
> > It seems that Duilio has fixed gettext i18n support within
> > libvisual-xmms! Gustavo, Vitaly and others would you people
> > care to translate libvisual-xmms to your favorite (or native) language ?
> 
> I can make russian translation.

Yay, please do so!

On Mon, 12 Jul 2004 18:20:25 +0200
Dennis Smit <sy...@yo...> wrote:

> It seems that Duilio has fixed gettext i18n support within
> libvisual-xmms! Gustavo, Vitaly and others would you people
> care to translate libvisual-xmms to your favorite (or native) language ?

I can make russian translation.

-- 
Vitaly
GPG Key ID: F95A23B9

> Hi,
> Of course I can do a french translation, what should I do for that ?
> JC

When you sync with the CVS, that will update configure.ac,
top Makefile.am and will create a po directory, wich will
contain:

- ChangeLog: about the i18n stuff, not the general one.
- es.po: the spanish catalog.
- es_AR.po: the argentinian spanish catalog.
- LINGUAS: contains the current available catalogs. If you add
french, you must add 'fr' to this file. 
- POTFILES.in: list of the source files from where the translatable
strings will be extracted.
- Makefile.in.in: don't touch :-)
- libvisual-xmms.pot: the most important, this is the template
containing translatable strings but without being associated
with any specific language.

After get this files, you must go to po directory and run

  msginit

this will take the 'libvisual-xmms.pot' template and will generate
a 'fr.po' file filling all fields it can with values taken from your
environment (sometimes 'fr.po' is not generated, but 'messages.po';
just renamed).

After that, edit 'fr.po' with an UTF-8 compliant editor (like gedit), 
and translate all the strings you want. If some string is not
translated, that string just will appear as it is written on the
sources (english).

Then add 'fr' to LINGUAS on po directory.

Then add 'fr' to ALL_LINGUAS variable on configure.ac, line 77.

Then run make, which must regenerate configure script, rerun 
configure, and near the end must show something like:

checking for catalogs to be installed...  es es_AR fr

Then install, and you will get Libvisual XMMS in french!

If any problem is found just tell me.

Bye,
Duilio.

On Mon, 2004-07-12 at 16:25 -0300, Gustavo Sverzut Barbieri wrote:
> Em Monday 12 July 2004 16:15, Dennis Smit escreveu:
> > Checkout libvisual-xmms and make a patch for a fr.po + adding
> > the language to the buildtree.
> >
> > I must admit that my gettext knowledge has become a bit vague
> > so Duilio maybe you could give us a step by step todo
> > to add extra languages to the xmms plugin ?
> 
> I know you'll not follow this path, but it's easier anyway:
> 
> cd $LIBVISUAL/po
> cp libvisual-xmms.pot <LANG>.po
> 
> kbabel <LANG>.po # This part you will not like, Dennis... :)

Rofl, Hey shouldn't the language code be added to LINGUS as well ?

And how to make sure it's in dist ?

> If you use the best editor in the world, emacs, it have a PO-mode also and 
> will help you out.
> 
> If you want to do it in other editor, just fill the msgstr line... but take 
> care to not damage the format.
> 

Em Monday 12 July 2004 16:15, Dennis Smit escreveu:
> Checkout libvisual-xmms and make a patch for a fr.po + adding
> the language to the buildtree.
>
> I must admit that my gettext knowledge has become a bit vague
> so Duilio maybe you could give us a step by step todo
> to add extra languages to the xmms plugin ?

I know you'll not follow this path, but it's easier anyway:

cd $LIBVISUAL/po
cp libvisual-xmms.pot <LANG>.po

kbabel <LANG>.po # This part you will not like, Dennis... :)

If you use the best editor in the world, emacs, it have a PO-mode also and 
will help you out.

If you want to do it in other editor, just fill the msgstr line... but take 
care to not damage the format.

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

Checkout libvisual-xmms and make a patch for a fr.po + adding
the language to the buildtree.

I must admit that my gettext knowledge has become a bit vague
so Duilio maybe you could give us a step by step todo
to add extra languages to the xmms plugin ?

Cheers,
Dennis

On Mon, 2004-07-12 at 20:40 +0200, Jean-Christophe wrote:
> Hi,
> Of course I can do a french translation, what should I do for that ?
> JC

Hi,
Of course I can do a french translation, what should I do for that ?
JC

It seems that Duilio has fixed gettext i18n support within
libvisual-xmms! Gustavo, Vitaly and others would you people
care to translate libvisual-xmms to your favorite (or native) language ?

Cheers and thanks,
Dennis

Ok a few ideas.

The following case scenario:

Visual is drawing into a GtkWidget. Embedded in a random player.

Random player wants the visual fullscreen. How do we proceed from here
on ? Can we get the gtk area fullscreen, in a decent mather, or do
we need to 'transfer' the visual from the gtk widget to a x11 display
and then go fullscreen ?. I don't have indepth knowledge about this
so please enlighten me how we can fix these kind of issues. Also
regarding the fullscreen stuff it would be good if the driver could
give us a list of resolutions, depths so we can choose an appropiate
one.

Cheers,
Dennis

Heya Vitaly,

Impressive, very impressive! I was wondering how good the library
is with reentrancy and multiple windows ?

I'm very happy with the concept around this lib. This way we can target
any display without the need of:

1. A very advanced 'player' for libvisual.
2. A program for every display target.

This will also solve the issue a friend of mine had with the
libvisual-xmms plugin using SDL, Because it would lock the
screen on fullscreen, which was very nasty in his dualhead setup
of which one head is a beamer :)

How are you going to implement things like window_size_requisistions,
window_capption sets, like title, icon ? (if possible that is)
window_no_frame and fullscreen support ?

I have to evaluate all the code a bit more to come up with critics, but
I'm very happy with your design!

I personally hadn't thought of the frontend part which is very good!

Rockon!

Cheers,
Dennis

On Sun, 2004-07-11 at 00:38 +0300, Vitaly V. Bursov wrote:
> Hello!
> 
> Not much docs, sorry... but it should be not a problem to get the idea.
> And no event system yet.
> 
> There are backend driver ("glx". also can be "x11", "sdl" or "win32") and
> frontend ("new" - create new object, Also: "gtk-widget", "qt-widget" and so on).
> 
> Any ideas, suggestions, critics are very welcome!

Hello!

Not much docs, sorry... but it should be not a problem to get the idea.
And no event system yet.

There are backend driver ("glx". also can be "x11", "sdl" or "win32") and
frontend ("new" - create new object, Also: "gtk-widget", "qt-widget" and so on).

Any ideas, suggestions, critics are very welcome!

-- 
Thanks,
Vitaly
GPG Key ID: F95A23B9

I've thought out the VisParam API, any comments ?

The container that contains a set of parameters:
struct _VisParamContainer {
        VisList entries;

	VisEventQueue *eventqueue;
};

A parameter entry:
struct _VisParamEntry {
	VisParamContainer *parent;
        char *name;
        VisParamType type;
        int flags;

        union {
                char *string;
                int *integer;
                float *floating;
                /** @todo add a VisColor entry as well */
        } data;
};

API functions:
VisParamContainer *visual_param_container_new ();
int visual_param_container_destroy (VisParamContainer *paramcontainer);

VisParamEntry *visual_param_entry_new ();
int visual_param_entry_free (VisParamEntry *param);

/* On a entry set an event is being emitted */
int visual_param_entry_set (VisParamEntry *param, char *name,
VisParamType type, int flags, void *data);

int visual_param_container_add (VisParamContainer *paramcontainer,
VisParamEntry *param);
int visual_param_container_add_new (VisParamContainer *paramcontainer,
char *name, VisParamType type, int flags, void *data);
int visual_param_container_remove (VisParamContainer *paramcontainer,
char *name);
VisParamEntry *visual_param_container_find (VisParamContainer
*paramcontainer, char *name);

The pointer to the eventqueue is optionally NULL and in case of a
plugin is being set by the plugin handler.

Please comment.

Dennis

Heya List,

I'd like to send out events to the plugin event handler
when params are changed. However the plugin it's VisEventQueue is
within the VisActor at the moment and not within the plugin
itself. Do you people agree that it would be wise to have a private
VisEventQueue entry within the plugin structure so events can
always be put on the same queue ?

Thanks,
Dennis

Heya Duilio,

Do you think it would be nicer to add a visual_mem_free as well ?

If so, would you like to do this ?

Thanks,
Dennis

Wow I can reproduce this after updating the morphsdl.c app.

I never had this on non accelerated nvidia xserver, this is
odd.

On Thu, 2004-07-08 at 16:58 +0200, Dennis Smit wrote:
> This sounds scary, Can you send me the source of the app ?
>
> Thanks,
> Dennis

Hello Mark,

Welcome to the list!

It sounds very interesting to be the visualisation framework of choice
for the aramoK player! The goal of libvisual is ofcourse to be used
everywhere and have one common visualisation platform!

The lib is at the moment in heavy development. It's usable for
developers but not yet ready for primetime. However it would
be great if you could have a look at it and give suggestions where
appropiate. In the end YOU, the mediaplayer developers are our
target audience :). I must add that we're rapidly improving our corelib
and it'll be useable within a short time. We have a few issues left
but we're rapidly improving. It's getting there for sure.

Thanks for your interests and if you'd like to know things, need
help with anything regarding supporting libvisual as the visualisation
platform of choice. Please let us know and we will gladly respond,
help with problems.

Cheers and thanks,
Dennis

On Fri, 2004-07-09 at 09:26 +0200, Mark Kretschmann wrote:
> Hi,
> 
> the other day Gustavo Sverzut Barbieri pointed us amaroK developers to the 
> libvisual project, as it might be interesting for our project. amaroK is 
> KDE's new audio player. You can learn about the project on
> 
> http://amarok.kde.org
> 
> Currently amaroK supports XMMS visualization plugins by means of a small 
> wrapper program (a hack really, but works reasonably well). For the future we 
> planned to provide our own visualization framework. Now libvisual comes into 
> game, and this looks like a very promising path we could go. So we're looking 
> forward to trying your lib.
> 
> How far is libvisual progressed? Is it worth starting to support it already 
> now?
> 
> 
> --Mark
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Libvisual-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libvisual-devel

2004	Jan	Feb	Mar	Apr (38)	May (22)	Jun (92)	Jul (101)	Aug (18)	Sep (286)	Oct (180)	Nov (73)	Dec (14)
2005	Jan (18)	Feb (74)	Mar (56)	Apr (11)	May (5)	Jun (4)	Jul (20)	Aug (4)	Sep	Oct	Nov (1)	Dec (2)
2006	Jan (11)	Feb (2)	Mar (10)	Apr (2)	May (1)	Jun	Jul (24)	Aug (11)	Sep (5)	Oct (16)	Nov (25)	Dec (8)
2007	Jan	Feb (1)	Mar	Apr	May	Jun (3)	Jul (1)	Aug	Sep	Oct (4)	Nov (12)	Dec
2009	Jan	Feb	Mar	Apr	May	Jun	Jul (3)	Aug	Sep	Oct	Nov (2)	Dec
2010	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec
2011	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (5)

libvisual-devel Mailing List for Libvisual (Page 38)

Audio visualisation library

libvisual-devel — libvisual mailinglist for developers