Last week, being then employed and interested in social activity and exercise, 
I took a free dance lesson from an acquaintance.

The main thing I learned was that music is a scarce and precious commodity in 
a dance studio.  You can only put one, or at most two, sets of music over the 
loud speaker systems.  Personal systems are *too* personal.  A couple cannot 
coordinate walkmen or even mp3 players.

WANTED: a wireless audio system for very local broadcasting -- to be used in 
dance studios and dance departments.  (Ideally, somebody already makes this.  
If not, have Motorola give me a call.)

TARGET MARKETS:
Dance studios and dance departments or schools. Gymnastics coaches.  Figure 
skaters and coaches.  Personal or small-group trainers who teach rythm 
aerobics.  Other markets for mini-cast audio.


COMPONENTS:

Information Appliances (2):

Personal headset unit with compact receiver and powersource.

Compact remote control unit.



Base unit (3 sub-components)

To be housed on PC, eventual migration to central info-appliance possible.
Wireless LAN.
Broadcaster software.

==================================

RECIEVER UNIT (RU):   

Low bulk, low weight.  Useable by serious amatuer and professional dancers, 
gymnists, aerobicizers, and otherwise friendly to atheletes and interpretive 
artists who need access to audio mini-cast to a small group.   Note that when 
I discussed this with my dancer friend she immediately thought it would be 
good for personal use.  Thus, a version of the reciever appliance will be 
able to store audio in non-volitile memory.  It will include the basic 
command functions listed below.  (That is, in addition to participating as a 
reciever in a LAN mini-cast, some models of reciever unit *must* act exactly 
like current Mp3 players.)

Reciver units shall have unique serial numbers (eg. MAC addresses) that can be 
aliased by the broadcaster software.  SNs will be used to assign reciever 
appliances to broadcast groups.

*THE* reason for the mini-cast system is to provide synchronized music to 
small groups in areas with high audio congestion.  Therefore, users must be 
able to configure RUs into mini-cast reception groups.  All recivers in a 
mini-cast group will get the same audio broadcast.  Therefore, system 
implementers will be *very* cautious about using cached data when as RU is a 
member of a reception group that contains any other RUs as members.

An RU cannot be restricted by line-of-sight.



COMPACT REMOTE CONTROL UNIT (CRCU):

Used by coaches and instructors, the remote control units will provide basic 
music control functions such as "select song", "make bookmark", "goto 
bookmark", pause, stop, fast forward, reverse, and--never to be 
forgotten--play.  The designer will *NOT* put excess function into the CRCU. 
Each button shall have one, and *ONLY* one function.

The RU and CRCU may be integrated into a single assembly.
It is marginally desirable that a palm-top augmented with appropriate software 
and hardware be able te emulate a CRCU.

A CRCU cannot be restricted by line-of-sight.


BASE UNIT (XMITer):

Early versions of the base unit will be implemented from an Intel or Apple 
computer using mircrowave or RF wireless LAN (eg wireless ethernet).  
Line-of-sight technologies are inappropriate for this application.  The 
wireless LAN must have sufficient bandwidth to support seamless, high quality 
broadcast of at least 5 simultaneous audio programs.

The ability to add wireless LANs on slightly different frequencies, thereby 
expanding the system, is moderately desirable. 

Software will be included to manage the system (the App).

The Application Administrator will be able to control storage and access to 
copywritten material, user access, where data is stored, and so on.    
Approprate interfaces will be provided to the App Admin.  A critical job for 
the App Admin will be naming RU and CRCU appliances.  *NOTE* that the App 
Admin is likely to be one or several small business owners with limited legal 
or computer expertise.  

Power users (coaches, instructors, and so on) will be designated by the app 
admin.  They will need to manage their own music, access studio owned music, 
assemble "programming" for a given class, and so on.  Most importantly, power 
users will need to define a group of RUs that will receive a mini-cast.  They 
will also need to designate the CRCU that will control the mini-cast.

The only domain expert consulted thus far seemed very interested in a personal 
RU with storage capablity.  While the intital prototype may require aliasing 
a fixed set of RUs and CRCUs, the system will be designed to add and drop RU 
and CRCU appliances _ad hoc_.  Adding new RU-CRCU appliances and designating 
a group should be fast--taking under five minutes for initial production 
versions of the system.
_______________________________________________
http://www.mccmedia.com/mailman/listinfo/brin-l

Reply via email to