headers
Ed Sweetman | 1 Nov 07:06
Favicon

some teaser code until the weekend

Tests are fun, I'd tell you about them but especially on halloween week 
they are double fun.  So yea, work is coming along SLOWLY this week and 
it angers me.   I'll have much more this weekend but i thought it would 
be fun to start the interface standardization debates now for a few of 
the major pipeline subsystems.  First off here are some definitions.

Subsystem: the subsystem is an abstraction interface meant solely for 
the ease of communication between subsystems.  They dont really do much 
on their own.  Each subsystem in the pipeline has a polymorphic worker 
object it creates for the grunt work.

Worker object: Every subsystem has them in the pipeline as mentioned 
above.  The worker object is there to actually do the function of the 
subsystem.  It allows feature upgrades to that subsystem without having 
to touch the subsystem at all, ensuring problems are confined to the 
interface in the hopes that maintainance is eased. Hopefully we can make 
each type of worker object for every subsystem some kind of module with 
a registration method to allow binary distribution of types of plugins 
without the player knowing anything about them at player compile time.

Interfaces not really materialized yet.

info object:  The info object is our way of cheating global variables. 
The info method offers a secure way of accessing all of the preferences, 
data, and states occuring in the player in any class since it's passed 
by reference to each on construction. I'm hoping the info object can 
replace signals.  The info object is constructed as a private member of 
the zinf main class.

UI subsystem: The UI subsystem is like the subsystems in the pipeline
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ed Sweetman | 2 Nov 02:42
Favicon

Re: some teaser code until the weekend

Also, which mp3 decoder should we aim as our primary mp3 decoder?  Ogg 
decoder is sort of a given since there is only one ..   Guess i'll start 
working on the ogg decoder in the meantime as we go over interface 
standardization and which mp3 decoder zinf should get (at least as a 
primary).

Ed Sweetman wrote:
> Tests are fun, I'd tell you about them but especially on halloween week 
> they are double fun.  So yea, work is coming along SLOWLY this week and 
> it angers me.   I'll have much more this weekend but i thought it would 
> be fun to start the interface standardization debates now for a few of 
> the major pipeline subsystems.  First off here are some definitions.
> 
> Subsystem: the subsystem is an abstraction interface meant solely for 
> the ease of communication between subsystems.  They dont really do much 
> on their own.  Each subsystem in the pipeline has a polymorphic worker 
> object it creates for the grunt work.
> 
> Worker object: Every subsystem has them in the pipeline as mentioned 
> above.  The worker object is there to actually do the function of the 
> subsystem.  It allows feature upgrades to that subsystem without having 
> to touch the subsystem at all, ensuring problems are confined to the 
> interface in the hopes that maintainance is eased. Hopefully we can make 
> each type of worker object for every subsystem some kind of module with 
> a registration method to allow binary distribution of types of plugins 
> without the player knowing anything about them at player compile time.
> 
> Interfaces not really materialized yet.
> 
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Steve Holmes | 2 Nov 05:38
Gravatar

Re: some teaser code until the weekend

The only mp3 decoders I'm familiar with is mpg123 and mpg321.  From
what I read recently from my Slackware Distribution, 8.1, mpg123 was
thrown out and replaced by mpg321.  Apparently there are some license
issues with mpg123 or something.  Slackware symbolically links mpg123
to the actual executable module, mpg321.

For whatever it's worth, I'd go the route with the least licensing
complications. 

On Fri, Nov 01, 2002 at 08:42:09PM -0500, Ed Sweetman wrote:
> Also, which mp3 decoder should we aim as our primary mp3 decoder?  Ogg 
> decoder is sort of a given since there is only one ..   Guess i'll start 
> working on the ogg decoder in the meantime as we go over interface 
> standardization and which mp3 decoder zinf should get (at least as a 
> primary).
> 
> 
> 
> 
> Ed Sweetman wrote:
> >Tests are fun, I'd tell you about them but especially on halloween week 
> >they are double fun.  So yea, work is coming along SLOWLY this week and 
> >it angers me.   I'll have much more this weekend but i thought it would 
> >be fun to start the interface standardization debates now for a few of 
> >the major pipeline subsystems.  First off here are some definitions.
> >
> >Subsystem: the subsystem is an abstraction interface meant solely for 
> >the ease of communication between subsystems.  They dont really do much 
> >on their own.  Each subsystem in the pipeline has a polymorphic worker 
> >object it creates for the grunt work.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ed Sweetman | 2 Nov 06:14
Favicon

