On 03/06/2014 01:51 AM, Rob Kudla wrote: > On 03/04/2014 09:35 PM, Vesa wrote: >> I think we should rather move to a model, where instead of one global >> time signature we could just allow setting a time signature for each >> pattern individually - you could mix in 5/8 patterns at the same time >> with 3/9 patterns, at the same time. This would be implemented for both >> melodic and beat patterns. This would also pave the way for adding >> other neat timing-based effects such as shuffle. > This would be ideal for me, since it's rare I write an entire song in one > time signature, not being a dance music sort of guy, and polyrhythm support > would be especially welcome. > > In trackers, I usually did it by changing the length of the pattern, since > they didn't really have time signatures per se. Maybe that's how it could > be handled internally: just choose a number of beats based on the time > signature and number of bars of a given pattern, treat "time signature" as > something that only exists for the GUI equivalent to syntactic sugar, and > be done with it. Seems simpler than the automation track or whatever it was > I used to change the time sig in the middle of the song when I tried to > make a polyrhythmic song in LMMS, which caused the cursor to not line up > with the current note after the first time sig change (note: this was at > least 4 or 5 years ago, in a much older LMMS version.)
That's pretty much what I'm planning - and that's pretty much how it already is, time sig only affects the "tact length", the only problem is that with only one time sig, you have to adjust all the patterns to the same tact length. Difference is that in LMMS, we use ticks (equivalent to a 192th note) to measure length, not beats. Which is actually also pretty similar to trackers! I remember that old trackers used the same kind of tick system, 6 ticks per 16th note = 1 tick per 192th note. Only in trackers, you could adjust the ticks per note, which I guess was their equivalent of time signature... You have to also remember that time sig in LMMS doesn't work exactly the same way as time sig in sheet music. In traditional notation, the lower part signifies which note length corresponds to one beat, for example: in 4/8 time, an 8th note would be one beat, meaning that one tact in 4/8 would be the same "actual length" as a tact in 4/4 (given the same BPM). But LMMS treats time sig more ĺike a fractional number, so that a tact in 4/8 is actually half the length of a tact in 4/4, given the same BPM. LMMS also allows the use of weird time sigs such as 5/7, which don't make any sense in a traditional sense (there are no 7th notes). I'm a bit of two minds whether we should do anything about this, I think LMMS's way may actually make more sense from the perspective of electronic music making... the lower part (denominator) could maybe be constrained to actual binary exponents, (1, 2, 4, 8...) but keep the function otherwise the same. > As long as new patterns can be snapped to the end of the previous pattern > to prevent discontinuity, I think it would be easier to deal with, not only > from a user perspective but also codewise. Of course, the existing code is > a sunk cost, but since it doesn't really work that well, something's going > to have to be done with it regardless. Replacing it with something simpler > that works seems like the way to go. Snapping would be implemented with the global time sig, which would act as a grid. Like if you have a transition between 7/8 and 9/8, you could set the grid to 1/8 so you could adjust the starting point if the next pattern with 1/8 accuracy, then afterwards set the grid to 9/8 to continue working in the 9/8 area. Possibly we'd also have to add in grid offset though, although implementing that would require some changes to the drawing code of the track backgrounds (but should be doable). > LMMS is not as bad as my old all-in-one keyboard workstation, which simply > wouldn't support anything but 2/4, 3/4 or 4/4, resulting in my having to > step-enter my own drum "click tracks" reflecting what time sig I actually > wanted to play in. But it could be better. > > I guess I ought to be putting my code where my mouth is, but I'm not even > sure I can get LMMS to compile on my current Ubuntu 13.10 machine. > Yeah no rush there, this time sig business will not be even considered before we get 1.0.0 out. I don't see any reason why LMMS wouldn't compile on 13.10 though. ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
