linux-wildo-devel — developers public list

Re: [Linux-wildo-devel] New API for Audio and Codec

[Gabriele D. C. <dar...@io...>]

Naturally, everything said in the mail in the mail with topic
"dataserver packets" still applies, this mail is intended for serious
discussion and concrete ideas on the implementation too.
Like "I want it to be able to do this" or "I have heard that other
programs do this".

Regards again,
Gabriele Dini Ciacci

On Tue, 20 Mar 2007 00:54:14 +0100
Gabriele Dini Ciacci <dar...@io...> wrote:

> Many tests during bug finding shown the limits of our current Audio
> and Codec API. They miss even basic functionality cause none found the
> time to add those things, in first place a SetReadDevice() and
> SetWriteDevice() calls, or something similar, the SetMode function is
> very limited (but probably will stay so, maybe with touch ups for
> stereo/mono), the SetFragmentSize and GetFragemntSize are just
> ridiculously empty.
> 
> For this reason, if someone is working on the Audio or the Codec API,
> or have ideas and requests about them, what they should do and what
> not please reply to this mail, so we can end up with a final design.
> 
> I will on my side post here (next time, it's late now) the stubs for
> the new API.
> 
> I will take the shape of the API from gros code that had
> pluginization, noting that to write decent unit tests we need the
> codecs and the audio to be loadable on run time, currently I am
> testing with a codec that writes to a file (it's in revision 253 as
> lw_sound_file) and managing it with all the thing hard coded is
> really a mess.
> 
> I thoguth that maybe a good design can be to allways have a class that
> is a endpoint/startpoint like the Audio Class and a class that is the
> codec that is the middle point and that can be seen as a filter, and
> more than one can exist and concatnate the stream.
> 
> I do not know is a good design for this codec class can be "onion
> like" or "serial like".
> Onion like is like the class has pointers to other codec itself and
> calls the other class internally. So each class call it's father/son
> (depends on how you like to assemble them bottom up or top down) and
> return the final buffer.
> Serial like is like we have an external filter manage that manages the
> order of the filters and they get called from outside in the given
> order and the buffer is passed externally.
> 
> I personally like more the "serial like" design, but that is probably
> because I am more a C coder than C++ one. I really would like to hear
> some suggestion on it.
> 
> So the thing is open for comments, awaiting you.
> 
> 
> Regards,
> Gabriele Dini Ciacci
> 
> 
> ----------- 
> http://linux-wildo.sf.net
> http://www.diniciacci.org
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your opinions on IT & business topics through brief surveys-and
> earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________ Linux-wildo-devel
> mailing list Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-wildo-devel


----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

[Linux-wildo-devel] New API for Audio and Codec

[Gabriele D. C. <dar...@io...>]

Many tests during bug finding shown the limits of our current Audio and
Codec API. They miss even basic functionality cause none found the
time to add those things, in first place a SetReadDevice() and
SetWriteDevice() calls, or something similar, the SetMode function is
very limited (but probably will stay so, maybe with touch ups for
stereo/mono), the SetFragmentSize and GetFragemntSize are just
ridiculously empty.

For this reason, if someone is working on the Audio or the Codec API,
or have ideas and requests about them, what they should do and what
not please reply to this mail, so we can end up with a final design.

I will on my side post here (next time, it's late now) the stubs for
the new API.

I will take the shape of the API from gros code that had pluginization,
noting that to write decent unit tests we need the codecs and the audio
to be loadable on run time, currently I am testing with a codec that
writes to a file (it's in revision 253 as lw_sound_file) and managing
it with all the thing hard coded is really a mess.

I thoguth that maybe a good design can be to allways have a class that
is a endpoint/startpoint like the Audio Class and a class that is the
codec that is the middle point and that can be seen as a filter, and
more than one can exist and concatnate the stream.

I do not know is a good design for this codec class can be "onion like"
or "serial like".
Onion like is like the class has pointers to other codec itself and
calls the other class internally. So each class call it's father/son
(depends on how you like to assemble them bottom up or top down) and
return the final buffer.
Serial like is like we have an external filter manage that manages the
order of the filters and they get called from outside in the given
order and the buffer is passed externally.

I personally like more the "serial like" design, but that is probably
because I am more a C coder than C++ one. I really would like to hear
some suggestion on it.

So the thing is open for comments, awaiting you.


Regards,
Gabriele Dini Ciacci


----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

Re: [Linux-wildo-devel] dataserver packets

[Benjamin P. <Ben...@ar...>]

Hi,

Gabriele Dini Ciacci wrote:
> [A ... B ... C]
> A big note is that I have NO idea of which is faster or less resource
> consuming, and I would like to hear opinions of everyone on that.
> 
> The other BIG note is that those functions are called very often,
> probably about every 20ms and we want them to be fast. Instantiating a
> class that managed the packet itself instead of a struct looks to me a
> bit too slow.
> 
> 
> Currently I like idea B/C, C allows us to go on with current code more
> easily cause the modifications touch a few the structure, (you just call
> a different function after setting up the chain that is anyway done in
> some new function).
> 

I would say to go with C, it is the solution I would have thought of and
it is most flexible and OOP like. There is also the possibility to
disable filters temporarly and change the whole set of filters easily by
changing the "filterManager" (TM).

I don't think you need to change the filters a lot.

But a good thing if you are concerned about speed is to implement some
buffering to the whole wildo structure. If there is data for about a
half second buffered the codec, filter and network transport wouldn't be
used that frequently and the overhead for virtual methods becomes
marginal. But it is also something we could do when the application is a
bit more stable.


regards,

Benjamin Peter

[Linux-wildo-devel] dataserver packets

[Gabriele D. C. <dar...@io...>]

I am currently rewriting all the dataserver packet structure, this is
basically managed by a few functions but i think it is worth to know
what you think about those 2 ideas and which one is better for you.

We have decided to send along with each data packet (containing the
audio data or whatever) an informational struct that currently contains
the uid (and is planned to contain only it to keep it small, but if
needed can contain something else).

Along with this we can already modify how the payload of those packet
is created, keep in mind that currently we just read and encode the
audio but maybe in future we want to pass it througth various filters.
We can:

A) design the new filter plugin API so that it internally support
filter chains, so each filter will call the next filter on his buffer.
This is a sort of nesting or onion structure.

B) keep the current API (with few changes that are already planned)
and write a variadic AssembleDataServerPacket(DataServerPacketInfo_t
info, ...)
or similar that get called with the list of filters you want to run and
calls them in series managing the buffers internally.
That will make the Filter API much simpler.
This is sort of serialization approach.

C) like B, but you call AddFilterToChain and it gets added to a
internally managed chain of filters, then the we call a ProcessBuffer
that calls all the filters, this is faster than B for sure cause the
filter chain do not need to be re-generated after each call, but
naturally you can't change the filters on the fly cause you need to
re-generate the filter chain.
This is a serialization approach where we can probably use some more C++

