40 lines
1.7 KiB
Plaintext
40 lines
1.7 KiB
Plaintext
|
pattern editor {
|
||
|
iosevka works perfectly for tracker patterns
|
||
|
C-4 01 vFF
|
||
|
can freely embed it too (SIL OFL allows bundling)
|
||
|
probably Iosevka Term (Light?)
|
||
|
}
|
||
|
|
||
|
project data {
|
||
|
samples are held in memory as {
|
||
|
QString name, QUuid id (used as dictionary key) (?)
|
||
|
sample rate, channel count (1 or 2), length
|
||
|
probably QSharedPointer to raw float array (size=length*channels, non-interleaved)
|
||
|
}
|
||
|
|
||
|
pattern {
|
||
|
name, id
|
||
|
length in rows (duh)
|
||
|
time signature, in beats per measure and rows per beat (can default to project global)
|
||
|
|
||
|
per-pattern channels? since everything is determined by instruments and plugins
|
||
|
- this would orphan all currently playing notes when crossing a pattern boundary (maybe treat same-named channels as the same for this purpose?)
|
||
|
|
||
|
command format
|
||
|
01 C-5 v7F ... ... ...
|
||
|
instrument (port) number first; note-sharp-octave notation same as most trackers, but arbitrary number of a single type of parameter
|
||
|
[plugins receive commands more or less exactly as written; meaning is by convention more than anything, but there is a "standard" way of handling notes, handled by a library on the lua side]
|
||
|
- leave pitch bends to automation? or build them as per-tick messages from host? also, stepped by tick or smoothed per sample?
|
||
|
- note-on events send the actual note as a float value
|
||
|
}
|
||
|
}
|
||
|
|
||
|
resampler object {
|
||
|
one used internally for each note
|
||
|
reference to sample
|
||
|
wrap mode (flat, loop, pingpong)
|
||
|
double position (number of samples with fractional part)
|
||
|
}
|
||
|
|
||
|
lv2 support: lilv (duh) for actual plugin loading, suil for UI embedding
|