Re: Re: xAP-Audio schema questions....

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Comments inline...

Malcolm Green wrote:

> Hi Kevin,
>
>    
------------------------------------------------------------------------
>     *From:* Kevin Hawkins [mailto:lists@xxxxxxx]
>     *Sent:* 11 January 2005 13:49
>     *To:* xAP_developer@xxxxxxx
>     *Subject:* Re: [xAP_developer] Re: xAP-Audio schema questions....
>
>
>     Hi Malcolm ,
>
>
>        I tried to clarify this too (transport events) but didnt get
too
>     far... Edward posted a response on the 17th Dec which is quite
>     useful,
>     although it uses his own schema additions - I think it needs us to
>     all
>     'brainstorm' here to sort this. Quite happy to work fast on
>     sorting this ...
>
>        I am also right at this moment writing a xAP plugin for WinAMP,
>     partly to provide a useable xAP-audio player demo application.  I
>     have
>     taken some of my earlier proposals on this list re additions to
the
>     xap-audio schema and implemented them in this, for example I
>     update the
>     now playing every 10 secs during play and when I am in FF or REW
>     or in
>     play but within the last 10 seconds of a  track I increase this to
>     every
>     second.  I have also added the extra key values I discussed before
on
>     this list - Here is a 'WIP'  example NowPlaying message, but some
>     of the
>     fields will likely disappear eg the percent, running and status.
>
>
>  It's arguable that the time-related fields (elapsed, remaining etc)
> should be in a transport event message rather than in the
> Playlist.Event message.

Yes, maybe it does seem to far more logically sit there than where I had
them. Or perhaps the context of the information is all relative to that
particular  'track' information so should sit in the playlist info
entwined with the other related track information. It feels better in
transport...

> My view is that the Playlist.Event message should only need to be sent
> once when the current playlist track is changed, but that a
> Transport.Event message should get sent regularly (e.g. every 10 sec
> or 1 sec as you describe) to indicate changes of playing state
> (playing, paused etc) and elapsed time.

Yes....ahh just thought of a second issue though - if the
track/artist/albumname for example is only sent once  then a xAP
receiver coming online can see playback is in progress from the periodic
transport events but cant get the track name until the next track
starts, So I'm still feeling that a transport event perhaps should only
go out when the transport mode changes rather than as a periodic time
--- let me think this one over - I can see the advantages both ways...

Thought -do we include the nowplaying block in every (periodic)
transport.event message which solves this ?

>        I am considering adding other ID3 tag info though to include
>     whatever
>     information is available from there eg 'year' 'bitrate' and
>     importantly
>     trying to recover the full path info of the file which is used by
for
>     example the xAP Desktop application to display album artwork  How
>     about
>     we have an additional (optional) ID3/ID2 message block  which
seems
>     quite sensible as the key values are so defined - this
"info.ID3"
>     supplements the now.playing block in the same xAp message if tag
>     information is available
>
>
> I'm not sure about this, as the Now.Playing block already includes
> many of the main tag fields (title, artist, album, genre, duration).
> Would it not be simpler just to add extra optional values to the
> Now.Playing block for additional tags such as year, bitrate, composer,
> etc?

It's just that the ID3 tag is a good structured descriptor that may , or
may not be available, yes perhaps we could include all the tags within a
block, perhaps even labelling them as ID3Trackname I guess, If we use
just trackname are there situations where the trackname might be
recoverable from dual sources eg from a filename, stream metadata, ID2
tag and ID3 tag and we might have several choices I wonder . The ID2 tag
and ID3 tag could easily be different I guess. In fact I know  a lot of
mine are.  If we had an ID3 tag block we could also do things like
'update this file with this ID3 tag info'  which may be useful for other
applications, it seems a good block format to write up formally as a
schema or block definition even if it remains optional here .

