New encoding for SequenceSection

[bookdude13]

We need to find a better way to store Sequence Section data besides JSON. JSON is nice, but clunky. Our data is pretty close to just binary, since each channel/time block is one byte big. Discuss thoughts below!

[bookdude13]

Alright, so talking with Ryan Smith made me realize that we could/should be using a database to store all of this data. I took a picture of the structure we worked out. Basically a user has a user id (uid) that links to many Permissions. Each Permission has a uid, a sequence id (seqid), the permission info, and a section id (sectid). A Section has a sectid, a start and end time (t_start and t_end), a seqid, and a list of Fixture ids ([fid]). A Sequence has a seqid, a list of fixture ids, and the actual sequence data. A Fixture has a fid, metadata about it, and a list of channel ids ([cid]). A Channel has a cid, a fid, and metadata about it.

If any questions about any of that, or if that made no sense, post in the comments.

[bookdude13]

[bookdude13]

This will affect how a lot of the cli is structured, just fyi

[LauraZiegelski]

So the way I'm understanding it right now, is that we will have multiple sequences that are being split up into sections for each user (which is what the t_start and t_end are for), and then each sequence, and therefore each section, will have an array of fixtures associated with it, and each fixture will have an array of channels associated with it.

[LauraZiegelski]

[computergeek125]

Almost. You are correct that sequences are divided into fixtures, and that fixtures are divided into channels.

However, sequences are split in two dimensions: sections along the x-axis, and fixtures along the y-axis.

So your diagram might end up looking something like this:

Now here's where it gets interesting: the extra array of fixtures you noted in the section is actually a subset of the fixtures in the sequence. This subset represents the actual fixtures the sequencer is allowed to operate on- all other fixtures are off-limits. Most of the time, [sequence fids] == [allowed fids], and the sequence might look something like the following picture. This sequence was sliced vertically: all sequencers are responsible for all fixtures, and time is divided between the sequencers.

Here, three sections might be defined:

section	t_start	t_end	allowed_fixtures
1	t0	t2	f1...f6
2	t2	t4	f1...f6
3	t4	t6	f1...f6

Side note: t_start and t_end can overlap within the data structure. This case would technically be feasible, however, the backend software should check for that and error if a user tries to enter an overlapping section.

Now here's where it gets complicated. You might also slice a sequence horizontally (by fixture). Here, all sequencers are responsible for the entire duration of the sequence, and fixtures are divided between the sequencers. I don't know if you want to support this case on the front end, but the data structure supports it. Calculating overlapping sections in this mode is harder and has a more complex Big-O (at least O(n^2) if not higher), but still possible.

Here, three sections might be defined:

section	t_start	t_end	allowed_fixtures
1	t0	t6	f1,f2
2	t0	t6	f3,f4
3	t0	t6	f5,f6

Note here that time overlaps, but the fixtures do not.

Finally, here's another case that uses both. In this case, sequencer 1 is a god and volunteers to do 2/3 of the song. The remaining 1/3 is split between 2 sequencers that don't have a whole lot of time on their hands.

section	t_start	t_end	allowed_fixtures
1	t0	t4	f1...f6
2	t4	t6	f1...f3
3	t4	t6	f4...f6

There are still no overlaps, because person 1 is responsible for all fixtures for the duration t0-t4, and the remaining duration is split by fixture between person 2 and person 3.

[computergeek125]

I just realized my post is 1-indexed. You can 0-index or 1-index, just make sure you stay consistent with whatever you choose.