Quantcast

Rethink time signature: instead of one global time sig, have a time sig for each pattern

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Rethink time signature: instead of one global time sig, have a time sig for each pattern

diiz
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?

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Rethink time signature: instead of one global time sig, have a time sig for each pattern

Nikko Rocksalot

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.



On Tue, Mar 04, 2014 at 8:35 PM, Vesa <[hidden email]> wrote:

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?

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

Raine M. Ekman
In reply to this post by diiz
Citerar Vesa <[hidden email]>:
> 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.



--
[hidden email]
softrabbit on #lmms



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

diiz
On 03/05/2014 05:45 PM, Raine M. Ekman wrote:

> Citerar Vesa <[hidden email]>:
>> 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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

Stian Jørgensrud
In reply to this post by diiz
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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

Rob Kudla
In reply to this post by diiz
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

diiz
In reply to this post by Stian Jørgensrud
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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

diiz
In reply to this post by Rob Kudla
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

diiz
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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

Raine M. Ekman
Citerar Vesa <[hidden email]>:
> 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

:)

--
[hidden email]
softrabbit on #lmms



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

diiz
On 03/06/2014 09:45 AM, Raine M. Ekman wrote:

> Citerar Vesa <[hidden email]>:
>> 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.



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

Raine M. Ekman
In reply to this post by diiz
Citerar Vesa <[hidden email]>:
> 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.

--
[hidden email]
softrabbit on #lmms



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

diiz
On 03/06/2014 11:49 AM, Raine M. Ekman wrote:

> Citerar Vesa <[hidden email]>:
>> 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.



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

Raine M. Ekman
Citerar Vesa <[hidden email]>:
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.

--
[hidden email]
softrabbit on #lmms


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel

time_signatures.png (55K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

diiz
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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

diiz
In reply to this post by Raine M. Ekman
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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

Stian Jørgensrud
In reply to this post by Raine M. Ekman
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

:)

--
[hidden email]
softrabbit on #lmms
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

diiz
In reply to this post by diiz
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.



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

Tobias Doerffel-2
I'd agree on limiting the denominators to powers of 4 as this causes
least problems for us.

Toby

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Rethink time signature: instead of one global time sig, have a time sig for each pattern

diiz
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...

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
LMMS-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
Loading...