A big note is that I have NO idea of which is faster or less resource
consuming, and I would like to hear opinions of everyone on that.

The other BIG note is that those functions are called very often,
probably about every 20ms and we want them to be fast. Instantiating a
class that managed the packet itself instead of a struct looks to me a
bit too slow.


Currently I like idea B/C, C allows us to go on with current code more
easily cause the modifications touch a few the structure, (you just call
a different function after setting up the chain that is anyway done in
some new function).


Best Regards
Gabriele Dini Ciacci

----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

[Linux-wildo-devel] Introduction

[Benjamin P. <Ben...@ar...>]

Hi darkschneider,

here is the introduction for the linux-wildo page you requested. I guess
now it is official. :-)

************
Benjamin “dedeibel” Peter
Developer since: May 2007

Well, I like those introducing rounds where everybody tells about
themselves, name,
age, hobbies. I usually say something like „Hi, my name is Benjamin
Peter. I am
21 years old, come from Germany and currently I am studying computer
science.“
(Maybe I should write it in a way that I don't have to update it all the
time :-) ).

Anyway, even before the start of my studies I was interested in Linux and
open source. I always wanted to contribute but never got really into it
- until
now. It started off by joining the linux-wildo channel on ircnet and
following
the discussions and progress of the project – because of my interest in
Linux gaming I know the lack of a nice open source voice communication
system and I was hoping for wildo to be success. There was my chance to
help the project becoming a success and so I had a look at the code and soon
found a way to add some improvements.

When I am not working on linux-wildo I like coding small scripts for all
sorts of
things in Perl, but now in Ruby (If you don't know it, have a look and
you will love it – I promise).

= Contribution =

Whatever is necessary

= Homepage =

http://dedeibel.sadacs.de/ - A bit out of date but on the TODO list

= Other Projects =

ACDA http://developer.berlios.de/projects/acda/
Currently I am working on a tool to create an index of CDs and DVDs,
which scans
the content of the disc and makes the database available via CLI, GUI,
http and will
have various export possibilities. At the moment it is developed in Ruby.

linuX-gamers.net http://linux-gamers.net/
Here I am talking with other people interested in gaming on Linux,
helping out each
other. Last year we also participated at the Linuxtag in Germany where
we had our own booth.
*********


regards,

Benjamin Peter

[Linux-wildo-devel] Timestamping codec

[Benjamin P. <Ben...@ar...>]

Hi there,

I have written a codec to measure the time from encoding a frame until
decoding. Since the codecs have a nice interface I created it as a
wrapper so that it can be used in combination with any real codec.

To integrate it there could be a bit that says use the codec with
timestamping like binary 1000. For example if 0001 is gsm then 1001
could be gsm with timestamping and 1010 would be speex with timestamping.

For testing I adopted the lwgsmtest code and made a few changes to
support other framesizes than the ones from gsm.

maybe someone can review it,


Benjamin Peter

[Linux-wildo-devel] About Tim Hentenaar code

[Gabriele D. C. <dar...@io...>]

As suggested on the IRC channel after some talking and really moved by
the fact that our current ALSA implementation is not working, I am
removing the last bits of Tim Hentenar's code, that indeed was
concentrated in the ALSA support.

Since he had no rights on the name Linux-Wildo itself and that his code
in not anymore present in the project, I am removing his name
from the copyright string.

If someone have any question or concerns about this feel free to
contact me here on the list or by private mail.

Best Regards,
Gabriele Dini Ciacci

----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

[Linux-wildo-devel] Fw: Delivery Status Notification

[Gabriele D. C. <dar...@io...>]

Begin forwarded message:

Date: Sun, 20 Aug 2006 22:51:11 +0200
From: Mail Delivery Service <pos...@aa...>
To: dar...@io...
Subject: Delivery Status Notification


lin...@li...

----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

[Linux-wildo-devel] Fw: Need a new Linux-Wildo dev?

[Gabriele D. C. <dar...@io...>]

Forward from personal mail.

Begin forwarded message:

Date: Wed, 16 Aug 2006 14:50:27 +0200
From: Gabriele Dini Ciacci <dar...@io...>
To: "Scorpyn" <sc...@us...>
Subject: Re: Need a new Linux-Wildo dev?


Hello!

I am happy you write me, looking for similar projects before starting
your own is always the best approach.

I say you in advance that we would be happy if you join us, we are
always open to get a new member in.

There is currently a totally free position for a gtk coder, cause I
already have so much work that I do not feel like to continue to fill
that position too.

If you do not like the idea of gtk coding we maybe can see for
something other, there is always lot to do.

Let me answer to your points just after them, many of them are points
where there was already lot of discussion in the past and some solution
had already been sorted out.

(continue below)

On Wed, 16 Aug 2006 01:40:34 -0700
"Scorpyn" <sc...@us...> wrote:

> 
> Message body follows:
> 
> Hi!
> 
> Short story very short, I've somewhat decided to make an 
> open source version of teamspeak/ventrilo, and before 
> starting the project I looked around a bit to see if there 
> already was such a project or not and found your Linux-
> Wildo project.
> 
> Anyway, do you think it'd be good if I joined your project, 
> or should I start my own? Keep in mind that the goals don't 
> seem to be exactly the same, and it's been a few years 
> since I've done any coding so I'll have to refresh that a 
> bit.
> 
> To give you an idea of what I want to create, here is the 
> output from my first brainstorming session :
> 
> * Test if it's possible to have different codecs for 
> different users to be able to give better sound quality to 
> the broadband users while still making it possible for 
> modem users to be able to listen 

