45 controls a playlist server
48 through a graphical user interface. It connects to a music database server which reads a set of
50 files that describe recordings and their location. Currently, there is
51 one set of maps, mostly for classical music, with some jazz and other stuff
52 thrown in. These are served by
54 which presents a file system conventionally mounted at
56 The playlist, explained below, is managed by a file system implemented by
58 and normally mounted on
62 is most easily started through the
67 has four windows, which can be selected by clicking the appropriate tab
68 at the top of the window.
70 Above the tab are nine buttons and a volume slider. The
71 .ift buttons, shown below,
73 are named, from left to right,
86 when they are displayed in dark green (or red). When they are pale blue
89 The Exit button is always active; it exits the program (but leaves the playlist and music database
94 window is for browsing through the music and selecting music to play.
95 Browsing down in the music hierarchy is done by clicking button one on
96 an item. Clicking button three goes back up.
97 Clicking button two recursively adds all files below the selected item to
101 The selected music is displayed in the
104 The track currently playing is shown in the
110 button browses back to the root.
114 button empties the playlist.
118 displays a minimal on-line manual.
121 starts playing at the beginning of the play list, or at the selected track in
134 go back or forward a track at a time. The other buttons do the obvious thing.
138 flag chooses a tiny font, useful for handhelds.
142 flag creates the jukebox in a new window. Normally, the jukebox takes over
143 the window in which it is invoked.
147 flag specifies the name under which the file descriptors of the playlist and databse servers are posted
148 in /srv. This allows two or more play list servers to exist on one platform, e.g., when
149 there are several audio devices. The default value of the flag is
151 for a playlist server at
152 .B /srv/playlistfs.$\f2user\fP
153 and a database server at
154 .BR /srv/jukefs.$\f2user\fP .
160 describing the music data, builds an in-memory database, and provides
164 .BR /sys/lib/music/map .
165 It consists of a hierarchical set of
167 Each object has a type, a value, zero or more attribute-value
168 pairs and zero or more subobjects. An object consists of the
169 type, followed by its contents between curly brackets.
170 Attribute value pairs consist
171 of a single line containing an attribute name, an equals sign, and
173 The value of an object is any text not containing curly brackets or equals
174 signs. Here is an example:
186 path {classic/mahler}
189 conductor = Waart,~Edo~de
191 Symphony Nº 5 in c♯ (RFO, Vienna)
193 Radio Filharmonisch Orkest Holland
194 Edo de Waart, conductor
196 recorded: Musikverein, Vienna, May 6, 1996
200 Trauermarsch (In gemessenem Schritt. Streng. Wie ein Kondukt)
205 Stürmisch bewegt, mit größter Vehemenz
210 Scherzo (Kräftig, nicht zu schnell)
215 Adagietto (Sehr Langsam)
220 Rondo–Finale (Allegro)
230 object for the composer Gustav Mahler (the value consists of the two
231 lines `Gustav Mahler' and `(1860 — 1911)') with one subobject, a
233 object whose value is `Symphony Nº 5 in c♯ (RFO, Vienna)'. The work object
234 contains six subobjects: one
241 objects must contain exactly one attribute-value pair. The attribute
242 names a subobject of the root under which this category object will
243 be placed. Gustav Mahler, thus, will be placed in
250 objects all describe named containers for subunits.
256 object adds information to a
262 object. It should only contain text.
263 The same is true for a
265 object; however, it should only be used adjacent to
267 objects and it should contain the running time of that file (this
272 object specifies a file to be played. When the
274 button is pressed, all file objects contained hierarchically in the
275 selected object are added to the playlist.
277 There are a number of pseudo objects:
285 command sorts the subobjects of the object it appears in by
290 commands prepends numbers to the texts of its subobjects
291 (e.g., for the parts in a symphony)
295 object is replaced by the contents of the named file.
299 object specifies a key for sorting subobjects.
303 object specifies a path to be prepended to the files named in
304 hierarchically contained
308 The attribute-value value pairs arrange for entries to be made of the
311 object named by the attribute directly under the root.
314 The interface to the browsing database is through a file system
317 The file system synthesises a directory per object. Each directory contains a set of files
318 describing the object's attributes:
321 contains a new-line separated list of subobject names. For each name,
325 describes the subobject.
328 contains a one-line summary of the object
331 is a new-line separated list of file objects contained in this object.
332 Each line consists of object name and file name.
335 is the fulltextual value of the object.
338 contains the key by which objects are sorted
341 is a one-line summary of the objects and the path leading to it from the root.
342 This is the line displayed in the playlist and bottom browse windows of
346 is the object reference to the parent of this object.
349 is a full description of the path leading to this object and the object itself.
350 This is the string displayed in the top of the Browse and Playing windows
355 is the text field of the object.
358 is the type of the object
361 .BR /sys/lib/music/map :
364 Default mount point for the music database.
366 .B /sys/src/games/music