Discussion about Zinf audio player development

Building on Linux Red Hat 8 + RPMs

Hello,

On www.zinf.org there's a "Help Wanted" request out for "Linux RPM Hackers".

I'm not sure whether the binary RPMs in the 2.2.1 release will install on 
Red Hat 8; but I'm fairly certain that 2.2.1 will not build on RH8.  The 
2.2.1 build needed some minor surgery before I had Zinf 2.2.1 up and running 
here.

I've uploaded fixes for two show-stoppers to the patch-tracker.  A few other 
minor fixes are also necessary, but these two are the bare minimum needed to 
get the code running (actually, only the GCC 3.2 fix is needed to compile 
the code, but the other patch fixes some breakage in GDK font loading).

I've also built RPMS that compile and install under RH8.  They're on 
Sourceforge's shell server in /home/users/m/mr/mrsam/zinf (source and binary 
RPMs).  Kindly let me know when I can reclaim diskspace that counts against 
my shell account quota 

-------------------------------------------------------
This SF.net email is sponsored by: Microsoft Visual Studio.NET 
comprehensive development tool, built to increase your 
productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en

headers

Dan Armak | 6 Dec 18:11

zinf 2.2.1 issues with arts


Hello,

I'm making a zinf 2.2.1 package for Gentoo (currently we have 2.2.0) and it 
seems the arts plugin is broken and, in fact, disabled. That is, it isn't 
part of the default targets in Makefile-plugins, and if I make 
plugins/arts.pmo by hand the -I parameters for artsc.h and artspmo.h are 
missing.

I tried adding those via $CPATH, but then I got a missing arts_free symbol. 
This might be due to a bad link command, but anyway I'd like to know the 
official zinf.org position on this. Should the arts plugin work, and if so, 
why does it seem to be disabled in the makefiles?

Clarification: it's the same way in zinf 2.2.0 AFAICS. I'm not the maintainer 
of the package - we have growig pains and many minor packages don't have a 
single maintainer atm - we're working to remedy this situation.

Right now I've disabled arts support in our zinf package. (This being Gentoo, 
it can be changed easily at any time, so this isn't a long-term 'policy' as 
it might be in binary distros.)

Please cc replies to me, as I am not subscribed to the list.

Thanks,

--

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel

(Continue reading)

headers

A J | 12 Dec 00:58

Like to help

Hey all,

I was surfin' and came across your site and I wanted
to help with the answering e-mails (user support).  As
for the project leader what are the duties for that?

Thanks for makin' a great product!

Dimitri

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

headers

Ed Sweetman | 12 Dec 08:40

almost back

after a really "fun" semester, it's about time to get back to getting 
the subsystems for zinf3 together.  Judging from the amount of emails 
recieved here regarding any of the new code (or any code), i'd say 
interest in zinf development is as good as it is always. So press on I 
will. I think next thing i will do is adapt the ogg plugin to it and fix 
the local file input plugin so that there are examples of some plugins. 
  Then i think i'll work on the info subsystem and the main zinf class 
that handles them all ...possibly even getting a simple text interface 
going to test the infrastructure by the end of my winter break. No 
promises though.  Hard to get motivation when the feedback is less than 
enthusiastic, or even critical.  Notice i haven't said anything about 
output plugin or real UI's....they're hard.  Have i coded any network 
interfaces before? No. Have I coded any audio interfaces from scratch? 
No.  have I even coded anything that needs to be done here from scratch 
before?  Nope. Except a few exceptions, most of the implimentation of 
"subsystems" occurs across many different source files in the current 
zinf and most of the time the code that is found is so cohesive that it 
just cant be used in the new modular code.

http input shouldn't be a problem to port over, i'm surprised (well not 
really) that nobody has written the module for it. I mean the one plugin 
that looks like some design thought went into it and it's small and 
tight and nobody touches it. Of course it needs to be converted to the 
world of C++ with it's Puny :) FILE handles.

So yea, lots of fun stuff still needs to be done. I'm pretty sure this 
is going in a threadless direction for now until we get UI setup.  I say 
we in the sense that i mean I because nobody else is on this mailing 
list that is interested in recoding zinf, heh.  Of course people are 
free as ever to continue development on the current version of zinf, but

(Continue reading)

headers

Robert Hart | 12 Dec 09:55

Re: almost back

Well your in a good mood aren't you!

I'm sorry you think that nobody else cares about zinf. I entirely agree
with you comments about xmms and the like. I think even freeamp made too
many concessions to winamp (i.e. themes)

However, last time I thought about getting involved, the state of zinf3
was beyond me. You seem to have a vision - and thats great - but until
things settle down a bit, there's little I can do.

I currently use zinf2, and there are bugs in it that I think should be
fixed in the mean time. I have tried submitting patches, but these seem
to be ignored.

I look forward to seeing a new zinf, and I will get involved when I can.
Rob

-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

headers

Kristian Kvilekval | 12 Dec 12:00

Re: almost back

1. Focus on progress.

Yes, people are still involved with zinf.. however currently the project seems to be in a state
of hiatus. I have patches (lazy database loading) to commit and things I would further implement (more gtk2)
but I held back as I am waiting to see who/what else is developing. What I have heard so far is "wait a while
and things will better soon".. Soooo I wait. I don't have a lot of extra time to devote to a side project,
so I will not write code that I expect to thrown away for no good reason,
but I use zinf pretty regularly and would like to see it improve or at least remain desktop
compliant so I would be willing to give some time to these activities.

