Home
Download
Documentation
Screenshots
License

Roadmap
Get Involved
SF.net Project
CVS
Statistics

Roadmap

Outlined here are ideas on how to extend Doors.

• Develop new Devices
  A Device is a program controlling a piece of hardware which either inputs or outputs musical content. Doors can work with many different types of Devices, although so far only one Device has been created - the MIDI File Player. The most useful Devices right now would be as follows:

  • MP3 Player
    MP3s must be timecoded (cf. Acidized), so that they can be timestretched and snapped to the correct time.

  • Graphics Player
    A whole world of possibilities here. What I have in mind right now is a simple 2/3D graphics program, which plays a SMF file. This would be very easy to integrate, because it would just implement the MidiFilePlayer interface.

    Another thought is that a CORBA wrapper around a flash player would be a great 2D graphics engine, with plenty of content & development tools available.

  • Lights Controller
    Based on MIDI files, probably, because many lights controllers have a MIDI-IN socket on the back. Easy to implement, being based mainly on Midi File Player code.

• Make Doors boot CD
  Complete with hardware drivers, DHCP, NTP, hardware autodetection etc. Put this CD into any Intel machine and it starts-up all appropriate output Devices, plus GUI if desired.

• Internet extension: Groups of Controllers
  At present, there is one Controller per Doors network. When it receives a request to play a Part, it matches the requested output device to an actual output device. This works fine if all musicians are in one location (room). But if you're in different locations, you will only hear Parts which happen to get scheduled on devices in your location.

  The solution is to contruct a peer-network of Controllers. When any Controller receives a Part XML to play, it matches it to a local device as normal, but it also forwards the Part XML to all other Controller in it's 'group'. These Controllers perform local device matching as normal, but do not forward the Part XML.

  This means that musicians can be scattered over the Internet, yet you can hear everything your group is playing. The quality and availability of output depends, of course, upon the nature and quantity of the output devices at your location.

• Input devices
  At present, there is no means of sending data to a Doors Device in realtime. For example, you cannot plug in a MIDI keyboard and choose which Doors Device generates the sound.
  
  If Doors could do this, then the user could control multimedia devices live, rather than merely presequencing some pre-written parts.

  To achieve this, 'Input Devices' will be added to the software model. An Input Device captures data and, when instructed by the Controller, will stream it's data to an 'Output Device' in realtime. The Input and Output Devices are both subclasses of doors.Device, and fit into the Doors framework like any other Device - ie. subject to booking and matching by the Controller.

  For MIDI, this would require writing a MIDI Input Device which streams MIDI messages in realtime, eg. DMidi by Phil Kerr. Note that streaming over the Internet (using groups of Controllers) is probably prohibitively difficult at the moment due to latency. In this case, users may only use the regular presequencing technique. The most straightforward implementation would be to modify the MIDI File Player to implement the 'Output Device' interface.
  

• User Guide
  Will contain: Doors concepts, GUI basics, how to create your own Parts

• Technical explanation of how Doors works
  Will contain: XML & DTD explanation, IDL explanation, how the Controller works, how Device clients work, how to write a new Device.

• Collect more Doors Media
  Put more Part XMLs and MIDI content at http://doors.sourceforge.net/music.

See Contribute to get involved.