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
MP3s must be timecoded (cf. Acidized), so that they can be
timestretched and snapped to the correct time.
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.
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
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.
Will contain: Doors concepts, GUI basics, how to create your own
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
- Collect more Doors Media
Put more Part XMLs and MIDI content at http://doors.sourceforge.net/music.
See Contribute to get involved.