The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Slimp3 as a xAP display & controller


  • Subject: Re: Slimp3 as a xAP display & controller
  • From: Stuart Booth
  • Date: Sat, 16 Aug 2003 22:42:00 +0000

On Sat, 16 Aug 2003 18:54:34 +0100, "Kevin Hawkins"
<<a
href="/group/xap_automation/post?postID=xEJjuqJNCWBkANG6hfKOBcfu1vEU9XcwrCUBrknPeB-wqEz_H2Pu91w4A4IopYj63pLTdC-RMbDa7DadjKzTTw">lists@u...</a>>
wrote:

> Stuart wrote the SliMP3 xAP as a display function however Patrick
>wrote a SliMP3 connector to support full control of the unit.
> P's implementation treats the SliMP3 very much as a xAP mp3 device -
>it handles music selection, play, pause, volume etc, playlist
management.
>However - the bad news - I don't think he ever published it - and more
bad
>news - I never got my SliMP3 back.

As it happens, my SliMP3 connector does that too! That Whole House
Audio (WHA) schema on my web site was my 2nd stab, I think, at a
general schema for all types of MP3 players, but it had SliMP3
extensions for specific items.

<<a href="http://www.xapframework.net/modules.php?name=Sections&op=viewarticle&artid=1";>http://www.xapframework.net/modules.php?name=Sections&amp;op=viewarticle&amp;artid=1</a>>

So you can actually control *all* aspects of the SliMP3 Command Line
Interface with my connector.

I haven't got around to seeing how it would cope with an Exstreamer
yet.

> Now the CLI interface that xAP uses to SliMP3 is truly an event
>interface. Anytime that anything changes on the SliMP3 the xAP
connector
>knows about it and can report it - for example the vol changing or a
track
>changing etc etc - this even extends to what is currently being
displayed
>and what IR remote keys are being pressed - Dean added this last bit
>especially for xAP. I don't know how much of this event reporting made
it
>into P's SliMP3 xAP. So...looking at what you're trying to do here..

But this is what I didn't finish implementing. Ages ago I had a
version that read SliMP3 events and output them on-screen, but I never
xAP-tised them. It's one thing on my enormous ToDo list. Oh, for a
week off work...

BTW, Max, MarkH has a db logging app available. He wrote this a while
ago:

66
The "Log all xAP messages to a database" program is ready for
alpha
testing.

Currently runs on Windows (tested on Win2k).
Should work with any ODBC-addressable database (tested on MySQL4).

I'd rather test with a few people before sticking up on the web -
please let me know if you'd like a copy and would be willing to help
test?
99

and

66
Thanks to the people who've replied off-list volunteering to test.

I thought that it would be worth documenting the tables used... all
of which are assumed to be in a database called xap.

TABLE message_header
header_id type int(11), not null, default 0
date_entered type datetime, not null, default 0000-00-00 00:00
xap_version type int(11), not null, default 0
hop_count type int(10)unsigned, not null, default 0
unique_identifier type varchar(8), not null
class type varchar (255), not null
source type varchar (255), not null
target type varchar (255)

TABLE message_block
header_id type int(10)unsigned, not null, default 0
block_id type int(10)unsigned, not null, default 0
block_name type varchar(255), not null

TABLE block_contents
header_id type int(10)unsigned, not null, default 0
block_id type int(10)unsigned, not null, default 0
content_id type int(10)unsigned, not null, default 0
keyname type varchar(255), not null
value type varchar(255), not null
is_hex type char(1)

The logic for having IDs, which are automatically generated by the
logger program, and rise monotonically, is to enable the EXACT re-
creation of the xAP message stream, even in areas where multiple
message blocks have identical names within the same message, and
multiple name-value pairs have identical names within the same
message block.

As you might imagine:

- header_id forms an index on message_header
- header_id, block_id forms an index on message_header
- header_id, block_id, content_id forms an index on message_header

The semantics of the fields should be fairly obvious :-)

Regards,

Mark
99

S
--
Stuart Booth
xAPFramework.net - a reusable xAP framework for .net

<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>
<a
href="/group/xap_automation/post?postID=FNgXGSZ7lTzBz--8LVVNyOwY91IEmJMseecHCUo8J4MhawoFfmgviyLMyaM0o65vtyDuDy-tmHzh-ObYGA">stuart@x...</a>





xAP_Automation Main Index | xAP_Automation Thread Index | xAP_Automation Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.