MegatrondKWUR 90.3 FMWashington University in St. Louis The finest in underground radio Check out the station at www.kwur.com Or on our blog at www.kwur.com/blog Email: techSPaMnOATkwur.com (s/SPaMnOAT/@/g) |
Hello, and welcome to our Lynx friendly page. This page is dedicated to ideas briefly outlined in our feature request tracker as well as long term goals for the project.
A little background: KWUR 90.3 FM is one of the last remaining completely student run independent, underground FM radio stations. We transmit over the air and online from the campus of Washington University in St. Louis. We have developed a set of management tools in-house which we have released on Sourceforge under GPL v3. This set of tools is everything (software!) one needs to run an FCC compliant broadcast radio station from a single server including work-force management, and automated and manual content scheduling, playback, and tracking.
Ideas! (Sorted by language)
Bash
- For Bash masters or intermediate scripters with great patience and willingness to read a lot of documentation that is sprayed across the net.
Background: One component to KWUR 90.3 FM's projects allows global, remote broadcasts via a local icecast machine interfacing with our automated broadcast server, controlled via a simple web interface. We would like to explicitly develop a small, specialized, lightweight, live GNU/linux distribution to run from CD or USB that could turn any computer into a remote broadcast capable machine on the fly. The end goal: literally provide a voice to oppressed peoples all over the world. Two main objectives regarding this idea are:
1) Collecting every possible driver for every possible piece of linux compatible wireless internet adapters
2) Scripts to detect and allow for consistent determination of mixer elements as well as wireless configuration.
- Create on-system "phone" interface for handling on-air callers from skype or gtalk as well as hardlines
PHP/SQL
- For intermediate PHP/SQL coder: Create management pages for content that requires rotation, such as Public Service Announcements. These pages consist of a simple interface that controls permissions/visibility of time-sensitive files to the robot so that they may be placed and pulled from the available PSA's on demand.
- As long as we're talking about management, there are a variety of admin tools desired in the web interface so that shows may be deleted and ownership of shows may be transferred among DJs. These tasks require a intermediate PHP programmer.
- For advanced PHP coder: Create an interface to allow for dynamic programming of the robot with variable block length allocation. Ideally, we'd like some sort of GCal looking interface that allows someone to click on a time slot and then specify what they would like played for whatever length of time. Once a user creates a schedule they like, it will then be exported to an xml file that can be understood by the robot.
Java
- During a remote broadcast, in the event that a disconnect occurs between the local machine and the icecast server, the robot enters a "remote difficulty mode. Currently that mode consists of a timer that waits for a reconnect from the remote broadcast machine. If there is a timeout, the robot will broadcast a message followed by "technical difficulty" music, in addition to waiting for a reconnection. However, we would like to implement a more robust solution to just waiting for the remote broadcast to "phone home."
- If the robot must be rebooted in the middle of a currently broadcasting show, this "cold start" will cause the robot to lose any spawned wgets for archival. We want the robot to know if it was recording before it was restarted, and for it to be able to provide as seamless appearing gap as possible in programming so that it can quickly take control of any rogue processes. In Java, however, this may involve some trickery.
- With the archival/reviewer subproject in its infancy, the robot will eventually connect to the database to read the filesystem in order to pull tracks accordingly. However, wouldn't it be nice if once users start providing feedback about music and what its related to, the robot could dynamically reprogram itself based on current trends and "relativistic" genre categorization?
C++
- Extend icecast to create new stream mountpoints on the fly and allow different source passwords on different mountpoints. A ticket system ill be created on top of this with an authorization on a stream equal to the ticket, which can be valid for x amount of time.
Python, Perl, Scheme?
- Nothing at the moment, but we are open to ideas!
Other ideas/thoughts/questions?
Send an email to our developer list
Bash
- For Bash masters or intermediate scripters with great patience and willingness to read a lot of documentation that is sprayed across the net.
Background: One component to KWUR 90.3 FM's projects allows global, remote broadcasts via a local icecast machine interfacing with our automated broadcast server, controlled via a simple web interface. We would like to explicitly develop a small, specialized, lightweight, live GNU/linux distribution to run from CD or USB that could turn any computer into a remote broadcast capable machine on the fly. The end goal: literally provide a voice to oppressed peoples all over the world. Two main objectives regarding this idea are:
1) Collecting every possible driver for every possible piece of linux compatible wireless internet adapters
2) Scripts to detect and allow for consistent determination of mixer elements as well as wireless configuration. - Create on-system "phone" interface for handling on-air callers from skype or gtalk as well as hardlines
PHP/SQL
- For intermediate PHP/SQL coder: Create management pages for content that requires rotation, such as Public Service Announcements. These pages consist of a simple interface that controls permissions/visibility of time-sensitive files to the robot so that they may be placed and pulled from the available PSA's on demand.
- As long as we're talking about management, there are a variety of admin tools desired in the web interface so that shows may be deleted and ownership of shows may be transferred among DJs. These tasks require a intermediate PHP programmer.
- For advanced PHP coder: Create an interface to allow for dynamic programming of the robot with variable block length allocation. Ideally, we'd like some sort of GCal looking interface that allows someone to click on a time slot and then specify what they would like played for whatever length of time. Once a user creates a schedule they like, it will then be exported to an xml file that can be understood by the robot.
Java
- During a remote broadcast, in the event that a disconnect occurs between the local machine and the icecast server, the robot enters a "remote difficulty mode. Currently that mode consists of a timer that waits for a reconnect from the remote broadcast machine. If there is a timeout, the robot will broadcast a message followed by "technical difficulty" music, in addition to waiting for a reconnection. However, we would like to implement a more robust solution to just waiting for the remote broadcast to "phone home."
- If the robot must be rebooted in the middle of a currently broadcasting show, this "cold start" will cause the robot to lose any spawned wgets for archival. We want the robot to know if it was recording before it was restarted, and for it to be able to provide as seamless appearing gap as possible in programming so that it can quickly take control of any rogue processes. In Java, however, this may involve some trickery.
- With the archival/reviewer subproject in its infancy, the robot will eventually connect to the database to read the filesystem in order to pull tracks accordingly. However, wouldn't it be nice if once users start providing feedback about music and what its related to, the robot could dynamically reprogram itself based on current trends and "relativistic" genre categorization?
C++
- Extend icecast to create new stream mountpoints on the fly and allow different source passwords on different mountpoints. A ticket system ill be created on top of this with an authorization on a stream equal to the ticket, which can be valid for x amount of time.
Python, Perl, Scheme?
- Nothing at the moment, but we are open to ideas!