>
>
>     xap-header
>     {
>     v=12
>     hop=1
>     uid=FF223300
>     class=xAP-Audio.Playlist.Event
>     source=UKUSA.WinAmp.lightning
>     }
>     now.playing
>     {
>     remaining=4:46
>     running=True
>     artist=ColdPlay
>     current=0:09
>     end=5:07
>     tracks=11
>     elapsed=0:21
>     title=Clocks
>     duration=5:07
>     album=A Rush of Blood to the Head
>     winampver=20488
>     percent=5%
>     start=00:00
>     index=6
>     status=1
>     }
>
>
>
>        I never managed to get clarification on the transport control
>     events
>     either , one of the original architects of that schema is
>     currently not
>     around and although I too was told there may be a later schema I
>     couldn't find one.  Edward may have some input here ?? If not I
feel
>     maybe we should just push ahead  and define something now as it is
>     required.     What do we need - I guess event names eg 'pause'
'play'
>     stop' 'FF' 'REW' 'rec'  'track+' 'track-' or something as I can't
see
>     these listed anywhere and also some other bits (?) - happy to have
>     suggestions here - unless this rumoured  'later version' schema
does
>     already exist anyone  ??  I did note Edwards comments on mirroring
a
>     similarity to BSC with the  .info and .event formats - so if I
could
>     take Edward up on his offer to clarify this ???
>
> The following is my suggestion for the Transport.Event message:
>
> *Class=xAP-Audio.Transport.Event*
>
> *Audio.Transport*
> {
> State=[playing  paused  stopped]
> Elapsed="elapsed time"
> Duration="total time"        (also in Now.Playing)
> Shuffle=[off  tracks  albums]
> Repeat=[off  one  all]
> }
>
I think we need the other states  too eg FF REW REC  Track+ Track-    -
some of these would usually be commands and some events and some augment
a state like REC could augment play perhaps. As you suggest maybe the
time events eg remaining time should go in here too . I now think we
need to include the now.playing block too though (??)

Interested as to why the other parameters , particularly say Shuffle
and Repeat are in transport rather than playlist events as I guess they
are events effecting the playlist ordering ??  Is that because it is
setting a 'mode' for playback  eg from possibly a button on the player.
So transport should reflect the sort of things you see on a front panel
of a feature rich player both in terms of buttons and displayed data
like 'time' but not track title.  Is this required demarkation between
'playlist' and 'transport' fundamentally flawed I wonder and we should
merge them, clarify the difference or perhaps use a different
segmentation ?? Just thougts...

K

>
> Regards,
> Malcolm
>
>
>         Kevin
>
>
>     ./ / - I hope malcolmcgreen wrote:
>
>     >I'm now looking at the next stage of xAP implementation in
TelCanto.
>     >I need to generate some notifications when the play status
changes,
>     >which will include the xAP-Audio.Playlist.Event (Now.Playing).
 I
