From: Vesa <di...@nb...> - 2014-03-05 02:36:02
|
Beware, long post ahead! I just want to throw this idea out there, raise some discussion maybe: Is the current implementation of time signature really purposeful? It doesn't allow the use of different time signatures in a song very conveniently: you basically have to find a time signature that "matches", ie. is divisible with, all the time signatures you want to use - this is mostly because changing time signatures mid-song is very awkward. And if you want to do fancy rhythmic things where you use overlapping different time signatures - well, things just get ugly. Also, automating tempo is already a cause of headache, automating the global time sig just increases that headache by several orders of magnitude... 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. Basically, we'd keep measuring the length of pattern in tacts, but additionally, each pattern would have a new "time sig" property, and the "real" length in ticks (to those who don't know: ticks are the internal "smallest unit of time" when it comes to notes, one tick is equivalent to a 192th note) would be acquired by multiplying the number of tacts with the pattern's own time sig. Backwards compatibility would be kept by converting all old patterns into new signatured patterns by applying the old global sig to them. And since the underlying tick system would remain unchanged, the required changes wouldn't have to go all that deep even. This would allow cleaner implementations in many cases, I seem to notice that the current time sig system causes many issues in many parts of the software... even now there are multiple open issues all related to time sig in one way or another. I believe my proposal would allow for cleaner implementations. Basically, when you open a piano roll, it would display the pattern in the time signature of the pattern. There'd be a time signature widget in the piano roll, another in automation editor and another in bb-editor. The song editor's global time grid could be entirely beat-based, or it could be adjustable as a function of time signature - so there could still be a "global time sig" widget, but the difference would be that adjusting it wouldn't change any patterns, it would only change the "grid" while keeping the position & length of patterns intact. Also the global time sig could be used as a hint for newly created patterns, they could take their time sig from the global widget. I think all in all this could be a big improvement in the way LMMS handles time signatures. What do you think? |
From: Nikko R. <nik...@gm...> - 2014-03-05 02:40:30
|
<p dir="ltr">As a user I would LOVE this. I have transitions to differing time signatures and have had to plot it all out to being divisible into the song's main signature. This hampers writing for sure.</p> <br/><br/><div class="cm_quote" style=" color: #787878">On Tue, Mar 04, 2014 at 8:35 PM, Vesa <<a href="mailto:di...@nb...">di...@nb...</a>> wrote:</div><br><div id="oldcontent" style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: rgb(255, 255, 255); background-position: initial initial; background-repeat: initial initial; "><blockquote style=""><p dir="ltr">Beware, long post ahead! <br> <br> I just want to throw this idea out there, raise some discussion maybe: <br> Is the current implementation of time signature really purposeful? <br> <br> It doesn't allow the use of different time signatures in a song very <br> conveniently: you basically have to find a time signature that <br> "matches", ie. is divisible with, all the time signatures you want to <br> use - this is mostly because changing time signatures mid-song is very <br> awkward. And if you want to do fancy rhythmic things where you use <br> overlapping different time signatures - well, things just get ugly. <br> Also, automating tempo is already a cause of headache, automating the <br> global time sig just increases that headache by several orders of <br> magnitude... <br> <br> I think we should rather move to a model, where instead of one global <br> time signature we could just allow setting a time signature for each <br> pattern individually - you could mix in 5/8 patterns at the same time <br> with 3/9 patterns, at the same time. This would be implemented for both <br> melodic and beat patterns. This would also pave the way for adding other <br> neat timing-based effects such as shuffle. <br> <br> Basically, we'd keep measuring the length of pattern in tacts, but <br> additionally, each pattern would have a new "time sig" property, and the <br> "real" length in ticks (to those who don't know: ticks are the internal <br> "smallest unit of time" when it comes to notes, one tick is equivalent <br> to a 192th note) would be acquired by multiplying the number of tacts <br> with the pattern's own time sig. <br> <br> Backwards compatibility would be kept by converting all old patterns <br> into new signatured patterns by applying the old global sig to them. And <br> since the underlying tick system would remain unchanged, the required <br> changes wouldn't have to go all that deep even. <br> <br> This would allow cleaner implementations in many cases, I seem to notice <br> that the current time sig system causes many issues in many parts of the <br> software... even now there are multiple open issues all related to time <br> sig in one way or another. I believe my proposal would allow for cleaner <br> implementations. Basically, when you open a piano roll, it would display <br> the pattern in the time signature of the pattern. There'd be a time <br> signature widget in the piano roll, another in automation editor and <br> another in bb-editor. <br> <br> The song editor's global time grid could be entirely beat-based, or it <br> could be adjustable as a function of time signature - so there could <br> still be a "global time sig" widget, but the difference would be that <br> adjusting it wouldn't change any patterns, it would only change the <br> "grid" while keeping the position & length of patterns intact. Also the <br> global time sig could be used as a hint for newly created patterns, they <br> could take their time sig from the global widget. <br> <br> I think all in all this could be a big improvement in the way LMMS <br> handles time signatures. What do you think? <br> <br> ------------------------------------------------------------------------------ <br> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. <br> With Perforce, you get hassle-free workflows. Merge that actually works. <br> Faster operations. Version large binaries. Built-in WAN optimization and the <br> freedom to use Git, Perforce or both. Make the move to Perforce. <br> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk <br> _______________________________________________ <br> LMMS-devel mailing list <br> LMM...@li... <br> https://lists.sourceforge.net/lists/listinfo/lmms-devel <br> </p> </blockquote></div> |
From: Raine M. E. <ra...@ik...> - 2014-03-05 15:45:45
|
Citerar Vesa <di...@nb...>: > 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. Sounds like a crazy idea. But probably not too hard to implement, time signature should logically be mostly a UI thing anyway. Hopefully it's all ticks on deeper levels... > This would allow cleaner implementations in many cases, I seem to notice > that the current time sig system causes many issues in many parts of the > software... even now there are multiple open issues all related to time > sig in one way or another. Bad math and bad assumptions will remain even if the time signature is local instead of global. -- ra...@ik... softrabbit on #lmms |
From: Vesa <di...@nb...> - 2014-03-05 17:32:49
|
On 03/05/2014 05:45 PM, Raine M. Ekman wrote: > Citerar Vesa <di...@nb...>: >> 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. > Sounds like a crazy idea. But probably not too hard to implement, time > signature should logically be mostly a UI thing anyway. Hopefully it's > all ticks on deeper levels... Yes, that's exactly what I'm talking about - making time signature a UI thing. Global time sig would act like a grid which you can adjust without moving/changing the patterns. Local time sig would act as a hint for piano roll on how to display instrument tracks. Automation tracks would also have time sigs and it would be used to display the background grid, just so it's easier to align them with various instrument tracks. Bb-tracks would also a time sig, and for them it would arguably make the most difference: bb-patterns take the length of the loop sequence from time sig, so this would allow creation of beats with any loop length. This would work so that the bb track itself has a time sig which determines the length of the bb-track and I do believe deeper levels use mostly ticks for timing, the tacts thing is mostly UI. And yeah, I don't think this would be very hard to implement - I've taken a look at the code and I think it's entirely doable. > Bad math and bad assumptions will remain even if the time signature is > local instead of global. Granted, but I think it would still help, since with this implementation, we can possibly do some things in cleaner ways. |
From: Stian J. <sti...@gm...> - 2014-03-05 22:31:17
|
Well, the current implementation with a global time signature is probably on purpose but it doesn't allow for changing time signature easy. I had just the same in mind or something similar as you. Some bars in the timeline could be mapped to one time signature and the rest of the bars in the song would stay as they are. So a pattern 4/4 long would look the same as a 3/4 pattern, right? Only that you would know the difference by looking at the timeline or a information-track or something. Or would it be better to actually shrink the graphical background on those bars instead? -- View this message in context: http://linux-multimedia-studio-lmms.996328.n3.nabble.com/Rethink-time-signature-instead-of-one-global-time-sig-have-a-time-sig-for-each-pattern-tp6818p6824.html Sent from the lmms-devel mailing list archive at Nabble.com. |
From: Vesa <di...@nb...> - 2014-03-06 03:10:54
|
On 03/06/2014 12:31 AM, Stian Jørgensrud wrote: > Well, the current implementation with a global time signature is probably on > purpose but it doesn't allow for changing time signature easy. I had just > the same in mind or something similar as you. Some bars in the timeline > could be mapped to one time signature and the rest of the bars in the song > would stay as they are. > > So a pattern 4/4 long would look the same as a 3/4 pattern, right? Only that > you would know the difference by looking at the timeline or a > information-track or something. Or would it be better to actually shrink the > graphical background on those bars instead? > Patterns would look like what they look like now when you change time signature. From the perspective of patterns, everything would stay the same - they just would take the information for time signature from their own internal "time sig" property instead of a global one. The global time sig would be used only as a "grid" (like a grid in a graphics software) which the patterns snap to. If you change the grid size in GIMP, it won't affect any of the elements you've snapped to the grid previously, only the next ones. Similarly, changing the global time sig would have no effect on the positioning of the patterns. We could maybe add a switch to enable/disable snapping too, to complete the grid metaphor. The timeline would be entirely ambivalent about time signature - it would always just show the tact numbers based on the current time sig grid. Since timing is done based on ticks internally, there's no need for the timeline to care about mappings of time sig. |
From: Rob K. <sou...@ku...> - 2014-03-05 23:52:05
|
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.) 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. 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. Rob |
From: Vesa <di...@nb...> - 2014-03-06 03:26:55
|
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. |
From: Raine M. E. <ra...@ik...> - 2014-03-06 09:49:44
|
Citerar Vesa <di...@nb...>: > 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. Or you could say tempo always relates to quarter notes, which I believe isn't uncommon in sequencers (I know Rosegarden does this, googled up some programs called Logic, Cubase and Sonar that seem to be the same way). If this is potentially confusing to the sheet music literate, maybe BPM should be renamed QPM to make things 100% clear. > 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. From a technical POV any integer factor of 192 should be OK. Not that it would bring much more to the table: 3, 6, 12, 24 and 48 if my math is correct. -- ra...@ik... softrabbit on #lmms |
From: Vesa <di...@nb...> - 2014-03-06 10:30:55
|
On 03/06/2014 11:49 AM, Raine M. Ekman wrote: > Citerar Vesa <di...@nb...>: >> 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. > Or you could say tempo always relates to quarter notes, which I > believe isn't uncommon in sequencers (I know Rosegarden does this, > googled up some programs called Logic, Cubase and Sonar that seem to > be the same way). If this is potentially confusing to the sheet music > literate, maybe BPM should be renamed QPM to make things 100% clear. Nah, BPM is fine. It's a known term, changing it would probably just confuse people even more. >> 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. > From a technical POV any integer factor of 192 should be OK. Not that > it would bring much more to the table: 3, 6, 12, 24 and 48 if my math > is correct. Well, kind of... but the issues arise with beat patterns. Beat patterns currently always use 4 steps per beat, so any time sig must be divisible by a 16th note or they become arrhytmic. |
From: Raine M. E. <ra...@ik...> - 2014-03-06 11:53:49
Attachments:
time_signatures.png
|
Citerar Vesa <di...@nb...>: On 03/06/2014 11:49 AM, Raine M. Ekman wrote: >> From a technical POV any integer factor of 192 should be OK. Not that >> it would bring much more to the table: 3, 6, 12, 24 and 48 if my math >> is correct. > > Well, kind of... but the issues arise with beat patterns. Beat patterns > currently always use 4 steps per beat, so any time sig must be divisible > by a 16th note or they become arrhytmic. Beat patterns should really be upgraded to have both a length and a denominator. 36 48ths for a drum fill? 16 quarter notes for a long, stiff beat where you don't need those smaller notes? No problem! (But it might be a lot easier said than done... :) As for where I'd like the time signature situation to evolve, see picture. -- ra...@ik... softrabbit on #lmms |
From: Vesa <di...@nb...> - 2014-03-06 12:15:55
|
On 03/06/2014 01:53 PM, Raine M. Ekman wrote: > Beat patterns should really be upgraded to have both a length and a > denominator. 36 48ths for a drum fill? 16 quarter notes for a long, > stiff beat where you don't need those smaller notes? No problem! (But > it might be a lot easier said than done... :) > I don't know, you can already do that by editing the pattern in piano roll. If implement the per-pattern time sig, then beat patterns could have both a time sig (pattern length) and another value for step length, ie. how many subdivisions each beat has. > As for where I'd like the time signature situation to evolve, see picture. I have to say I'd rather have the time signature as a property of each pattern. That would still allow doing what your picture shows (by using different patterns for each segment), but it would also allow mixing different time signatures, eg. overlapping 5/8 patterns on one instrument and 3/8 on another... this wouldn't possible with fixed time signature areas. Also your suggestion has many ambiguities, like what happens when you move a 4/4 pattern to a 5/4 area... will a space be inserted in the tacts, will the notes stay where they are (making them misaligned with the signature)... with per-pattern time sigs, this wouldn't be an issue, as the patterns would be the same no matter where they are in relation to the song, as the global time sig would just be used as an adjustable grid. |
From: Vesa <di...@nb...> - 2014-03-06 12:50:38
|
On 03/06/2014 01:53 PM, Raine M. Ekman wrote: > Beat patterns should really be upgraded to have both a length and a > denominator. 36 48ths for a drum fill? 16 quarter notes for a long, > stiff beat where you don't need those smaller notes? No problem! (But > it might be a lot easier said than done... :) > I don't know, you can already do that by editing the pattern in piano roll. If implement the per-pattern time sig, then beat patterns could have both a time sig (pattern length) and another value for step length, ie. how many subdivisions each beat has. > As for where I'd like the time signature situation to evolve, see picture. I have to say I'd rather have the time signature as a property of each pattern. That would still allow doing what your picture shows (by using different patterns for each segment), but it would also allow mixing different time signatures, eg. overlapping 5/8 patterns on one instrument and 3/8 on another... this wouldn't possible with fixed time signature areas. Also your suggestion has many ambiguities, like what happens when you move a 4/4 pattern to a 5/4 area... will a space be inserted in the tacts, will the notes stay where they are (making them misaligned with the signature)... with per-pattern time sigs, this wouldn't be an issue, as the patterns would be the same no matter where they are in relation to the song, as the global time sig would just be used as an adjustable grid. |
From: Vesa <di...@nb...> - 2014-03-08 08:52:26
|
Anyway, at the very least, we should get rid of meter denominators that are not powers of 2 or 3. That means that the allowed meter denominators would be 1,2,3,4,6,8,12,16,24,32. However, personally, I'd rather just go and only have powers of 2, because that would be easier and make the beat/bassline implementation simpler. If we include 3's, we'll have to decide how we'll make beat-basslines behave in relation to them. Anyway, we should decide something either way. Either just stick with powers of 2, or also include the 3-series 3,6,12,24. At the very least, the odd numbers 5,7,9,11.. etc. should go, because they're not even divisible with our tick system. |
From: Tobias D. <tob...@gm...> - 2014-03-09 22:34:56
|
I'd agree on limiting the denominators to powers of 4 as this causes least problems for us. Toby |
From: Vesa <di...@nb...> - 2014-03-10 00:25:02
|
On 03/10/2014 12:34 AM, Tobias Doerffel wrote: > I'd agree on limiting the denominators to powers of 4 as this causes > least problems for us. > > Toby I think you meant powers of 2? Powers of 4 would be only 4 and 16... ;) Would this be best implemented by inheriting LcdSpinBox into a special DenominatorSpinBox, which only allows these values? And correspondingly, do the same for the model... |
From: Vesa <di...@nb...> - 2014-03-06 03:49:28
|
On 03/06/2014 05:26 AM, Vesa wrote: > 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. Actually now that I think about this, I think this is one thing we could do before 1.0.0 (since it will break backwards compatibility): modify time signature so that the denominator is constrained to binary exponents, like it is on actual time signatures. Time sigs that LMMS allows - such as 5/9, 3/11, etc. - make no sense as time sigs, and they cause weird behaviour, because they produce tact lengths that don't correspond to any actual note sizes (apart from the tick-sized 192th notes...) The upper part could still be whatever between 1-32, but the lower part should have no need to be anything other than 1,2,4,8,16 or 32. Toby, what do you say? It'd be a relatively simple thing to do, maybe break some backwards compat (if anoyne has actually ever used those weird uneven sigs), but it's better to break it now than later, and it would make things much easier for us in the long run. |
From: Raine M. E. <ra...@ik...> - 2014-03-06 07:45:31
|
Citerar Vesa <di...@nb...>: > Actually now that I think about this, I think this is one thing we could > do before 1.0.0 (since it will break backwards compatibility): modify > time signature so that the denominator is constrained to binary > exponents, like it is on actual time signatures. Time sigs that LMMS > allows - such as 5/9, 3/11, etc. - make no sense as time sigs, and they > cause weird behaviour, because they produce tact lengths that don't > correspond to any actual note sizes (apart from the tick-sized 192th > notes...) It's the cutting edge of modern music, really: http://en.wikipedia.org/wiki/Time_signature#Irrational_meters :) -- ra...@ik... softrabbit on #lmms |
From: Vesa <di...@nb...> - 2014-03-06 07:56:58
|
On 03/06/2014 09:45 AM, Raine M. Ekman wrote: > Citerar Vesa <di...@nb...>: >> Actually now that I think about this, I think this is one thing we could >> do before 1.0.0 (since it will break backwards compatibility): modify >> time signature so that the denominator is constrained to binary >> exponents, like it is on actual time signatures. Time sigs that LMMS >> allows - such as 5/9, 3/11, etc. - make no sense as time sigs, and they >> cause weird behaviour, because they produce tact lengths that don't >> correspond to any actual note sizes (apart from the tick-sized 192th >> notes...) > It's the cutting edge of modern music, really: > http://en.wikipedia.org/wiki/Time_signature#Irrational_meters > > :) > Right, sure, and if we used time sigs the same way they're used in traditional notation, I'd think we should keep them. But since we use "time signature" differently (see my earlier response to Rob), those irrational meters don't really make sense for us. |
From: Stian J. <sti...@gm...> - 2014-03-06 22:28:26
|
Haha. I saw that link, and this one is even more amazing. I don't think I would ever need any strange BPM, really... never. http://en.wikipedia.org/wiki/List_of_musical_works_in_unusual_time_signatures#1.2F.E2.88.9A.CF.80.2F.E2.88.9A.E2.85.94 Raine M. Ekman wrote > It's the cutting edge of modern music, really: > http://en.wikipedia.org/wiki/Time_signature#Irrational_meters > > :) > > -- > raine@ > softrabbit on #lmms -- View this message in context: http://linux-multimedia-studio-lmms.996328.n3.nabble.com/Rethink-time-signature-instead-of-one-global-time-sig-have-a-time-sig-for-each-pattern-tp6818p6841.html Sent from the lmms-devel mailing list archive at Nabble.com. |