Support playing programmed music upon demand

[oubiwann]

Upon demand from an external source ...

Target workflow:

1. Start up Raspberry Pi (w/touch screen)
2. When desktop displays, touch icon to start undermidi
3. After undermidi starts, touch icon for a particular MIDI sequence
4. Ensure that clicking the icon executes the sequence associated with desktop icon
5. When finished, the original undermidi terminal + REPL is unaffected (stays open)
6. Provide function for listing all sequences on desktop (icons)
7. Provide function for selecting and playing one of the sequences
8. Provide function show showing the current songs in the playlist

Dev tasks:

• [x] Create new playlist gen_server
• [x] Update it to accept an "add file" message
• [x] Add a function that will read a sequence file and play the notes
• [x] Add client support and the ability to send an "add file" message
• [x] Create some sequence files
• [x] Ensure that they play correctly when their names are passed via the client
  • [x] create a supervision tree that can spawn worker gen_servers
  • [x] create a queue function that asks the supervision tree to spawn a worker, passing all the required data
  • [x] test basic workflow with timer:sleep
  • [x] implement player
  • [x] ensure that the worker plays the sequence correctly
  • [x] create a worker function that sends song data back to the queue gen_server when the song finishes
• [x] Experiment with a Desktop shortcut that starts an undermidi/LFE node and sends a message (e.g., via -- -<flag> file)

[oubiwann]

There are many ways to support a workflow like this, but there's one solution that intrigues me most:

• have a desktop icon that just brings up undermidi + the LFE REPL, but executes no sequence
• add a new "playlist" gen_server
• have "sequence" desktop icons that set an ENV variable for a sequence file and start up a new LFE node, sending a "play file" request, passing the value set in the ENV var
• the main undermidi LFE node receives this message, adds the sequence to the queue, with the "playlist" gen_server playing sequences in order
• once the "sequence" desktop icon's process has sent the file message, it closes down

[oubiwann]

Right, I forgot: when using rebar, erl and lfe are not called; rather, the shells are invoked in code, so there is not passing of args directly to either. Will have to explore the ENV route ...

[oubiwann]

Well, I guess we don't have to use the ENV route, since we do have rebar3 lfe run ...

[oubiwann]

Okay, I've created a main script in priv/scripts/playlist-add.lfe that takes kv pairs as args on the CLI and turns them into a map.

rebar.config profile section:

{profiles, [
    ...
    {'playlist-add', [
        {lfe, [{main, "priv/scripts/playlist-add.lfe"}]}
    ]}
]}.

Using this profile:

rebar3 as playlist-add lfe run -- name seq1 file priv/seqs/basic.lfe

Output of the script after a couple of rpc ~calls~ casts:

Playlist state: #M(opts #M(repeat f)
                   queue
                     (#M(name "seq1" file "priv/seqs/basic.lfe")
                      #M(name "seq1" file "priv/seqs/basic.lfe"))
                   played ())

[oubiwann]

That's basic infrastructure experiments done; next is the hard part of determining the best short-term solution for actually playing these files (a longer term solution can't be worked on until this epic work is nearing completion).

[oubiwann]

Key required behaviours:

• the Erlang that plays these files cannot block the gen_server (playing these files will (in the short term) involve sleeps between notes, which is a blocking operation)
• if nothing is in the queue when a file is added, the file should be played immediately
• if a file is already being played, the incoming file should be placed into a queue
• all files that are placed in the queue should be played on a FIFO basis
• when a file is sent to the playing process, it should be removed from the queue, and all of its associated data/metadata passed to the playing process
• the gen_server should get a message whenever the "playing" Erlang process finishes playing a file, and that message should also contain all of the song's associated data/metadata
• when the gen_server receives the "played" message, it should spawn an Erlang process to play the next song in the queue
• when the gen_server receives the "played" message, the song data/metadata should be appended to the played list
• the the play queue is empty and the last song has finished playing, if the gen_server's "repeat" option is "true" then the "played" list should be moved to the "to-play queue"

[oubiwann]

Phew! That's the most involved OTP I've done in a while ...