| |
tlr
Registered: Sep 2003
Posts: 1790 |
Music editor, encoding alternatives for editing patterns?
I'm fiddling a little with a trackerish music editor and am curious to know how others solve typical problems.
My current editor prototype can edit dur style data directly like many others. The upside of this is that patterns can contain quite a lot of notes and can be used with the unmodified target player. The downside is more complicated editing logic and the issue of how to handle the update of a pattern while it is playing. Follow play is also a bit more tricky as rendering the data from the "source" takes a little more time.
I should mention that what I'm trying to do here is to allow editing data with tick (frame) precision, so a pattern of 128 steps in speed=6 could potentially contain up to 128 * 6 rows if zoomed in. This makes caching in "raw" form quite memory consuming.
How do other editors solve this problem? |
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
In defMON each step (even if empty) is represented in DUR representation (ticks rather than steps though) when editing. This makes it easy to edit data, since each pattern is 32 steps and thus takes a fixed amount of RAM. When packing, the DUR stuff is collapsed though, so that subsequent empty steps can be represented with a single data point, simply by adding the DUR/tick values. The duration value is only 4 or 5 bits though — can't remember right now — so a full empty pattern would require more than one data point, but usually there is a note or a command of some kind without too much of distance anyway, so it is a relatively sparse way of representing things anyway.
Using a variant of this approach for your purposes you could perhaps "expand" the pattern (or all three visible ones, for purposes of drawing follow play stuff) that you're currently editing into a larger buffer, and also temporarily change the pattern pointers of that pattern to point to the buffer, and then — once you're done editing that pattern — you could "pack" it and move it out of the buffer.
One downside of the approach used in defMON is that changing speed of the whole tune requires editing of each step in in each of the patterns, since the number of ticks until next step is actually hardcoded at each step in the patterns, rather than being easily modifiable using global "song speed commands" in the patterns. defMON "solves" this by allowing different modes of editing (think vim or so) that can edit every step in the whole song and things like this. These "edit modes" are also used for things like clearing the whole song, or a particular pattern. So I use the same "clear row" function as is used to clear a single line to clear a pattern or the whole song. I just apply that function differently, depending on the edit mode. The edit mode stuff also allows for things like "edit every Nth line", in case you want to set shuffle speed and such. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I'm also using ticks for duration rather than steps so the same issue with changing speed is there.
I guess what makes my goal a little tricky is that I want to be able to use all of the 256 maximum pattern bytes in an efficient manner. I'm thinking more than one effect command per event and things like that. Together with the pattern length requirement of ~128 or so steps (zoomable to tick level) expanding the data becomes impractical. Especially if the player routine is to handle >256 byte patterns just for the editor. I prefer to keep the player the same.
Maybe I need to tweak the goals... |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
What about indexed note durations? Don't know if it makes editing easier, but it is one way to encode durations in packed data. F.ex half, quarter, eight... |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Indexed note duration is a good idea for efficiency after packing yes. For editing only more complicated.
I think for encoding that, better not think in terms of music. Just build a histogram and sort. Currently my encoding allows 1-64 ticks encoded in one byte and up to 256 ticks in two. |
| |
Hein
Registered: Apr 2004
Posts: 954 |
Virtuoso decodes/encodes the player's active DUR based patterns to a temporary memory location in tick based form. This is used for follow play and editing purposes. The DUR based patterns in the editor are page aligned and only packed when exporting.
Temporary location:
;d000-d4ff - track 1 (1x note, 1x instrument, 8x fx) (128b x 10)
;d500-d9ff - track 2 (1x note, 1x instrument, 8x fx) (128b x 10)
;da00-deff - track 3 (1x note, 1x instrument, 8x fx) (128b x 10)
;data block of $500 bytes:
;0000=instrument (5 low-bits) \/ glide type (3 hi-bits)
;0080=note/gate \/ $80 end marker
;0100=prgads value
;0180=prgpor value / glide value
;0200=prgwav value
;0280=prgfre value
;0300=prgpul value
;0380=prgfil value
;0400=prghar value ;3 hi-bits free
;0480=speed value \/ $80 sets marker for pattern cmd used
This temporary data is decoded/encoded to screen data that any SID musician should be able to understand. Sort of.
So Virtuoso uses a 2 pass method, where the temporary location is used to poke to screen and peek from user input. Screen poking is 50fps, but only because of the temporary tick based data.
It's quite memory unfriendly as mentioned. Haven't tried to optimize it to a 1 pass method. Limiting it to speed 2 (25 fps) may be an option to encode DUR based pattern data to human-readable tick based screen data.
Lessons learned from using the editor:
- I really don't need 8 effect commands per tick. 4 at most.
- Limiting the amount of editable patterns because of page alignment is annoying when feeling creative.
- Limiting the editable pattern length to 96 ticks is annoying when using 4/4 time measure. :) The player can handle 256 bytes per pattern, which should be at least 128 ticks for editing. It's enough for a wild musician to fill it up with notes and effects. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Interesting notes there Hein.
I also use page aligned patterns although the code supports an arbitrary fixed size. You could use dynamically sized patterns but then some kind of garbage collector would be required. This might introduce delays that feel random to the user.
Getting rid of those display caches would make room for at least 15 more patterns.
My current approach is also 2 pass, although not yet for displaying. The difference is that my "expanded" data is using a separate table that has offsets to each primary unit (event), the length of that primary unit and the duration that it occupies. The "encoded" data only has dur entries where the duration changes.
This 2 pass process is used when editing the data (only for one pattern each time) and this is implemented by a separate abstraction layer that the actual visible editor uses.
Follow play is what I am most doubtful about because of the decoding. I also allow zooming the editor in to tick(frame) level but maybe follow play doesn't make sense there as it goes too fast? |
| |
Hein
Registered: Apr 2004
Posts: 954 |
Zooming in per frame does indeed feel too detailed to use for follow play. Considering my age. :)
I've played with the thought of implementing a piano roll approach (like modern DAWs), can't really remember why I stepped away from that idea, tbh. I think it makes encoding dur based patterns to screen faster and follow play smoother. And editing more natural for educated musicians (unlike myself). |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
As an even less educated musician piano roll usually doesn't do it for me. I really want the integration between notes, slides and other events to show together.
What I'm currently struggling with is the update of the player pattern position and remaining duration when adding note into the currently playing pattern. This got much more messy than I initially anticipated.
I'm doing a small test harness for the underlying logic so I can iron out the corner cases using a few regression tests. |
