MusicWeaver Data Types



Packets and Items

You don't really need to know how its data is organized to use the MusicWeaver, but such knowledge may be helpful down the line

All data is transferred between elements as packets, each containing one or more items. Items are tagged with an ID word as to their type, and elements only respond to those that concern them. The basic items relevant to most MusicWeaver modules are the 'MIDI' item (with that ID) holding the events themselves, and the the TimeStamp (ID 'MTIM') of the packet. The most common packet will just comprise those two items: one MTIM and one MIDI. Usually the MIDI item will hold just one event, but if more than one of these has the same event-time they will be put in the same item if possible. There is never more than one of either the above items in a packet.

A MIDI item actually holds a little more than just the MIDI events. Unique to the MusicWeaver, MIDI events can be tagged with any of eight "marks". When an element is passed such an event, it can take action determined by its marks (currently only deciding which path or paths to send it out on). Find all the details in Marking and Splitting.

A standard MIDI stream contains mostly events that are represented in three bytes or less; these are encoded directly in the above MIDI items. A stream can also carry "System Exclusive" messages, that can be quite long, so do not fit in with the other short events. These are handled in the MusicWeaver as separate packets, also with a timestamp but with the system exclusive data in a 'MSYX' item. Such packets are generated as appropriate by MidiPlay, MidiFile and RePlay, and recorded by MidiFile and RePlay. They are passed along the original path by all other modules, but will not get sent to the 'Split' branch of a Splitter, or included in the output of a TimeSort. [It is possible, in the published standard, for some types of System Exclusive, for particular hardware, to be divided into several time-separated sections in a midifile. This seems to be rare, and currently the MusicWeaver doesn't handle these (the MidiKit doesn't either...) — it assumes each System Exclusive message is bundled as a unit.]

There are yet other types of data that travel along paths in a MusicWeaver diagram that are not part of the MIDI standard itself, and will not get transmitted outside of the diagram at all. For one thing, a standard midifile typically has quite a bit of extra information that cannot be transmitted as MIDI, but is used and created by Sequencer programs and so on. These data chunks are generically known as "Metaevents". Like 'MSYX' items, these have a timstamp, and get passed along the original path, but will not be split or timesorted. All except the one in the next paragraph have the common ID 'MMTD'; they are not really used by any modules, except for display (MidiMon and Karaoke).

One particular — and essential — metaevent is the Tempo indicator, that specifies exactly how fast a MIDI sequence should be played. The midifile-playing modules (MidiPlay and MidiFile) of course use these to control their own output, but they also pass them out as 'MTPO' packets for possible use elsewhere. MidiFile will of course record and use them suitably. The Metronome module is also aware. RePlay, though, always uses its own timebase, and does not record, use, or generate them.

The last midifile-relevant item is the "Track Indicator" ('MTRK'). Produced by MidiPlay and MidiFile from the information in the playing midifile, it is only used for display by MidiMon and to decide what is actually a "Lyric" by Karaoke

Certain of the modules add or use a couple of other items beyond those in the basic midi scheme. One is "Chord Info" ('CHRD'), which describes the chord that is apparently sounding, with some limitations. It is added to each midi packet passing through by the KeyTrack element, and is used by Analyze and KeySig elements. The chord is represented in two ways, first by transposing all the sounding notes (irrespective of channel) into a single octave, and also by an attempted identification of the actual chord and its root note. The latter is often ambiguous (is it a fourth or a fifth?), and compression into an octave loses information too, but the preprocessing is useful for the downstream elements. A MidiMon will display the apparent root note and the chord (with the above limitations).

The other new item tacked on to each packet by KeyTrack is "Keys Down" ('KEYS'); it represents all the notes (out of the complete set of 128) that are apparently sounding — i.e. there are more Note-On events than Note-Offs. Channel is ignored, but a count is kept by the generating module, so the same note on separate channels is monitored correctly. This item is currently only used by the Notator module.

In addition to all these MusicWeaver packet types, there are "Director" packets, intended to be used in any Weaver suite. For details on these, see Universal Modules.

MidiFile vs. Replay

The MusicWeaver has two entirely separate ways of recording and playing back its MIDI streams — MidiFile and RePlay — so it is worth noting why they are both useful and where you might use them. Essentially, MidiFile handles the standard cross-platform midifiles that you see everywhere, but it therefore isn't able to take notice of what the MusicWeaver can add to streams. Replay, on the other hand, has its own private storage format, which is no use elsewhere, but is able to preserve and reproduce the added information.

The MidiFile module will handle all the information contained in a midifile. The only point to note is that it turns multi-track ('Format 1') files into single track ones internally, so that although it plays them perfectly well you will only get a 'Format 0' file if you save it back to disc. all the information is still there — it just is all merged into one track, which is less convenient for working on in a sequencer. (Though most sequencers can split a single-track file back into multiple tracks.)

All events standard to a midifile — including System Exclusive, Tempo changes, and other MetaEvents — are sent on a MidiFile's output path when playing, and recorded when received. A RePlay element on the other hand, will record and play back System Exclusive sequences, but not the metaevents known to the MidiFile. It does, however, record the 'tags' added to MIDI events by other MusicWeaver modules, so these can be reproduced during a later session. It also preserves any 'Switch' or other Control packets it receives on its Recording input.

Both MidiFile and Replay can be triggered by events on their input, but RePlay can delay its playback a desired amount if the trigger must precede the synchronization point.

The playback speed of a RePlay sequence can be changed, whereas this is not possible with a MidiFile.

There are other minor differences, but the above are the important ones. One intended use of RePlay is to hold short sequences that can be triggered into action (singly or repeatedly) during a performance.