Re: some teaser code until the weekend


libmp3hip is the only library mp3 decoder in debian and it wouldn't be 
there if it wasn't completely free.  mpg321 seems to be simply an 
application.

Steve Holmes wrote:
> The only mp3 decoders I'm familiar with is mpg123 and mpg321.  From
> what I read recently from my Slackware Distribution, 8.1, mpg123 was
> thrown out and replaced by mpg321.  Apparently there are some license
> issues with mpg123 or something.  Slackware symbolically links mpg123
> to the actual executable module, mpg321.
> 
> For whatever it's worth, I'd go the route with the least licensing
> complications. 
> 
> On Fri, Nov 01, 2002 at 08:42:09PM -0500, Ed Sweetman wrote:
> 
>>Also, which mp3 decoder should we aim as our primary mp3 decoder?  Ogg 
>>decoder is sort of a given since there is only one ..   Guess i'll start 
>>working on the ogg decoder in the meantime as we go over interface 
>>standardization and which mp3 decoder zinf should get (at least as a 
>>primary).
>>
>>
>>
>>
>>Ed Sweetman wrote:
>>
>>>Tests are fun, I'd tell you about them but especially on halloween week 
>>>they are double fun.  So yea, work is coming along SLOWLY this week and
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andreas Rottmann | 3 Nov 16:59
Picon
Picon
Gravatar

Re: some teaser code until the weekend

Ed Sweetman <ed.sweetman <at> wmich.edu> writes:

> libmp3hip is the only library mp3 decoder in debian and it wouldn't be
> there if it wasn't completely free.  mpg321 seems to be simply an
> application.
> 
There is also libmad0, which seems to be used by mpg321.

Andy

PS: It would be nice not to post TOFU (text above fullquote).
--

-- 
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: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
Permalink | Reply | 0 comments |
headers
Tomas Dvorak | 3 Nov 18:30
Favicon

some thoughts

Hi, here are some reactions to your code. Please excuse my english, it is
not
my native language.

1) Please use just 80 columns, I've got some trouble reading it on my
terminal :-)

2) I don't quite understand the difference between zinfStream and input
-- it
has exactly the same methods. Is (Will be) zinfStream used elsewhere, too
?
Where ?

3) I believe the zinfStream, input, decode and output classes (and most
of the
new classes yet to come :-) ought have some getError method -- f.e. if
input::GetRead returns 0, was it because we are at EOF or because the
network
connection was lost ?

4) I don't think you can get along efficiently without using signals, if
I
understood you right, all objects would have to repeatedly check whether
any
informations contained in the global info vital for them did not change.
Instead of this, they could just be informed by a signal that such a
change
has occured.

5) I wouldn't make UI the creator of the get-decode-write pipeline, the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ed Sweetman | 3 Nov 21:27
Favicon

Re: some thoughts

Tomas Dvorak wrote:
> Hi, here are some reactions to your code. Please excuse my english, it is
> not
> my native language.
> 
> 1) Please use just 80 columns, I've got some trouble reading it on my
> terminal :-)
maybe upgrade your terminal size to something bigger?  I'll go and fix the
widths but it's annoying to keep line lengths so short.

> 2) I don't quite understand the difference between zinfStream and input
> -- it
> has exactly the same methods. Is (Will be) zinfStream used elsewhere, too
> ?
> Where ?

zinfstream exists as i've said before to separate issues with upgrading 
the objects that actually do something. Also, it's not possible to make 
input the base object for a plugin system as you'd need to be able to 
discern the type of input you want in the decode subsystem, which is not 
it's job to do.  Each subsystem, input decode output ui, get a 
polymorphic worker object that they know how to create and work with. 
No other subsystem needs to know about it.   In this way zinfStream is 
necessary and serves a very good purpose.

> 3) I believe the zinfStream, input, decode and output classes (and most
> of the
> new classes yet to come :-) ought have some getError method -- f.e. if
> input::GetRead returns 0, was it because we are at EOF or because the
> network
(Continue reading)

Permalink | Reply | 0 comments |
headers
吴 汝旭 | 23 Nov 14:53
Picon

I want to port GUI of GTK1.2 to GTK2

    I think it is very important to port GTK1.2 to GTK2 in order to make 
more and more user ,zinf is better than xmms ,especially the audio 
effection  .
    Is there any body who want to do with me together?

_________________________________________________________________
免费下载 MSN Explorer:  http://explorer.msn.com/lccn/

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |

Gmane