>     also
>     >need an event to indicate change of transport state, but can't
>     find an
>     >event defined in the schema corresponding to the
Audio.Transport
>     >command, i.e. an Audio.Transport.Event.  Can anyone enlighten
me
>     as to
>     >whether such an event has been defined, perhaps in a later
version of
>     >the schema?
>     >
>     >Malcolm Green
>     >
>     >
>     >--- In xAP_developer@xxxxxxx, Kevin Hawkins <lists@u...>
>     >wrote:
>     >
>     >
>     >>This is a posting of a couple of email exchanges now moved
to this
>     >>
>     >>
>     >list
>     >
>     >
>     >>as it is of interest to all I feel.
>     >>
>     >>
>     >>Hi P - yes I can see why you've done that ...
>     >>
>     >>In re-reading the schema I understand how certain .events
are sent
>     >>
>     >>
>     >but I
>     >
>     >
>     >>am still unsure of some and I can't see a list of the
'modes' for
>     >>example and what should be sent if say a player is put
into pause
>     >>
>     >>
>     >or FF
>     >
>     >
>     >>or whatever. I also see there is a refererence to allowing
the
>     >>
>     >>
>     >.events
>     >
>     >
>     >>to be sent 'as needed'
>     >>
>     >>It strikes me we could do with defining some additional
time
>     >>
>     >>
>     >related
>     >
>     >
>     >>parameters for inclusion in the event reporting timeline
including
>     >>
>     >>Duration  <mandatory>
>     >>StartTime <mandatory>
>     >>EndTime <mandatory>
>     >>CurrentTime  <mandatory>
>     >>ElapsedTime   <optional ?>
>     >>RemainingTime  <optional ?>
>     >>
>     >>.. and that these should be sent periodically at a
frequency that
>     >>
>     >>
>     >is
>     >
>     >
>     >>configurable as different users might want tighter
feedback. 10
>     >>
>     >>
>     >secs
>     >
>     >
>     >>sounds a useful time for most implementations. Towards the
end of
>     >>
>     >>
>     >the
>     >
>     >
>     >>current track it may be desireable to increase the
frequency of
>     >>
>     >>
>     >events
>     >
>     >
>     >>Just to expand on the above time information I was
considering what
>     >>would happen if a player was asked to play a track whose
duration
>     >>
>     >>
>     >was
>     >
>     >
>     >>say 5 mins but starting at position 1min22secs and ending
at
>     >>
>     >>
>     >1min44secs
>     >
>     >
>     >>which I think our schema should/does support (the actual
time being
>     >>
>     >>
>     >down
>     >
>     >
>     >>to 100'ths of a sec perhaps).The current 'Duration' is the
length of
>     >>
>     >>
>     >the
>     >
>     >
>     >>whole track and the currentTime the exact current position
relative
>     >>
>     >>
>     >to
>     >
>     >
>     >>that. The StartTime and EndTime are the actual markers for
what
>     >>
>     >>
>     >section
>     >
>     >
>     >>is to be played. ElapsedTime and RemainingTime can be
derived from
>     >>
>     >>
>     >the
>     >
>     >
>     >>other values but could be defined such that they can be
inserted as
>     >>optional .
>     >>
>     >>What does anyone think ? I think this is needed and I am
keen to
>     >>
>     >>
>     >resolve
>     >
>     >
>     >>it whilst Malcolm is focussed on teh xAP aspects of
TelCanto.
>     >>
>     >>
>     >Edward
>     >
>     >
>     >>and Stuart I would particularly value your comments as you
are the
>     >>
>     >>
>     >two
>     >
>     >
>     >>who have done this practically already...
>     >>
>     >>    Kevin
>     >>
>     >>
>     >>Patrick Lidstone wrote:
>     >>
>     >>
>     >>
>     >>>I do an "elapsed time" event which includes
current play state for
>     >>>
>     >>>
>     >the
>     >
>     >
>     >>>Rio stuff (sent once every 10s or so, plus whenever a
button
>     >>>
>     >>>
>     >causes a
>     >
>     >
>     >>>change). This is an integral part of the audio spec -
I can dig
>     >>>
>     >>>
>     >out the
>     >
>     >
>     >>>exact message if no-one else chips in.
>     >>>
>     >>>P.
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>>-----Original Message-----
>     >>>>From: Kevin Hawkins
>     >>>>Sent: 09 December 2004 13:44
>     >>>>
>     >>>>
>     >>>>xAP guys...
>     >>>>
>     >>>>   The newer audio schema isnt one I'm familiar
with  so I'm
>     >>>>
>     >>>>
>     >just
>     >
>     >
>     >>>>coming up to speed on that as I provide feedback
to Malcolm. What
>     >>>>
>     >>>>
>     >I
>     >
>     >
>     >>>>can't seem to see is how a player keeps people
informed of its
>     >>>>
>     >>>>
>     >state.
>     >
>     >
>     >>>>For example when it is paused by a press of the
pause button on
>     >>>>
>     >>>>
>     >the
>     >
>     >
>     >>>>player or IR remote or FF'wded perhaps causing the
track position
>     >>>>
>     >>>>
>     >to
>     >
>     >
>     >>>>change (not the actual track just the time
remaining).  How do we
>     >>>>indicate a player is in pause/play or whatever ?. 
  It strikes
>     >>>>
>     >>>>
>     >me we
>     >
>     >
>     >>>>need a whole series of periodic event messages
being generated by
>     >>>>
>     >>>>
>     >a
>     >
>     >
>     >>>>player that keep people updated about it current
state eg 'time
>     >>>>remaining'.  ... and that such event messages
should probably
>     >>>>be issued
>     >>>>quite frequently (configurable), particulalry
towards the end
>     >>>>of a track
>     >>>>playing (eg track about to end /finished). 
Additionally
>     >>>>anything that
>     >>>>causes the estimated time remaining to change
should
>     >>>>immediately send an
>     >>>>update (eg a REW) This way monitoring apps can
accurately
>     >>>>become synched
>     >>>>with a players status even if they are only turned
on half
>     >>>>way through
>     >>>>a  track eg the xAP Desktop SliMP3 display...    I
can see
>     >>>>some specific
>     >>>>SliMP3 bits that would help but not in the general
schema and in
>     >>>>telCanto's case it could be driving lots of
different clients.
>     >>>>
>     >>>>Or have I missed something ?
>     >>>>
>     >>>>Kevin
>     >>>>
>     >>>>
>     >>>>
>     >>>>
>     >>>>
>     >
>     >
>     >
>     >
>     >
>     >
>     >Yahoo! Groups Links
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>
>
>
>    
------------------------------------------------------------------------
>     *Yahoo! Groups Links*
>
>         * To visit your group on the web, go to:
>           http://groups.yahoo.com/group/xAP_developer/
>
>         * To unsubscribe from this group, send an email to:
>           xAP_developer-unsubscribe@xxxxxxx
>           <mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe>
>
>         * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>           Service <http://docs.yahoo.com/info/terms/>.
>
>