To allow as many users as possible to use LW the best design choice was
a server oriented design. This means that all users connect to a
central server where the data flow (this is the only possible design in
non peer to peer communication, cause peer to peer distributed design
(gnutella, emule, ecc..) do not guarantee the syncing of the flows and
a low delay (notice that voice speaking is very sensible to delay, more
than what one would expect looking at the numbers).
So in your idea the problem is that it's the server that have to
multiplex various voice streams to various quality, decoding a signal
from a user, re-encoding it to appropriate lower quality/band and
multiplex it. This way you lose lot of quality cause of double decoding
encoding, and the server have a huge overhead of cpu and band usage.
This design has proved to be not only unuseful, but unproductive, 56K
users do not voice chat or use Internet for long time, people that use
a lot Internet and want to chat on it instead of using a simple phone
call on some other mobile normally get an ADSL, and ADSL is already
pretty enought for full voice use.

> * More than 1 person talking at the same time should (if 
> somewhat possible) cause that to be re-coded into 1 stream 
> to save bandwidth 

Since LW is server oriented, it's not VOIP or similar, a Massive number
of users is supposed to be able to talk. Think about MMORPG partyes
that share the same channel during a mission.

> * Encryption (on the voice aswell as the login) 

There is already a short design draft for using ssh both for voice and
login, my best friend is quite a famous expert of cryptography and he is
willing to implement it when the project ready.
 
> * No need for web interface for the server - everything 
> should be possible to manage by settings files, the client 
> etc 

Servers with web interface :DDD eheheh
Nono this is not a project for newbies, if you want to run a server you
must be able to run and manage a server. Certainly the client will
include a "start local server" option needed for fast setup, but i
never ever tought to a web interface, to be true this is the first time
ever i hear someone talking of a web interface to a LW server :)
It's an idea :)

> * Perhaps ability to listen to more than 1 port and 
> redirect to different internal servers (ts can do this 
> already) 

Never used TS, so i have no idea of what this feature is for.
Notice that lw has allready some server to server comunication, so you
shodul be able to migrate from one server to the other in the future.

> * Client and server should both be available in linux and 
> windows versions (linux server and windows client would 
> probably have higher priority in the initial phase) 
priority is as follows:

POSIX client and server (so cygwin and mingw are included)

so this include Linux, MacOSX, Windows, *BSD....
If we find someone that has a Wintendo box he will gladly become the
Wintendo mantainer.

> * tsdisp-like overlay thingy that can be customized for 
> various games (same font, borders, color scheme etc to 
> increase immersion) 

No idea what this is. LW has allready a half-done totally skinnable gtk
client, the design has been done by me and afterwards it has revealed
to be an improvement of the one used by winamp and xmms and a
siggly different approach but same feature of winamp 2 design. It is
based on XML configuration file. You can find and run examples from
LW gtk client dir, there is a doc file that give some guidelines.

If you are talking abotu something invasive in the game, this violate
security policy. You can't use a screen area taken by another
application, apart under certain limits, OSD and similar are ok.
Anyway there is no need of a real overlay, LW is studied to be
integrated inside game client with about 10 lines of code, so it's
up to the game to design another screen where you set the preferency.
What I mean is that LW GUI client is just for games not integrating LW,
the client will probably be included in the game itself, will indeed
see for a release to LGPL maybe.

> * Subchannels in more levels than what TS currently 
> supports 

LW design is: control server, where you log in, multiple data servers
controled by the same control server, you can just change data server
by changing room.

> * Channels that are invisible unless you have the rights to 
> be in them 

Current idea is that all channels are public or with a password, i do
not see why to hide an "admin" channel, anyway this is a detail, not a
feature, cause it's just a matter of who you display or send the list
of channels.

> * Possibility of making ppl in the default channel 
> automatically muted and "blind" (can't see other users or 
> channels) 

LW has half-impelented administation features, with op like irc.

> * Better versatility than ts when it comes to the ability 
> to make groups and set their permissions 

op features are irc inspired

> * Ability to autoselect codec based on who is in the 
> channel and the current traffic etc

on the fly codec switching will be possible but planned for the future.
For now it's rather easy to just create a new channel/room with a
different codec and move to it.

> As you can see, a lot of that isn't really necessary to 
> make it work - my goal would be to make something that 
> isn't just a simple alternative to ventrilo and teamspeak, 
> but it should also be better than both of them combined.

LW never aimed to be a drop in replacement for any of them. As you
have seen many features are for the future, notice that RW did not had
any of those features and until it closed it was by far more used than
TS or Ventrillo. Ease of use, successful easy design often makes the
difference and can even win marketing.

> The list of stuff to be implemented that I've read in the 
> Linux-Wildo info seems to be a lot more realistic though, 
> and definitely a good start.

Indeed, the offical list is a realistic list of things that are not
that far from beeing threre (notice that private testing allready have
sen LW working).

> Anyway, get in touch if you think I might have anything to 
> contribute. If not, I'll probably start up something new 
> from scratch.

I hope you can join us, idling on the irc channel on freenode where we
gather is a good start to get in touch and remember that joining a
project is not as easy as starting a new one, but normally it brings
to results.
 
> /Scorpyn

Best Regards
Gabriele Dini Ciacci

> --
> This message has been sent to you, a registered SourceForge.net user,
> by another site user, through the SourceForge.net site.  This message
> has been delivered to your SourceForge.net mail alias.  You may reply
> to this message using the "Reply" feature of your email client, or
> using the messaging facility of SourceForge.net at:
> https://sourceforge.net/sendmessage.php?touser=1576176
> 


----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

Re: [Linux-wildo-devel] Command line arguments list

[Steffen P. <kr...@gm...>]

On Wed, 22 Feb 2006 22:33:32 +0100
Gabriele Dini Ciacci <dar...@io...> wrote:

