2021-04-28

MAIN GOAL: Plan out order of work for [sample-editor], figure out how to get started with this.

I think the first question to answer is what does an MVP of this look like?

1. Allow users to drag in samples from the sample library into the MIDI editor and place them on note lines
2. Full + accurate playback for the placed samples
3. Customized note box rendering for samples showing the name of the sample
4. Handling for BPM wrt. the actual lengths of samples, accurately handling collissions

I feel like I'm brushing over a lot of hidden complexity here, but if that were to be achieved I'd be happy enough to consider it a functional MVP.

Next-tier features that I'd like to see are:

• Sample recording + export
  • Integration into patch network as a top level sample recorder node
  • Export capabilities
• More detailed sample note box rendering with rendered waveform
• Sample crossfade editor
• Sample transformations and effects (reversing, etc.), derived samples persistence and association

OK so what is the first step for implementing this? I feel like I've been stuck not doing anything for a while; I had a big period of high productivity for the base [midi-editor] where each feature seemed to effortlessly flow into the next one, but now I'm finding it difficult to get started.

Of the first four MVP tasks, which shall we start with? Well, we've actually made a lot of progress on item 2, implementing the foundation of the Wasm module that will actually generate the audio from scheduled samples. Most of the API for interacting with it from the [awp] is in place, as is the actual playback + scheduling mechanism for the samples themselves. The AWP itself needs to be implemented, however, and that has ties with the MIDI editor that will own it as well.

Perhaps, since we've already started on the Wasm backend for it, we can expand on that next? Fleshing out the JS AWP code sounds do-able; it's going to require figuring out the messaging interface between the AWP and the parent as well which can help guide our work there once we get started on that piece.

After that, I think that item 3 (customized note box rendering) is a fine option. It feels like a lot of the changes that need to be made to the MIDI editor trickle up from the notes; we can create the generic note not box that is extended by MIDINoteBox and SampleNoteBox. OK sure, now we just have to muster up the willpower to go and build this stuff.