roelofruis / artamus Goto Github PK

In protocol

Check whether (immutable) models can be passed outside the core.

Use different modelling domains:

• Event-based
• Symbolic
  (- Analytical ?)

Think of some kind of construction mechanism that hides creating ID's for symbols and symboltracks.

Make all algorithms be just transformations of SymbolTracks

So All tracks for a given ID can be found

Investigate using futures

Fix the todo's in Commands and Events:
// TODO: Remove references to domain types, use DTO's for communication between layers

Based on the quantized grid, place the notes into measures

Playback and terminal should be both enabled

Only for PlaybackDevice and Logger, not InputDevice

Do not use the grid based approach but a system like MIDI ticks. Also enable midi input device again as this will now be almost 1 to 1.

Later add a quantization mechanism as separate part.

Also make sure the reference to Idea.ID is removed and properly supplied as a type.

Use commands to keep the separation, but do not expose the core services anymore.

So other modules can expose their functionality to the core

Make it nicer with an actual ASCII GUI.

Implement a terminal PlaybackDevice

Linear grid quantizer with given tempo and given grid size. Move out from there in new features.

Determine the best grid and BPM to record at, or at least make configurable.

This might improve correctness of the quantizer but the grid size boundaries should make sense in comparison to the recording grid.

This probably has something to do with the midi resource management, maybe rewrite this portion, now that the MIDI module has its own Driver

Using an interface like

trait CommandLog extends CommandDispatcher {
  def replay
  def size
  def persist
  def load
}

Maybe abstract over both Recording and Quantization, or make a separate Recording entity.

Using a given (known) key/scale.

If the client exits unexpectedly, the server crashes

Add communication synchronization via the MessageBus

Find a better way where either:

• modules dispose of their own long-living resources
• core asks the modules about resources instead of the other way around

Use private[core], final and private constructors where appropriate

Separate thread for entering music and receiving stop commands.

Or change the flow of control so recordings can be stopped

Ensure more decoupling and better project structure before moving on to adding more functionality.

This allows plugging multiple senders

Add a new show idea command

They can then later be refactored and put inside the core as commands.

As it now stands, each set of Service implementations is actually more distinct than seemed before, so no shared interface should be used.

Right now the TrackQuantizer interface depends on implementation specific parameters. This should be changed to allow other TrackQuantizer implementations with (probably) different parameters.

Maybe expand later to the idea's scale.

So it can be shared between different track representations

in protocol