> Here is a list of which command arguments can be useful, this is nor
> complete nor definitive, it's just a list of those that come to mind.
> 
> I ask everyone to contribute if they find anything more is needed.
> 
> Feel free to propose more appropriate/intuitive letters for the list.
> 
> -n --nickname "nickname"
> -s --controlserver "controlserveraddr[:port]"
> -d --dataserver "dataserveraddr[:port]"
> -a --audioplugin "audioplugin" 
> --audiodevice "audiodevice"
> 
> No more come to mind... I am sure there are more!

Hi,

attached is the updated source of my popt testcode with support for the commandline arguments from your mail.

-- 
Hypnos powered by LFS SVN-20041206 (Linux 2.6.15.4)
	visit 	http://www.kratz00.org/
		http://liflg.org/

Best regards, Steffen Pankratz.
 
PGP PUBLIC KEY: http://www.kratz00.org/kratz00.at.gmx.de.asc

[Linux-wildo-devel] Command line arguments list

[Gabriele D. C. <dar...@io...>]

Here is a list of which command arguments can be useful, this is nor
complete nor definitive, it's just a list of those that come to mind.

I ask everyone to contribute if they find anything more is needed.

Feel free to propose more appropriate/intuitive letters for the list.

-n --nickname "nickname"
-s --controlserver "controlserveraddr[:port]"
-d --dataserver "dataserveraddr[:port]"
-a --audioplugin "audioplugin" 
--audiodevice "audiodevice"

No more come to mind... I am sure there are more!



----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

Re: [Linux-wildo-devel] Sound in/out on the client

[Gabriele D. C. <dar...@io...>]

First of all one consideration, it' sad that now that we have some
traffic on the ML 2 people just unsubscibed... I hope that when we go
out with new version some of them will come back.

Hi Robert, here I'm with the answer, it's divided in 3 parts:

1) current code:

Current code is a real fast thing that is there just to have audio
something working, currently at compile time you have to choose which
audio support have, but you can choose to have more than one, and the
code generated will try to use one the best one, so yes it's like you
have only one at compile time, /dev/dsp is hardcoded too. I think
that best would be to read the device setting from a
configuration file and in the future when we get one we will store the
default value there that the gui/client frontend will have the duty to
set it at startup.

2) old plugin code:

Time ago out plugin master gros allready rewrote that part of code to
not be anymore a crap static fast thing to be plug in style. So we got
a loader and al other nifty things. That code did not got integrated
yet due to the pending need to clean and reorganize the cvs and dues to
the fact we was going out with alpha.
Those question moved our attention to the fact that going out with an
alpha 0.2.0 without a so important change as the plugin was nonsense,
cause when plugin would be integrated that would have required another
minor release for sure (0.3.0) and this was a non sense.

3)

Here we arrive to recent (1 month or so). I decided to delay alpha
until I could integrate all gros code and redesign the client API to
have it readable. Currently there are many legacies on the order in
which you have to call client API function and the reason/behavor is
not always clear.
When I communicated gros about that I was goign to integrate his code,
I talked him about a nifty filter/codec plugin structure I have thought
about, he liked the idea and said me to freeze cvs until he can
integrate such a thing.
So when gros will be done we will probably have stack for message
reporting and plugin support for both audio and codec.

Now extra, as you higligthed we miss a function in the audio api for
settign the device, you are rigth and that is a serious miss.
What about a:
int LW_Sound::set_device(char *device)

lwplaytest is a nice small program used to test audio support.. just now
as you see it works only for the hardcoded oss, idea was to make it able
to load any plugin (gros allready did that, we both have the source I
think). Last time gros tested ALSA it showed some weakness that need
fix. Portaudio is another thing I will fix when i have time, and after
ALSA works.
ESD support would be nice as SDL, the main problem is to write decent
configure scripts so that compilation is smooth.
So if you feel like you are willing to test you could write ESD
support, when plugin goes in we will convert it to plugin, it's not
complex. The API is in lw_sound.h apart the function from above, that
after your mail, is scheduled for addition.

Ciao,
Gabriele

On Thu, 9 Feb 2006 20:33:21 -0500
"Robert A.M. Diamond" <ram...@gm...> wrote:

> Hey guys,
> 
> 	This is DeadRAM on IRC. Was looking over the lwplaytest in the current
> cvs (can't wait for the new stuff to be commited to cvs :P). Looks to me
> like the client will have to be built with say, OSS sound support (for
> playback and recording). If someone wanted to change over to portaudio,
> or alsa, they would have to rebuild the client. I'd prefer it if they
> set an option durring build time to include all the types of sound
> support they wanted, and then configured thier client to use OSS, or
> ALSA, or whatever. I havn't seen the client code yet, so I might be
> wrong about this. If it is the case though, I wouldn't mind writing some
> code to let people choose say, /dev/dsp as thier OSS in/out device, or
> 127.0.0.1:8000 as thier ESD in/out device. Couldn't find gros or dark on
> IRC, and I'll be away for most of tomorrow, so I figured I'd make this
> post. I think my days are your nights anyways 0.o
> 
> My gpg key is attached.
> 
> -- 
> Robert A.M. Diamond
>   <ram...@gm...>
> 
> Sentimentality -- that's what we call the sentiment we don't share.
> 		-- Graham Greene


----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

[Linux-wildo-devel] Sound in/out on the client

[Robert A.M. D. <ram...@gm...>]

Hey guys,

	This is DeadRAM on IRC. Was looking over the lwplaytest in the current
cvs (can't wait for the new stuff to be commited to cvs :P). Looks to me
like the client will have to be built with say, OSS sound support (for
playback and recording). If someone wanted to change over to portaudio,
or alsa, they would have to rebuild the client. I'd prefer it if they
set an option durring build time to include all the types of sound
support they wanted, and then configured thier client to use OSS, or
ALSA, or whatever. I havn't seen the client code yet, so I might be
wrong about this. If it is the case though, I wouldn't mind writing some
code to let people choose say, /dev/dsp as thier OSS in/out device, or
127.0.0.1:8000 as thier ESD in/out device. Couldn't find gros or dark on
IRC, and I'll be away for most of tomorrow, so I figured I'd make this
post. I think my days are your nights anyways 0.o

My gpg key is attached.

-- 
Robert A.M. Diamond
  <ram...@gm...>

Sentimentality -- that's what we call the sentiment we don't share.
		-- Graham Greene

Re: [Linux-wildo-devel] parse_server_address_port function

[Steffen P. <kr...@gm...>]

On Fri, 3 Feb 2006 17:25:36 +0100
Gabriele Dini Ciacci <dar...@io...> wrote:

> 
> The work was "simple" but the outcome superb :)
Thank you.

> You risk to get lot of work :P
No problem :)
 
