This is the data behind a single block.

Block metadata is extra data that doesn't affect normal derivation, but may be of interest to cmds.

Previously this was used to mark blocks for automatic lilypond derivation, currently tscore uses it to mark sub-blocks.

Score derivation creates destination tracks 1:1 with their source tracks, so I can key them with their source TrackIds.

(source_track_id, (destination_track_id, index))

For block_integrated, the source_track_id should point to a track in the source block. For block_integrated_tracks it should point to a track within its own block. The destination_track_id should always point to a track in the same block.

This holds the EventIndex for one note track, along with its dependent control tracks.

Create an empty destination for the first integration.

TODO I intended to unify all the integration muddle into one dest to source map, and maybe I stil can, but meanwhile, here's what it could look like.

Destinations for a manually-invoked integration. A single SourceKey can have destinations on multiple tracks within the block.

Arbitrary text used to identify the source of this integration. Unlike automatic integrations, which come from another block or track, a manual integration can bring in events from anywhere, so it needs a unique key to identify the source.

This is a picture of the integrated events that were used to create an integrated block or track. By taking its difference against the current contents of the block I can figure out user edits.

Arrows that should be drawn to indicate integrate relationships.

Per-block configuration.

One of those colored boxes wedged into the corners of the block window.

Like Track.Track, this has per-track data, but unlike Track.Track, this is data that can vary per-block.

This is the higher level track that is visible at the haskell level, as opposed to DisplayTrack, which is what is visible in the UI.

Construct a Track with defaults.

A generic divider to insert manually as a visual aid. Imitates the background color.

Don't send a track signal to a track unless it actually wants to draw it.

This is the low-level representation of a track, which directly corresponds with what is displayed by the UI. The DisplayTracks should be derivable from a Block deterministically.

This has a 2 character string to display above the track, and a background color. TODO change to Char Char

Most of these only make sense for event tracks.

Convert logical block level tracks to display tracks.

A divider separating tracks. Defined here in Block since it's so trivial.

A view is a single window on screen. Views are destroyed when the window is closed.

Construct a View, using default values for most of its fields. Don't construct views using View directly since create_view overwrites view_tracks, and maybe more in the future.

Pixel width and height of stuff in the view that is not the track area, i.e. scrollbars, skeleton display, block title, etc.

Only fltk knows the width of all the various widgets, but it's cached here so pure code doesn't have to call to the UI and import BlockC. Only UpdateViewResize should set this, which in turn comes from MsgCollector::msg_resize, which in turn comes from Block::get_padding.

Figure out what color the background of the status line should be.

Return how much track is in view.

Get the rect of the track area within the view. This is used with set_track_rect to set the size of the visible track area, minus the extra GUI bits around it.

The inverse of track_rect Use this to set the track area area to a certain size.

Y coordinate of the given TrackTime.