----- Original Message -----
From: "Dennis Schridde" <[EMAIL PROTECTED]>
To: <warzone-dev@gna.org>
Sent: Thursday, January 25, 2007 12:26 AM
Subject: Re: [Warzone-dev] Music playlists
> Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
> > ----- Original Message -----
> > From: "Dennis Schridde" <[EMAIL PROTECTED]>
> > To: "Development list" <warzone-dev@gna.org>
> > Sent: Wednesday, January 24, 2007 8:43 PM
> > Subject: Re: [Warzone-dev] Music playlists
> >
> > >Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
> > >> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
> > >> > I had some musings about the way this should work. Playlist script
> > >> > interface will be most used by scriptors I assume. I see two main
> > >> > occasions when such an interface might be used:
> > >> >
> > >> > 1) when it is time to interrupt any background music that might be
> > >> > played and kick in some moody piece to create atmosphere, like it is
> > >> > usually done in campaigns.
> > >> >
> > >> > 2) when someone wants to attach a custom playlist to his map, the way
> > >> > it is done with Unreal Tournament maps for example.
> > >>
> > >> Agreed.
> > >>
> > >> > As for the implementation, looks like wz uses 'tracks' to store songs.
> > >> > Track 2 corresponds to menu, track 1 to the in-game music.
> > >>
> > >> I do not think we should let that get in the way of a decent API. We
> > >> can change the way Warzone stores songs, if necessary.
> >
> > Since i'm not the one to program it it's fine with me. ;-)
> >
> > >> > When modder wants his custom playlist to be played when someone is
> > >> > using his map he either loads all songs manually to the user track
> > >> > using scripts, like
> > >> >
> > >> > playlistAddUserSong("mySong1.ogg");
> > >> > playlistAddUserSong("mySong2.ogg");
> > >>
> > >> Sounds good.
> > >>
> > >> > Since this is not the most convenient approach it might be a better
> > >> > idea to load playlist from an external playlist file, which will come
> > >> > with the mod
> > >>
> > >> Well, to me the in-script version above seems more convenient than
> > >> adding yet another file, since the number of songs will probably never
> > >> be high.
> > >>
> > >> > In case of a map with custom playlist it is simple, just call
> > >> > something like playlistPlayUserTrack(); from within the scripts (or
> > >> > again we can make wz start playing user track automatically if a map
> > >> > comes with a user playlist) for wz to switch from player playlist to
> > >> > the custom map playlist.
> > >>
> > >> I think starting the script-supplied playlist automatically seems like
> > >> the simpler and better way.
> >
> > What if the user doesn't want any music to be played at the beginning? It's
> > probably better to let the modder decide this.
> I think what Per meant is that there should be an initPlaylist function in
> the
> scripts, which is called upon mission start. If the modder doesn't want that,
> he must not provide that function.
I don't know how we jumped from playback to initialization. Anyway, for the
initialization of the playlist you just place the necessary code into the
script callback that gets called whenever a map is loaded.
>
> > >> > In cases when some music must kick in from time to time depending on
> > >> > some in-game conditions it is a bit more complicated.
> > >>
> > >> There are probably two different needs here:
> > >> 1) Scripter wants to play a short song to set the theme of some event,
> > >> then resume the playlist as normal. The new song should then not be in
> > >> the playlist afterwards.
> > >> 2) Scripter wants to change the whole theme of a level by playing a
> > >> new song or songs throughout the remaining time (or until it changes
> > >> again). So we need a way to reset the playlist; then the scripter can
> > >> add the new songs.
> > >>
> > >> So how about an API like this:
> > >> playlistReset() -- deletes existing playlist (eg to remove game
> > >> supplied playlist)
> > >> playlistAdd(song) -- adds song to top of playlist (eg to add to game's
> > >> supplied playlist)
> > >> playlistInterruptWith(song) -- play a song once, then resume playing
> > >> playlist (eg for event)
> >
> > Makes sense to me.
> Didn't say that it doesn't to me.
> Just the naming is not my favourite...
> playlistReset -> clearPlaylist
> playlistInteruptWith -> playTrack
> That was my idea... Maybe not ideal, either.
>
> > >My proposal:
> > >
> > >Function to set a playlist.
> > >Function to immediately play one track.
> > >Function to stop playlist playback and one function to resume playback.
> > >Function to set playback-modes, like repeat_all, shuffle, fadein, fadeout,
> > >crossfade.
> Those effects (not shuffle, but .*fade.*) would also affect playTrack(). If
> the modder wants something different, he can switch modes before and after
> his custom track. (Reacting to events.)
>
> > This all can surely be usefull to the end user/scriptor. Crossfades for
> > 'insertations' especially in campaigns etc.
> >
> > >Clearing the playlist is simply supplying an empty playlist.
> > >I don't think there is any need to dynamically attach a track to the
> > > playlist, am I correct? Why would one attach a song if he doesn't know
> > > when it will be played...
> >
> > You never know what's going on inside of a modder's head, it doesn't take
> > much affort to provide this functionality, besides I don't see how else we
> > would want to re-fill the list (see below).
> If there is technically no other way, yes. In my idea you could re-fill the
> list simply by setting the playlist to a list of different songs...
> But addTrack should have a switch so you can choose whether to append to the
> front or the back... (Or maybe better 2 functions addTrackFront addTrackBack,
> or appendTrack prependTrack, or similarly named.)
>
> I just got the idea of Open*L style functions... OMG... crazy...
> createPlaylist(Playlist*); // New, empty playlist
> deletePlaylist(Playlist*); // Trash it, mark pointer invalid
> bindPlaylist(Playlist*); // Switch to another playlist
> addTrack(Playlist*,Track*); // Append Track
>
> Hmmm... Actually the idea is not that bad...
> Would make it easy to handle multiple playlists, eg. one for the menu and for
> the game, or when The Modder wants to interupt the game with a few different
> songs to acompany his cutscenes or the attack of the clones... (And wants to
> switch back to the usual theme afterwards.)
>
> Implementation for createPlaylist:
> New item of a playlist-linked-list. All pointers NULL. (next, prev,
> thisTrack).
>
> addTrack:
> Walk to the end of Playlist*, check if thisTrack is NULL, yes-> set thisTrack
> to Track*, no-> append another empty item, link it in, set it's thisTrack.
>
> bindPlaylist:
> Set sound engine's nextTrack pointer to 1st item of the given list, and
> advise
> it to skipTrack() so it plays nextTrack.
>
> The linked list would perhaps become a bit unhandy when it comes to shuffling
> and repeating, but it seems very handy when binding, adding or switching to
> the next track...
>
> What do you think about this? Opinions, objections?
I don't know if linked list is best suitable for this or about other
implementation details but the idea itself sounds good, this approach is more
flexible than current one. For just the in-game playlists it may be too much,
but could be usefull when scripts get involved.
>
> > >Stoping and resuming the playlist may be interesting to create moments of
> > >total silence or when cutscenes are played.
> > >
> > >C-Functions:
> > >WZSound_setPlaylist( Song * song1, ... );
> > >WZSound_playTrack( Track interuptionTrack );
> > >WZSound_stopPlaylist();
> > >WZSound_resumePlaylist();
> > >WZSound_setPlaylistMode( PlaylistMode newMode );
> > >
> > >typedef PlaylistMode UInt8;
> > >#define PLAYLIST_SHUFFLE 0x1
> > >#define PLAYLIST_REPEAT_ALL 0x2
> > >#define PLAYLIST_CROSSFADE 0x4
> > >...
> > >
> > >C-Function examples:
> > >WZSound_setPlaylist( song1, song2, song3 );
> > >WZSound_setPlaylist( NULL );
> > >WZSound_setPlaylistMode( PLAYLIST_SHUFFLE | PLAYLIST_CROSSFADE );
> > >
> > >Script-Function examples:
> > >WZSound_setPlaylist( "song1.ogg", "song2.ogg", "song3.ogg" );
> >
> > Variadic functions won't work, we'll have to fall back to something like
> > playlistAddSong(song);
> Ok, then I'm fine with Per's playlistAdd and playlistClear functions.
>
> > >WZSound_setPlaylist( "none" );
> > >WZSound_playTrack( "event1.ogg" );
> > >WZSound_setPlaylistMode( "shuffle", "fadein" );
> > >WZSound_setPlaylistMode( "repeat_all", "crossfade", "fadeout" );
> > >WZSound_setPlaylistMode( "none" );
> >
> > Any particular reason not to use playlistSetMode() instead of
> > WZSound_setPlaylistMode()? It's shorter while preserving the same meaning.
> For the scripts I don't care.
For the scripts, yes.
> For the code I think we should develop some unique and sane naming convention
> to prevent name clashes and provide a clear and consistent API.
> That's why I came up with WZSound_. Other engine (-> lib/) parts might be
> called WZScript, WZIvis (what does ivis actually mean/stand for?) or
> WZGrahics...
>
> > >Additionally I would sent following events to the scripts (and over the
> > >internal event-bus), namings are currently very bad:
> > >playlist_stop
> > >playlist_resume
> > >playlist_nextTrack
> > >playlist_customTrack
> > >playlist_customTrackEnd
> > >playlist_modeChange
> > >playlist_new
> > >playlist_end
> > >
> > >--Dennis
> >
> > Script events would be usefull. Those would end up being named
> > CALL_PLAYLISTEND, CALL_SONGEND etc following wz convention. But those are
> > details, provide me playlist functionality I'll take care of the rest,
> > probably not until mid february though.
> 2.1 won't be released in February and probably not in March or anytime soon.
> So this currently doesn't matter that much. ;)
>
> > PS: geez am I the only one having trouble replying to attached files?
> Apparently: Yes...
Wouldn't have asked if it was apparent. I was refering to those '>' markers
actually. Don't see a way how to add them with outlook express, which forces me
to make a small detour.
Troman_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