> Regards and Compliments
> Gabriele Dini Ciacci
> 
> 
> P.S. to all
> Next duty will be for an artist, we need all set of gfx for the client
> skin, now I'm using Zajin exit button and other gfx from me.
> 
> On Fri, 3 Feb 2006 16:08:56 +0100
> Steffen Pankratz <kr...@gm...> wrote:
> 
> > Hi to all on the list.
> > 
> > If you have other 'simple' task don't  be afraid of asking me to do it :)
> > 
> > -- 
> > Hypnos powered by LFS SVN-20041206 (Linux 2.6.15.2)
> > 		http://www.kratz00.org/
> > 		http://liflg.org/
> > 
> > Best regards, Steffen Pankratz.
> >  
> > PGP PUBLIC KEY: http://www.kratz00.org/kratz00.at.gmx.de.asc
> 
> 
> ----------- 
> http://linux-wildo.sf.net
> http://www.diniciacci.org
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Linux-wildo-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-wildo-devel
> 


-- 
Hypnos powered by LFS SVN-20041206 (Linux 2.6.15.2)
	visit 	http://www.kratz00.org/
			http://liflg.org/

Best regards, Steffen Pankratz.
 
PGP PUBLIC KEY: http://www.kratz00.org/kratz00.at.gmx.de.asc

Re: [Linux-wildo-devel] parse_server_address_port function

[Gabriele D. C. <dar...@io...>]

The work was "simple" but the outcome superb :)

You risk to get lot of work :P

Regards and Compliments
Gabriele Dini Ciacci


P.S. to all
Next duty will be for an artist, we need all set of gfx for the client
skin, now I'm using Zajin exit button and other gfx from me.


On Fri, 3 Feb 2006 16:08:56 +0100
Steffen Pankratz <kr...@gm...> wrote:

> Hi to all on the list.
> 
> If you have other 'simple' task don't  be afraid of asking me to do it :)
> 
> -- 
> Hypnos powered by LFS SVN-20041206 (Linux 2.6.15.2)
> 		http://www.kratz00.org/
> 		http://liflg.org/
> 
> Best regards, Steffen Pankratz.
>  
> PGP PUBLIC KEY: http://www.kratz00.org/kratz00.at.gmx.de.asc


----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

[Linux-wildo-devel] parse_server_address_port function

[Steffen P. <kr...@gm...>]

Hi to all on the list.

If you have other 'simple' task don't  be afraid of asking me to do it :)

-- 
Hypnos powered by LFS SVN-20041206 (Linux 2.6.15.2)
		http://www.kratz00.org/
		http://liflg.org/

Best regards, Steffen Pankratz.
 
PGP PUBLIC KEY: http://www.kratz00.org/kratz00.at.gmx.de.asc

[Linux-wildo-devel] Some news from irc

[Gabriele D. C. <dar...@io...>]

I send this e-mail cause maybe someon can think that the fact that none
write here is because the project is dead :)
Nope! We just really use irc a LOT!

This log was enought interesting to be spread a bit.

Best Regards
Gabriele

