Multi instruments?
Posted: Fri Aug 14, 2020 8:29 am
I don't know enough about how LMMS (or indeed any other DAWs) are organised "under the hood". I wonder if a concept of "multi-instrument" might be helpful.
At one level, even a common instrument, such as a piano, is a multi instrument. It can be considered as a sound producer with typically 88 different sub-instruments - one for each key, and if we also consider that each key can be struck in different ways - hard, soft and also held on for more or less time the number of such sub-instruments might be incresed further.
If we now suppose that we have several such more complex instruments - now I'm assuming that we can already generate something quite complex - like a piano - then it should be possible to combine instruments at a high level. For example, we could combine a piano with a plucked violin. Obviously this can be done by having multiple tracks, and having each note on each instrument played on both instrument tracks. What I'm now thinking of is a track which has a combined multi-instrument, so that it's not necessary to duplicate the notation, either in a score or midi format.
So - how could such a multi-instrument be implemented? Ignoring the software side for a moment, there are some issues regarding what would be needed. One way would be to take two existing instruments, and blend them together - mix them. For some situations that could work well, but in others it wouldn't work. For example, if there were two piano instruments, one with sustained sounds, one with short staccato sounds, blending would always result in a more or less sustained sound - as blending would give significant emphasis to the sustaining instrument. Blending could be a useful operation, but it's not the only one. Another operation might be pitch shifting., to extend the range of any instrument. Another could be time shifting - for example in the piano+violin combination - always have the violin sound coming at the end of the note. Other operations would be more binary - like on/off operations, to prevent one of the sub-instruments from dominating over the others used in the composite - for example in certain pitch ranges.
Actually implementing such a system of multi-instruments might be hard, but could present a different approach - more top down than bottom up - to software production, and new ways of thinking, just as writing in fuctional programming languages has led to new ways of thinking about how to develop software, and in some cases significant improvements. Rather than thinking about composites being built up of a large number of small elements, each of which needs its own programming, think about ways in which composites can be combined and interact with each other. The actual implementations using such an approach may still require some detailed low level work for efficiency reasons, but this is not always the case, and sometimes new ways of generating programs which work well can be found.
A trivial programming example might be:
At one level, even a common instrument, such as a piano, is a multi instrument. It can be considered as a sound producer with typically 88 different sub-instruments - one for each key, and if we also consider that each key can be struck in different ways - hard, soft and also held on for more or less time the number of such sub-instruments might be incresed further.
If we now suppose that we have several such more complex instruments - now I'm assuming that we can already generate something quite complex - like a piano - then it should be possible to combine instruments at a high level. For example, we could combine a piano with a plucked violin. Obviously this can be done by having multiple tracks, and having each note on each instrument played on both instrument tracks. What I'm now thinking of is a track which has a combined multi-instrument, so that it's not necessary to duplicate the notation, either in a score or midi format.
So - how could such a multi-instrument be implemented? Ignoring the software side for a moment, there are some issues regarding what would be needed. One way would be to take two existing instruments, and blend them together - mix them. For some situations that could work well, but in others it wouldn't work. For example, if there were two piano instruments, one with sustained sounds, one with short staccato sounds, blending would always result in a more or less sustained sound - as blending would give significant emphasis to the sustaining instrument. Blending could be a useful operation, but it's not the only one. Another operation might be pitch shifting., to extend the range of any instrument. Another could be time shifting - for example in the piano+violin combination - always have the violin sound coming at the end of the note. Other operations would be more binary - like on/off operations, to prevent one of the sub-instruments from dominating over the others used in the composite - for example in certain pitch ranges.
Actually implementing such a system of multi-instruments might be hard, but could present a different approach - more top down than bottom up - to software production, and new ways of thinking, just as writing in fuctional programming languages has led to new ways of thinking about how to develop software, and in some cases significant improvements. Rather than thinking about composites being built up of a large number of small elements, each of which needs its own programming, think about ways in which composites can be combined and interact with each other. The actual implementations using such an approach may still require some detailed low level work for efficiency reasons, but this is not always the case, and sometimes new ways of generating programs which work well can be found.
A trivial programming example might be:
In functional programmingRather than trying to make an algorithm such as bubble sort run faster by clever low level programming, use a different algorithm - such as quicksort or heap sort. Always try to replace O(n^3) algorithms by O(n^2) algorithms, O(n^2) algorithms by O(log n) algoritthms, and ultimately replace these by O(1) algorithms.
This is, of course, merely kite flying!Use map operations rather than low level iteration, or explicit recusion