TR : MusicBox-0.2.9

[Peron, Stéphane]

  So I think we have some conclusion right now:

  1. Mixer should be a stand-alone application.
     That's easy, and I have one already.
     But I also want MusicBox can have a little slider bar
     to control the volume from MusicBox directly.
     Therefore, the Mixer will be splitted into
     a Mixer.bundle and a Mixer.app, which uses Mixer.bundle.
     So MusicBox can access the mixer, too.
     (Anyone need Mixer.pref ?)
Good !
And eventually Encod ( ;-) ) can access the mixer as people want to read one
track just to test if it is the good one or not

  2. cddb will be Cddb.bundle and Cddb.pref.
     So there is a global cddb setting in Preference.app.
     The only problem left for cddb.bundle
     is what's the interface for this cddb.bundle ?
     You must feed cddb.bundle with the CD information.
     Right now, my freedb classes need the number of total tracks,
     the length of each track, and the offset of each track.
     So I think an array of dictionary should be enough,
     and the keys for dictionary are just "length" and "offset".
     The count of array is the number of total tracks.
     Is this information (length and offset) available in Encod and GSburn ?
     By the way, the freedb classes I have right now use
     blocking I/O for network.
     I'll try to make it non-blocking and notify in the future.
     So beware that it will block your application when access cddb site.

     Any comment on these two points ?

Good ! But why not configuring directly from one of tree application the
cddb server with a common string like for e.g:
                default writes NSSound Cddbserver (xxx.freedb.xxxxx)

We only have to agree on a common variable. When its variable is changed
from one application, its changed  for the others that uses Cddbserver !

What do you think about ?


Stephane

>From: Andreas Heppel <address@hidden>
>Reply-To: address@hidden
>To: address@hidden
>Subject: Re: MusicBox-0.2.9
>Date: Wed, 09 Oct 2002 17:45:53 +0200
>
>On 2002-10-09 09:52:30 -0400 Yen-Ju Chen <address@hidden> wrote:
>
> > So my suggestion is put this preference into Preference.app
> > as the global setting for all the GNUstep application.
> > But I don't know whether freedb should be in Preference.app.
> > And even the freedb preference is in Preference.app,
> > we still need a place for freedb classes.
>That's exactly what I am saying. Put the preferences page into 
>Preferences.app. The bundle then would be split into two parts Cddb.prefs 
>and Cddb.bundle. The one for the settings and the other for the actual 
>work.
>
> >
> > I have also a volume control (mixer), which can be shared by
> > all the sound applications to control the sound volume.
> > But again, I don't know it should be an independent application offering
> > service,
> > or a preference bundle in Preference.app ?
> > What does the volume control do in *step ?
>Well, the mixer itself will probably be an application. I don't see what 
>else it should be. Bundles or services don't make sense to me in this case.

>It could have a prefs bundle for use with Preferences.app, but I don't know

>what it would be good for, since the mixer will be a stand-alone app. What 
>I could imagine, though, was to make mixer as a whole a part of 
>Preferences.app, thus regarding the mixer as tool to set sound preferences.

>How about that?
>
> > But as I said above, bundles can only save setting under application's 
>domain.
> > Therefore, even we use the same bundle,
> > MusicBox can't read the setting of Encod or GSburn. (I may be wrong).
>That's not true. A bundle can e.g. save into NSGlobalDomain. That's how the

>keyboard prefs bundle works.
>
> > Actually I would like to write a bundle
> > which use cdda2wav or cdparanoia (I will try it later) instead SDL for 
>CD
> > control,
>Does this make sense? cdda2wav and *paranois are rippers in the first place

>and not cd playing libs.
>
> > 2. We have to decide whether we would like to use service, bundle,
> >     or library to shared these function ?
>That depends on the single functions. You must keep in mind, that services 
>always need some data on the pasteboard. Thus, if you can think of the user

>putting some data there and then call an operation on this data it may be a

>service. If you can't put anything meaningful on the pasteboard you can't 
>use services. Then you will use a bundle offering this function. Finally, 
>bundles and libraries are the same, imho.
>
> > 3. For the preference (freedb and volume control),
> >     where would you like to put it ?
> >     Globally in Preference.app or in each application ?
>See my statement above.
>
> >
> > The final thing is that I would like to offer a high-level method
> > in freedb support.
> > Right now, instead of give it the cddb id,
> > you can simply give it the information of CD.
> > It will calculate the cddb id itself locally or through freedb site.
>That makes sense. Otherwise each app will have to calculate the id itself 
>:-(
>Let's have a bundle for freedb/cddb with a general interface like using 
>dictionaries.
>
>In any case I think we should _not_ hurry, but carefully think about 
>things. IMHO, it is ok, if the three apps run in parallel for a while and 
>come together only step by step. I'd prefer to get on with the ripper 
>bundle/prefs first (Stéphane?) and then start with cddb/freedb support as 
>prefs/bundle. If I got it right you won't be available for a while, Yen-Ju?

>If you are you might in parallel start to think over cddb (if you like this

>means :-).
>In any case I would not start to build things on other libs than SDL, 
>paranoia or whatelse _while_ re-engineering the bundles and/or services. 
>Take what we have so far and first re-build interfaces and then the way it 
>operates internally.
>
>Cheers,
>Andreas
>
>--
>Andreas Heppel
>
>Mail: aheppel at web dot de
>Home: http://www.andreasheppel.de
>GSburn.app: http://gsburn.sourceforge.net
>
>
>
>_______________________________________________
>Apps-gnustep mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/apps-gnustep




_________________________________________________________________
Join the world's largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



_______________________________________________
Apps-gnustep mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/apps-gnustep


Ce message contient des informations confidentielles ou appartenant au 
Crédit Lyonnais et est établi à l'intention exclusive de ses 
destinataires. Toute divulgation, utilisation, diffusion ou reproduction 
(totale ou partielle) de ce message, ou des informations qu'il contient, 
doit être préalablement autorisée. Tout message électronique est 
susceptible d'altération et son intégrité ne peut être assurée. 
Le Crédit Lyonnais décline toute responsabilité au titre de ce 
message s'il a été modifié ou falsifié. Si vous n'êtes pas 
destinataire de ce message, merci de le détruire immédiatement et 
d'avertir l'expéditeur de l'erreur de distribution et de la destruction
du message.
Crédit Lyonnais, SA au capital de Euros 1.807.874.827 - RCS Lyon B 954 509 741
Siège Central : 19, boulevard des Italiens. 75002 Paris. France

This e-mail contains confidential information or information belonging 
to Crédit Lyonnais and is intended solely for the addressees. 
The unauthorised disclosure, use, dissemination or copying (either whole 
or partial) of this e-mail, or any information it contains, is prohibited.
E-mails are susceptible to alteration and their integrity cannot be guaranteed. 
Crédit Lyonnais shall not be liable for this e-mail if modified or falsified.
If you are not the intended recipient of this e-mail, please delete it 
immediately from your system and notify the sender of the wrong delivery 
and the mail deletion.
Crédit Lyonnais SA.
Share Capital of Euros 1.807.874.827.
Registered Office : Lyon (B 954 509 741) 
Central and administrative Office : 19, boulevard des Italiens. 75002 Paris. 
France