<lauwenmark> Is that another LW version ?
<darkschneider> nope :)
<darkschneider> but he wants to try from about weeks
<darkschneider> so i'll give him some time :)
<darkschneider> i'm still workign on the codec move to dataserver
<darkschneider> i have to decide who dictates the codec and how...
<darkschneider> if it's the client, i have to add some packets for the
client to comunicate the control client what codec to use <lauwenmark>
I'd say that the room creator defines it. <darkschneider> yeah
<darkschneider> room creator/room admin
<lauwenmark> As for "how", I'd say "as a parameter of the room creation
request" <darkschneider> for now room admin is just one user, in the
future we have to change that to somethign array <darkschneider> mmm
the how <darkschneider> so you think it's better so..
<lauwenmark> Well, it sounds simple, yet doesn't create new issues.
<darkschneider> i was thinkng to addding a a COTS_SET_CODEC
<darkschneider> CTOS
<darkschneider> cause there is no real reason why you can't change the
codec in the middle of a reunion <lauwenmark> Except that all peers
will have to change as well, which may be impossible if they don't have
to correct codec. <darkschneider> you change it, server brodcast it to
all clients, they stop threads, deinstantiate old codec , instantiate
new, start thread again <darkschneider> yes, that true... if a client
does not have the new codec, he will just get an error <lauwenmark>
Then you have to define a set of permissions to give some users the
right to change codecs. <darkschneider> putting the codec option on
servercreation/room regustration would force to deresiter the room and
reregister it (all klikets kicked) <darkschneider> mmm that has some
sense <darkschneider> but now there is just admin and normal user
<darkschneider> mmmm what about admin list users that have special
permissions, and the client struct contains what are those permissions
<lauwenmark> Or you could have it the fun hard way, and make the
dataserver handle the datastreams in a codec-independent way
internally, converting the stream content on the fly for each client :)
<darkschneider> admin is a var in dataserver struct that hold the uid
of admin users <darkschneider> eheh that woudl requite a cluster of
power :P <darkschneider> ok now dinner <lauwenmark> :) <darkschneider>
i'll go for CTOS_SET_CODEC cause i liket he idea of beeign able to
change codec, for now only the room creator (that is all power admin)
will be able to set the codec <aGu> Sorry, I have to go to sleep, maths
exam tomorrow <aGu> Good night <lauwenmark> cya <darkschneider> ok :)
<lauwenmark> (around 500 CPS on the typing test, BTW, although I'm
noticeably slower in English than in French, obviously) <darkschneider>
500 CPM :) <darkschneider> or you have 50 fingers :) <lauwenmark>
yeah :) <darkschneider> lw clietn si terrible :( <lauwenmark> howso ?
<darkschneider> i really need to clean it's interface <darkschneider>
uggly interface... <darkschneider> was really inexperienced when i
wrote it... <darkschneider> interface/API <darkschneider> have to
recheck instatiation of threads audio and codec sequence to be sure
they can be executed in the rigth order... <lauwenmark> Yep. A simple
flag/trigger should enforce that <darkschneider> mm i just figured out
that i ned to change thread structure <darkschneider> the thread should
read the socket even if audio interface or codec are not instatiarted..
<darkschneider> and trash the data <darkschneider> or when we
instantatiate the missing thing we frinsih up with a LOAD of data to
read <darkschneider> (resulting in a permanent delay that can be teaken
out only if the other side does not send data for soem time)
<darkschneider>   STOC_CODEC_NIAR   Not In A Room <darkschneider> have
a better idea for that scronim? <darkschneider> acronim <lauwenmark>
mmm <lauwenmark> When is that message sent ? <darkschneider> when the
client ask for soom codec and he is not in a room <darkschneider>
soom/room <darkschneider> mm STOC_CODEC_NOROOM is better <lauwenmark>
yep <darkschneider> :)
<darkschneider> i somehow love that adding a new command to lw is
trivial... <darkschneider> parsing it in the client is terrible...
<darkschneider> nonono i'll rewrite the client structure asap
<lauwenmark> :)
* darkschneider hoped to hear someone saying "I will do it" apart his
own voice in his own brain :D <lauwenmark> heh
<lauwenmark> Well, once the protocol is frozen, then I'll do it :)
<darkschneider> hehe
<darkschneider> i hope that you will write a GUI only cause the client
API will be so nice to not ned a reqrite :P <lauwenmark> :D
* lauwenmark just got a request from a girl to send her a drawing :)
<darkschneider> eheh :)
<darkschneider> i said you draw good :)
<lauwenmark> lol
<darkschneider>  * added get_dataserver_by_rid()
<darkschneider> is that name enougth clear?
<darkschneider> i want clear function names..
<darkschneider> get_client_by_uid is the next on the list
<darkschneider> aaghhh, design flaaw
<darkschneider> ok too tired to fix it now...
<lauwenmark> Yes, it looks clear e,ough
<darkschneider> register_dataserver is a bad function cause it
creates_dataserver too :( <lauwenmark> Call it
"get_dataserver_instance", then :) <darkschneider> i'm splitting it to
create_dataserver and register_dataserver so it's the same as client
and controlserver <lauwenmark> yup <darkschneider> the list managemnt
fucntions are not so bad.. <darkschneider> maybe cause it's the 10th
time i write a complete list interface
* darkschneider for soem reason allways end up to use lists a lot
<darkschneider> to use/useing
<lauwenmark> Well, I often start by coding/reusing a list and a stack
implementation in my projects, because I use both a lot <darkschneider>
stack impelentation.. ahhh dream it :) <darkschneider> we neeeeeeeeeed
some nice implementation for audio filters... <lauwenmark> lol, that's
not very hard to implement :) <lauwenmark> yes
<darkschneider> so codec willbecome an audio filter..
<darkschneider> and i can normalize and denoise audio
<darkschneider> but i have totally no idea abotu such thing..
<lauwenmark> Ideally, the interface should provide an input, a plug to
get warned about output, and an information method <darkschneider> you
need to load filter module and such.. <darkschneider> yeah
<darkschneider> so codec realoding will be just a case of a audio
filter load <darkschneider> but ihave no skills to write sucha thing..
<darkschneider> and i prefer to go and look xmms code and copy their
interface <darkschneider> what about lw looking like xmms
<lauwenmark> The input part is easy: just use something like
send_audio_chunk(data); as for output, create an
add_audio_listener(functionpointer_to_callback) <lauwenmark> (with
functionpointer_to_callback being an int fnstuff(data)) <lauwenmark>
(and store all callbacks in a dynamic array in the codec. Case
solved :))
<darkschneider> wow
<lauwenmark> And given that callbacks would have the exact same
prototype as the send_audio_chunk() methods, you can transparently
chain as many codecs as you want <darkschneider> dynamic array.. we
need allready some <lauwenmark> Sure - Vector or Chained lists would do
the job. <darkschneider> adding more chained lists.. <darkschneider> mmm
<darkschneider> ithink we will go for vector...
<darkschneider> even if it's really c++
<lauwenmark> (oh, and you'd need a "remove_audio_listener" as well, so
you can "unplug" something as well) <darkschneider> i'll leave to
youimpemenation of all vectors to sho you my generousity <lauwenmark>
lol <darkschneider> :)
<lauwenmark> There's already a Vector class in the STL if I'm correct,
though <darkschneider> yeah
<darkschneider> i need free_packet() functions tooo .... uffff lot of
work... <darkschneider> every line of code i discover i need 100 more
lines :( sometimes i really do nto see the end <lauwenmark> mmm
<lauwenmark> Well, at least you see a working result now - that's
pretty nice <darkschneider> yes.. not even if lw is "working" none
belive in it :(( <darkschneider> i mean a guy taking cvs can't manage
to use it ;:( <lauwenmark> Well, sure, but we'll work to improve that
for sure :) <lauwenmark> Are you planning to modify a lot of things in
the protocol ? <darkschneider> not so many
<darkschneider> i mean OLD things, nope
<darkschneider> none, the only one was this one related to codec
<darkschneider> adding, many.. since there are still many old things
<darkschneider> makfiles need to be cleaned
<darkschneider> and conditional compilation of alsa added
<darkschneider> alsa/ alsa speex and so on
<darkschneider> so we need some AC_SUBST(@ALSA_OBJ@) and so on
<lauwenmark> mhmh. So make the CVS up to date, so I'll use my free time
Tomorrow to rewrite the audio plugins interface <darkschneider> i have
no words... <darkschneider> i can jsut say thanks...
<lauwenmark> You can just say: "and move your ass, so that the plugins
interface is finished in 24 hours !" :) <darkschneider> i'll commit
when i have done (cut the code in cvs will not anymore able to talk,
cause CTOS_SET_CODEC will be impelemented not today) <darkschneider>
cut/but <darkschneider> eheh gros youa re realling helping a lot with
lw <lauwenmark> lol, I don't think so :) <lauwenmark> I'm better at
telling stories faster than hoxu, for what matters :D <darkschneider>
naaa <darkschneider> btw, a thing i fogot to say to you last time,
there is no need to reimpelnet module loading, i have yoru local copy
on my add and plan to merge it asap i can work on makefiles (i didn0t
liked the thing you needed to install the library system wide to have
lw working, it isn't nice in thsoe time fo developemnt.. they chagne
too often) <darkschneider> and you added too many directories to
lw_audio :SD <lauwenmark> lol - one directory per plugin :)
----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

Fw: [Linux-wildo-devel] Members removal

[Gabriele D. C. <dar...@io...>]

As announced tomorrow I will provide to remove developers that did not
replied to the old mail I am forwarding.

All the code from Vanya has been rewritten, since he dropped server
development, when I took it I rewrote the two hundred lines he had
committed.

All code from Tim has been took out as been considered not of much use.

Code from Shawn is still in the cvs and I hope it will stay there for
all project life since at current state it look like a good work even
if it would need some renewal (the API has 1 more function to be added).
Moreover PortAudio is the planned audio API for Mac and Win.

Best Regards
Gabriele Dini Ciacci

Begin forwarded message:

Date: Mon, 10 Oct 2005 23:52:28 +0200
From: Gabriele Dini Ciacci <dar...@io...>
To: linux-wildo-devel <lin...@li...>
Subject: [Linux-wildo-devel] Members removal


If none of the interested replies to this message I will remove them
from sf project page :)
It's time to clean it a bit up.. In a year i was the only one to code
at least a single line of lw :)
So I consider you inactive members :)

