anokta / barelymusician Goto Github PK

generator adds notes to score
conductor conducts the notes in score
performer performs the conducted notes

voice and instrument interfaces (as well as all the unitgenerators overall) assume to have mono output.

would be useful to have multi-channel support particularly for instrument, e.g., to be able to assign different voices with panning etc.

also consider passing sample_rate (instead of sampling_interval) for consistency?

including event, sequencer, transport

ensure consistency + efficiency + safety of construction/destruction etc.

two cases:

1. global: e.g., for the midi input composers, performers should not go through conductor at all
2. per performer/instrument: e.g., drums instrument should not get affected by scale

while the current method seems to be working okay overall, might be worth revisiting the calculation later on.

to avoid redundant temp vector iteration

clarify the alphabetical order requirement, then,
full codebase needed pass to ensure it's consistent across.

debugging is not fun enough!

the initial plan to have only mono and stereo channels for instruments (and audio output).

might benefit more downmix/upmix methods for surround etc. later on.

interface for each level (legacy names below):

1. macro (song structure)
2. meso (harmonic progression)
3. micro (line/melody)

it seems to be a common enough approach to split instrument vs instrument parameter interfaces in audio plugins. might be worth investigating further what the benefits/tradeoffs are?

Current method requires dynamic memory allocation due to free/active voice containers.

Might be worth revisiting the implementation, particularly to see if there is a better way ensuring thread-safety in a more straightforward way (see #11 for the progress on thread-safety).

• where/if they are absolute time samples (vs. relative to score etc.)
• do they need a specific "time" type, or just keep it int etc.?

useful for polyphonic voice

explicitly interleaved:
buffer[index] -> frame
frame[channel] -> sample

for simplicity, current behavior snaps the playback cursor to the nearest sample.

this may be problematic for certain sampling ratio (system vs. playback sampling rate).

one very trivial improvement is to use linear interpolation for the fractional part of the cursor. then, can be further improved via cubic interpolation and/or a proper resampler - although, arguably not worth the added complexity.

for audio processing vs. modulation/ui controls, thread-safety must be ensured.

should instruments handle this? or should it be handled in the api level etc.?

section_composer -> return section_index
bar_composer -> noop
beat_composer -> read midi notes

conductor -> noop

util: instrument midi id -> instrument factory
util: midi metadata -> sequencer info

as modern western modes are basically derivations of the existing western scales, might be useful to simply set a start index/offset of a scale (e.g., 0 for ionian, 1 for dorian...) to avoid introducing additional scales.

https://en.wikipedia.org/wiki/Mode_(music)

for the old implementation, see: https://github.com/anokta/barelyMusician/blob/dissertation/Assets/barelyMusician/Core/Scripts/Composition/Base/Generation/ModeGenerator.cs#L69

performer will play notes with a timestamp prior to the start sample as soon as possible, meaning that will trigger them at the start of the buffer - without handling the missed samples.

while this should be an unlikely case (handled by the top-level api already?), might be good to investigate this further in the future.

• where/if a custom structure needed for passing buffers
• ensure no unnecessary copies get created across the modules

or alternatively it's an enum (?) with hardcoded chord structures

e.g., at the minimum to allow having I (major triad) vs i (minor triad) vs I7 (major 7th)

unit generators - particularly square/sawtooth etc. technically introduce aliasing due to discontinuities.

there are several possible solutions to generation methods (e.g., see in designing software synthesizer plug-ins in c++ for reference), although seems to be an overkill.

may still be worth investigating more later on for more sophisticated synth implementations.

alphabetical vs. contextual etc.

possibly:

• functions

  • constructor/destructor (increasing param)
  • inherited (alphabetical)
  • declared (alphabetical)

• variables

  • contextual grouping?

currently only used rand() in white noise generation for simplicity.

however, a more structured solution will become of importance soon when music generators are introduced.

next step: switch to random number generators in stl.

would instrument benefit from process(int num_frames) instead of inheriting unitgenerator.next()?

how many different note structures needed?

• w/o timestamps
• note on/off vs start/end
• absolute vs relative indices

how/where should the structures exposed across the api?

has instrument
uses note_queue

module interface reset behavior is not consistent across the codebase with usage of either,

1. reset the internal states, or
2. reset all the settings to default (more of re-initialize)

it should either be unified, or split behaviors into two explicit functions

refactor polyphonic voice accordingly

seemingly unnecessary for now, considering the whole point of scaling a note is to snap to the scale in-key notes in the first place.

but might still be useful to at least round the fractional value rather than flooring.

might be useful to add a quantizer method/class to avoid editing raw floating point beat durations

ensemble: list { performer, score, generator }

hardcoded with oscillators for now for simplicity.

should consider having a more generic wrapper when sample players etc. are added for instruments.

_getch()? really? :)