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

["Malcolm Green" <groups@xxxxxxxxxxxx>]

------=_NextPart_000_0130_01C4F7ED.3C258C20
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

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.
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.

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?



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]
}


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
>
>
>
>
>
>
>
>
>
>





_____