Enlisted for removal (deadline the 25 of October):

matriarktervel	Tim Hentenaar	Developer
shadowjack_cp	Shawn Lavin	Porter (Cross Platform Devel.)
vsergeev	Vanya Sergeev	Developer


Best Regards
Gabriele Dini Ciacci

P.S.
I hope you reply and start back supporting the project :)


----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-wildo-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-wildo-devel


----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

[Linux-wildo-devel] Members removal

[Gabriele D. C. <dar...@io...>]

If none of the interested replies to this message I will remove them
from sf project page :)
It's time to clean it a bit up.. In a year i was the only one to code
at least a single line of lw :)
So I consider you inactive members :)

Enlisted for removal (deadline the 25 of October):

matriarktervel	Tim Hentenaar	Developer
shadowjack_cp	Shawn Lavin	Porter (Cross Platform Devel.)
vsergeev	Vanya Sergeev	Developer


Best Regards
Gabriele Dini Ciacci

P.S.
I hope you reply and start back supporting the project :)



----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

[Linux-wildo-devel] More work going on

[Gabriele D. C. <dar...@io...>]

Ahh! Cheers to everyone.
I have took this full week end to work 24h on 24h on lw so I have coded
many interesting lines in a lovely delirium.

There are quite some nice news, enought to release a 0.1.7 version,
but, here comes the but, I am really near to an alpha.

What an alpha means? It means alpha version! As announced years ago on
plans alpha version has basic voice support, that means you can try to
talk and hope some voice come back.

I am not far from it, just some missing part of code, but it is limited
to say 200 lines, things you can do in a day, maybe today.

Today I just tested 3 way communication with a control server running a
data server running and me on a client.
The client logged in on the control server, then it publicized the
data server and the control server answered registering that data
server. Then the control server authenticated on the data server and
data server replied to it successfully.

Now the only part that is missing is the client asking authorization to
control server to log in a channel (a data server) and then actually
authenticating on the data server.

This involves me to add some tricky packets like STOC_JOINROOM_ACK that
contains a sensible session-id ticket and some low level UDP
communication to client, will see what happens.

As Last things, but not least, there is a shocking piece of a news, I
do not like anymore how client class is currently designed and it can
happen I switch to a select() for client too as opposed to
user-event-driven interface as it is now. This will frankly happen only
after alpha and if everything goes real right or real bad since the
few flexibility of client forces me to do that earlier.


Best Regards
Gabriele Dini Ciacci

P.S.
Maybe I will give a shot to the last of 0.1.x series with this 0.1.7
release


----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

[Linux-wildo-devel] Cvs changes

[Gabriele D. C. <dar...@io...>]

Hello all,

Just to advise anyone that I am coding and reorganizing the
server code and if none asks for, I will delay release to cvs until the
code compiles again.

Regards
Gabriele Dini Ciacci



----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

[Linux-wildo-devel] Making some order

[Gabriele D. C. <dar...@io...>]

Hello all,
After months of quietness, after some real bad personal problem, after
today it rained as hell, after I made a gentoo distro look perfect,
after I burned backups of everything, after I manually merged 3
different Mail dirs in 3 different mail formats into one, there is
really nothing anymore useful I can do apart ordering the lw
cvs.

Ordering the cvs means removing Vanya Sergeev code that is quite a good
server code, but it is old and unmaintained, since [VS] ghostized.

This mean that the next time the above unbelievable sequence of
events happens I will be able to start coding the data server myself.

Don't be too anxious if you can't keep it for months at least, anyway
life.. ehm, linux-wildo flows.

Best Regards to Everyone
Gabriele Dini Ciacci

----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org

[Linux-wildo-devel] Release

[Gabriele D. C. <dar...@io...>]

Hello all.

I did a new release at sf before a maybe long time without.
I need to code some data part that still require some minor design, so it can 
take a lot if I encounter issures.

Now everyonce can test and see current state, that I would define pretty 
stable and nice.

Thread code is back there, but we still using posix threads. To keep using 
those I was constricted to use a staric wrapper, a bad thing in some way.
We will move to Boost::Threads when we have time.

You can test thread code with the client, press h and see the help (press t to 
call blindly the thread function)

That is all.

Regards
Gabriele Dini Ciacci

-- 
http://www.diniciacci.org
http://linux-wildo.sf.net

Re: [Linux-wildo-devel] Greetings

[Gabriele D. C. <dar...@io...>]