I encourage you(Ed) to continue work on zinf3 (the all singing/dancing version), but I would also
like to see patches and bug fixes submitted for the current version. I currently have no interest
in rewriting the whole thing from scratch as the current one works well enough. When the new
version has arrived at a point when code contributions would be meaningful, then I fully
expect to jump aboard, but currently there's no train in the station.

The important thing is to ensure that zinf remains useful to it's users. For me
that means that it support the latest music formats, works solidly, and is easy to use.

Currently it fits those goals. However, My desktop has moved on, the linux sound
system has moved on, and zinf has stayed the same. It's probably time to play a
little catch up. I think a rewrite would probably be a good idea, especially to
get rid of the c'isms that exist all over zinf making it less than speedy, but
I think an *incremental* rewrite is the way to go. Let's keep it real (i.e. functional).

2. Development strategy

How should future development be managed?

(Continue reading)

headers

Andreas Rottmann | 12 Dec 12:24

Re: almost back

Kristian Kvilekval <kris <at> cs.ucsb.edu> writes:

> 1.  Focus on progress.
> 
[snipped]

Can you *please* wrap your lines at ~75 chars?

Thanks, Andy
--

-- 
Andreas Rottmann         | Dru <at> ICQ        | 118634484 <at> ICQ | a.rottmann <at> gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

headers

Ed Sweetman | 12 Dec 14:58

Re: almost back


> 2.  Development strategy
> 
> How should future development be managed?
> 
> a)   Wait for new design.
> 
> zinf3 seems like it may take a while to gel into a stable state. Some
> design elements have been sketched out in emails, but that does not
> really take the place of hard design documents/ code (i.e. 
> interfaces)..   I have not seen alot of interest in cooperative 
> design (this is basically ed's baby), so we need to wait until the 
> design is worked out and presented.

I'm pretty certain i outlined the interfaces and put them up for debate 
on whether something should be added and what not. The only response i 
got though was a misunderstanding with the purpose of the base classes 
for worker objects for each subsystem. I need to fix some things with 
all the interfaces and such.  We'll see how things are after some of the 
decode subsystem is done. I got no feedback on the interfaces so i'm 
using them the way i have them.   It's gonna be a bit too late if people 
decide to mention an issue when i get done coding half to 3/4 of zinf3.

again, nobody is holding you back from playing with zinf2 and doing 
things there.  I'm just no longer interested in doing that.

> b)   Fork development
> 
> Zinf2 and Zinf3 could fork.   From the initial soundings, it seems 
> like the zinf2 codebase will only be used as scraps in the

(Continue reading)

headers

Steve Holmes | 12 Dec 19:14

Re: almost back

Like some others said before me, I too am willing to help but still
have much to learn yet before contributing.  I'm personally studying
C++ to get a better handle on the object model.  Also, previous
comments implied that I need to wait till a more certain foundation is
established before messing about with user interfaces.  I would really
like to work on the text interfaces - ncurses and command lines but I
don't want to waste my time on 2.2 if that is going to go away soon
and I really don't know where to start right now.  So like some of the
others, I sit and wait; it does not mean I'm disinterested, I'm just
waiting.  From what I've been able to understand so far, the concepts
of objects and the like make sense to me so s soon as I have something
to work off of, I'll dive in.  Hopefully by then, my understanding of
C++ will be better.
--

-- 
Please avoid sending me Word or PowerPoint attachments.
   See http://www.fsf.org/philosophy/no-word-attachments.html

-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

headers

Andreas Rottmann | 13 Dec 17:26

Re: almost back

Steve Holmes <steve <at> holmesgrown.com> writes:

[also interested in zinf development, but still learning C++]

I'd like to follow up here and say that I (also wearing my zinf debian
maintainer hat -> _/\_ ) am also interested in lending a helping
hand, but am also tied up with some other projects. I have a good
knowledge of C++, but I still have to review the code you posted some
time ago, so I can actually post some (hopefully) useful ideas for
development.

I also really would like to contribute my experience in interfacing
C++ with scripting languages (I wrote a framework for that, using a
quite different approach (-> very C++-centric) from SWIG and similiar
tools, see http://yehia.sf.net). I don't have done work on this for
some time, because I started a P2P work distribution application, but
some months I began to restructure it (making it more modular) and
implemented classes for (non-blocking, event-based IO). It would be
*really* great if we could merge efforts here and produce code that
maybe *also* of use for other (non-zinf related) projects.

Now, before I get too shameless in self-promotion, I stop - hopefully
the zinf developers can flame a bit (or comment  on the above.

Regards, Andy - who goes off to browse the ML archive for the code
stuff.

P.S: Are there sometimes people in #zinf on freenode?
--

-- 
Andreas Rottmann         | Dru <at> ICQ        | 118634484 <at> ICQ | a.rottmann <at> gmx.at

(Continue reading)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

2	June 2008
6	January 2008
1	October 2007
6	August 2006
4	July 2006
2	April 2006
4	February 2006
1	December 2005
7	September 2005
5	July 2005
8	June 2005
19	May 2005
16	April 2005
2	March 2005
8	February 2005
6	January 2005
15	November 2004
3	October 2004
7	September 2004
2	August 2004
2	July 2004
10	May 2004
7	April 2004
23	March 2004
105	February 2004
45	January 2004
6	December 2003
29	November 2003
86	October 2003
43	September 2003
146	August 2003
42	July 2003
3	June 2003
29	May 2003
44	April 2003
247	March 2003
182	February 2003
123	January 2003
88	December 2002
8	November 2002
82	October 2002
43	September 2002
36	August 2002