planning
parent
2cbcbb134f
commit
d3005dc72a
|
@ -0,0 +1,39 @@
|
|||
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
|
Loading…
Reference in New Issue