On Tuesday 31 August 2004 21:36, Daniel Cabezas wrote:
> On Tue, 31 Aug 2004 21:35:20 +0200, Gabriele Dini Ciacci wrote
>
> > [endless number of retryes....]
>
> Greetings,
>
>
> Oh, my god! I think in spite being on september exams I should ahve
> answered the first mail in the chain :P
>
> (...)

Sorry, I was not sure you was reciving this, and I wanted a copy of this in=
=20
the list, but list copy allways get refused. Sorry again for so much mailin=
g=20
:) I'm on exam too and I know what it means.

> > Current state is not bad, I work on it on spare time left my my uni
> > and by my gf. We have many test programs working, one test the gsm
> > codec, one test the logger, one test the data server, one test the
> > control server and one is the client. I'm happy with current state,
> >  only 2 big pieces of code are missing, first is the rewrite of the
> > audio read/write threads and the other is the exchange of
> > information with the server about the data server address. In this
> > last one I need some time thinking to a flexible way since I want to
> > leave the ability to have a data server separated from control
> > server, maybe running on another machine.
>
> Ok, thank you very much.
>
> > So I'm happy with the state.
> > I coudl define current state "one in witch we need help" :)
>
> I think that neither linux kernel can deny help offered :) (perhapss
> Microsoft can? )
>
> > We need a windows coder, since our windows support now is zero, we
> > need windows audio support and very important someone that can
> > actualy try to build lw on windows, showing where the
> > incopatiblities are.
>
> Ok, so after exams I=B4ll begin examingin the code.
>
> > So I'm happy if you want to help and you are welcome in the team.
> >
> > Much talking happen on irc channel since it's often faster than
> > email. We leave e-mail for things that must remain in the archive,
> > like improtant modifcations, brainstormings and such. Anyway mailing
> > list is allways a good place to write if you need answers. So if you
> > want to come aboard wellcome aboard.
>
> That=B4s what I=B4ll do, #linux-wildo, here I come.
>
> See you,
>
> Daniel
>
> > Best Regards
> > Gabriele Dini Ciacci
> >
> > On Thursday 19 August 2004 19:21, Daniel Cabezas wrote:
> > > Hello, all
> > >
> > > I recently foun linux-wildo project through freshmeat directory,
> > > searching for teamspeak, ventrilo and similar programs available for
> > > Linux. Wildo=B4s pllaned features actually seem very interesting, whi=
ch
> > > is ths state of the project as of now ? Perhaps I could help a bit,
> > > mainly whith windows programming, as it is the main platform am I
> > > developing nowadays.
> > >
> > > See you,
> > >
> > >
> > > Daniel  . -------        daniel_at_seriousworks.net
> > >              /Cabezas  SeriousWorks Solutions, SCP
> > > ______/                 Barcelona, Spain
> > >                              www:    http://www.seriousworks.net
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> > > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> > > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> > > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> > > _______________________________________________
> > > Linux-wildo-devel mailing list
> > > Lin...@li...
> > > https://lists.sourceforge.net/lists/listinfo/linux-wildo-devel
> >
> > --
> > http://www.diniciacci.org
> > http://linux-wildo.sf.net
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by BEA Weblogic Workshop
> > FREE Java Enterprise J2EE developer tools!
> > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > http://ads.osdn.com/?ad_idP47&alloc_id808&op=3Dclick
> > _______________________________________________
> > Linux-wildo-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linux-wildo-devel
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
> _______________________________________________
> Linux-wildo-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-wildo-devel

=2D-=20
http://www.diniciacci.org
http://linux-wildo.sf.net

Re: [Linux-wildo-devel] Greetings

[Daniel C. <da...@se...>]

On Tue, 31 Aug 2004 21:35:20 +0200, Gabriele Dini Ciacci wrote
> [endless number of retryes....]

Greetings, 


Oh, my god! I think in spite being on september exams I should ahve answered
the first mail in the chain :P

(...)
> Current state is not bad, I work on it on spare time left my my uni 
> and by my gf. We have many test programs working, one test the gsm 
> codec, one test the logger, one test the data server, one test the 
> control server and one is the client. I'm happy with current state,
>  only 2 big pieces of code are missing, first is the rewrite of the 
> audio read/write threads and the other is the exchange of 
> information with the server about the data server address. In this 
> last one I need some time thinking to a flexible way since I want to 
> leave the ability to have a data server separated from control 
> server, maybe running on another machine.

Ok, thank you very much.
> 
> So I'm happy with the state.
> I coudl define current state "one in witch we need help" :)

I think that neither linux kernel can deny help offered :) (perhapss Microsoft
can? )


> We need a windows coder, since our windows support now is zero, we 
> need windows audio support and very important someone that can 
> actualy try to build lw on windows, showing where the 
> incopatiblities are.

Ok, so after exams I´ll begin examingin the code.
> 
> So I'm happy if you want to help and you are welcome in the team.
> 
> Much talking happen on irc channel since it's often faster than 
> email. We leave e-mail for things that must remain in the archive, 
> like improtant modifcations, brainstormings and such. Anyway mailing 
> list is allways a good place to write if you need answers. So if you 
> want to come aboard wellcome aboard.

That´s what I´ll do, #linux-wildo, here I come.

See you,

Daniel
> 
> Best Regards
> Gabriele Dini Ciacci
> 
> On Thursday 19 August 2004 19:21, Daniel Cabezas wrote:
> > Hello, all
> >
> > I recently foun linux-wildo project through freshmeat directory, searching
> > for teamspeak, ventrilo and similar programs available for Linux. Wildo´s
> > pllaned features actually seem very interesting, which is ths state of the
> > project as of now ? Perhaps I could help a bit, mainly whith windows
> > programming, as it is the main platform am I developing nowadays.
> >
> > See you,
> >
> >
> > Daniel  . -------        daniel_at_seriousworks.net
> >              /Cabezas  SeriousWorks Solutions, SCP
> > ______/                 Barcelona, Spain
> >                              www:    http://www.seriousworks.net
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> > _______________________________________________
> > Linux-wildo-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linux-wildo-devel
> 
> -- 
> http://www.diniciacci.org
> http://linux-wildo.sf.net
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_idP47&alloc_id808&op=click
> _______________________________________________
> Linux-wildo-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-wildo-devel