Adding setting for custom ticks per bar

[regulus]

Hi!

I was going to write a longer post, but when pressing preview it wanted me to log in again, and I lost my progress :'( So here's a short summary:

---

Currently, the number of ticks per bar is fixed at 192. This is fine for most people who compose in divisions of 1/4, 1/8, 1/6 etc, or even 1/3, 1/6, 1/2 etc, but it is not flexible enough for users require more precision, or who wish to compose in odd quantizations, such as 1/5 or 1/7.

It would be beneficial if users could go to the settings and change the ticks per bar for that project. That way, if you need extra precision, you could change it from 192 to, say, 786. Or if you want to compose in 1/5ths, you could set it to 320. Or any other combination of factors.

---

There are a few things which would need to be done to implement this:

1. Fix any gui (or core) components which do not support dynamic ticks per bar.

   • This mostly amounts to setting the ticksPerBar to something random in the code, and fixing everything which breaks.

2. Add a project-specific setting to change the ticks per bar (Project-specific settings are implemented in https://github.com/LMMS/lmms/pull/7865)

   • The setting has to be per-project, since otherwise opening projects from other people who use a different ticks per bar would load incorrectly.

3. Add a way to update all note/clip positions when the ticks per bar are changed, in order to not break everything.

   • This is not always reversible. When going from 192 to 64 ticks per bar, precision is lost, so some note positions may have to be rounded. Should we have a warning?

I would love to hear any comments or feedback. I know some users have brought up the idea of getting rid of integer ticks and simply using floats. Of course, then there's the discussion about precision and everything.

[musikbear]

go to the settings and change the ticks per bar for that project.

It would, but it is not possible. 1/192 is the limit, and atm there are also no possibilities to make 'odd' setups.

[orystully]

There are a few things which would need to be done to implement this:

1. Fix any gui (or core) components which do not support dynamic ticks per bar.

   • This mostly amounts to setting the ticksPerBar to something random in the code, and fixing everything which breaks.

2. Add a project-specific setting to change the ticks per bar (Project-specific settings are implemented in https://github.com/LMMS/lmms/pull/7865) [MOD EDIT: removed spam link]

   • The setting has to be per-project, since otherwise opening projects from other people who use a different ticks per bar would load incorrectly.

3. Add a way to update all note/clip positions when the ticks per bar are changed, in order to not break everything.

   • This is not always reversible. When going from 192 to 64 ticks per bar, precision is lost, so some note positions may have to be rounded. Should we have a warning?

This sounds like a solid and well-thought-out approach. The per-project ticks-per-bar setting especially makes sense to avoid compatibility issues. A warning when reducing resolution (e.g 192 -> 64) feels necessary, since rounding could affect musical intent.

[mjolnir]

Although I see the advantage of maybe odd meters, I disagree with this proposal for ticks editing. That level of granular editing is just TOO precise to be musically useful unless you're trying to synchronize to film/video/tv in which case you'd just align the video to the audio or the audio to the video in your DIGITAL VIDEO WORKSTATION (DVW), not in a DAW (Digital Audio Workstation).

The question seems like a red herring to me, much like requests for insanely high PPQ (pulses per quarter notes). Several decades of MIDI hardware runs successfully at low PPQs such as 96 PPQ, although 384 PPQ and on up became more common eventually. Reaper, for example, has a default of 960 PPQ which is just too much for me... I use MIDI all the time, and record with a USB MIDI controller, but I manually set my PPQ to 96 so it's not stressing my CPU with that excessive precision wasted if I'm only playing rapidly up to 32nd note triplets at 60-192 BPM (max), and certainly NOT performing nor needing 1/384th notes nor higher.

I'm not trying to go off on a tangent. Ticks per bar is just 4 times PPQ; it's really the same thing using slightly different math. It's still a fools errand UNLESS you need SMPTE time code precision of synch, as I said for example, for film/tv/video/animation.

In terms of MIDI latency, if you need better precision, that's managed in other parts of the chain. If you ramp up the PPQ (or the ticks=pulses per measure), you're just stressing the computer CPU.

Think of if you do all your cuts of carpentry at the inch or half inch or maybe centimeter. You DON'T need full resolution zoomed into the millimeter level or smaller (micro, pico, nano, femto, etc). While this metaphor is rather different and not 1:1 per scale, it's the same thing... if you need more musical resolution, just start with a higher BPM and work up to your BPM limit; that's the easy solution.

Like I said, if you need odd meter, that's different from PPQ or pulses/ticks per measure.
But I don't want to get into a wikipedia style argument about the definitions of meter or tempo.

A more real-world request would be using firmer maths such as:
Since LMMS allows a tempo between 10 and 999 (!!!!), at 44.1 kHz or 48 audio playback rate, for example, what's the duration of a "bar" (measure) at 960 BPM, assuming a 4/4 meter.

LMMS current DOES support 3/4 or 6/8 types of meters if you add and subract pattern lengths using the buttons. I've noticed it while demoing recently the Nightly versions. Click the "+" once and it doubles the length. Click it again, and it DOESN'T double the length again = you end up with a multiple of 3, which is handy exactly for 3/4 or 6/8 or 12/4 etc. Keep clicking it again and counting the exact numbers of beats and you'll see. "-" works in reverse similarly.

But if you want to get into odd or compound meters that's really a different type of request.
It doesn't require modifications to pulses/ticks. I guess that would be more of a regular request for fully editable meter, more like FL Studio.

Sorry if I sound snooty or arrogant in this response. I'm just strongly opinionated on this topic similar to how I reject the old school wars for "dither" or the loudness war stuff. I am sincere, though.