Expert
Posts: 512
Location: Netherlands | Anyone ever seen/used Lilypond? www.lilypond.org
I'm trying to figure it out recently (as I'm in need of example scores for the book I'm writing), quite hard as there are countless things and at first sight the syntax doesn't look very uniform or obvious to me, more like "w00ps, we need another command, well.. let's try this one then". Anyway, with the idea of printing revisit music in mind I've been wondering what would be the best way: the midifile way, where a midi tool tries to understand your intentions by just looking at the notes, or perhaps directly exporting the revisit format to lilypond. The midifile way has the disadvantage that the midi format is quite skinny, it's more a technological communication protocol than that it has anything related to music. What's an 8th note and an 8th rest? An 8th note with an 8th rest or a quarter note with a staccato dot on it? There's note-on and note-off and that's it.
Since revisit's content can be output as xml, one has access to all pattern fields, one could basically create an exporter from revisit to lilypond. The problem is that tracking formats by tradition aren't as detailed as a score can be. How to define slurs in a pattern editor? How to define cresc/dim, other than following ctrl7, etc. One could convert switchkey'ed articulations when one has the definitions of those. And then there's the next problem: what about string instruments where for instance c0-b3 means upstroke and c4-b7 means downstroke. That's all handwork when someone wants to convert to score.
A solution could be to have many more cells in a track, not all visible at once ofcoz, but selectable. In those cells one could define slurs, articulation styles (some standard listnumber could be assumed, like '000' is always arco, '001' is always pizzicato, etc. Other cells might have expression symbols up/down-stroke symbols. There might even be cells which define key signatures, countless things to include.
It would mean that a future channel format would have to be a bit more advanced, not only having note or numerical cells, but also binary cells (slur-on, slur-off), or cells that can represent ppppp-fffff.
It's a bit of a tricky affair. As complex stuff like a harp glissando is quite hard to define perhaps, but it's still worth thinking over I think.. |
Developer
Posts: 746
 
Location: England | I agree: tracking is quite a good editing medium for converting to score, simply because the intrinsic quantisation allows for less confusion in the score import stage. Also, unlike MIDI, or even most score editors, the tracker effect's notion (musical effects over time) is quite close to the concept of relative ornaments and performance directions (Dxx, for example is equivalent to crescendo lines). In MIDI and sequencers, you can only emulate the effect by gradually making each note louder manually. In reViSiT, you just add the 'crescendo' effect. So, I think their's a lot of scope for a tracker->score convertor.
However, one of the advantages of the tracker pattern is that it's not formally bound to the score format, which many musicians say is ultimately limiting. (Indeed, I'm working with a composer from IRCAM on two such very problems at this moment in time!) It's also not tethered to a single instrument or genre. It doesn't distinguish between acoustic or digital instruments. It provides a powerful and flexible conduit to provide as much expressivity as possible without colouring or shaping the experience.
Changes to the pattern format have been discussed before. Some minor changes have already been made, some more major extensions are planned (multiple pitches, multiple effects). reViSiT is about music creation, not transcription, so the 'advanced features' suggested here are not really appropriate for reViSiT. Naturally, I'll explore any such modifications that fit neatly into the reViSiT mission, or manage to add to the interaction without making other compromises.
Chris |
future channel format
