Search options (Page 18 of 131)

Hi all,
I am considering moving to calendar versioning. So using version numbers as "2023.1" instead of x.y.z.
It seems apt considering the frequency of releases. I guess it means there might never be an official version 1.0…

There are two popular formats I would consider, YYYY.MM where the second part is the zero padded month, (ex: 2023.03) or YYYY.Minor, where the second part is the release number within that particular year (ex: 2023.1).
What do you think?

I'm doing a simplification pass and I want to get rid of this.

To explain what this is, it is a small collection of SVG files that are built into the program and exposed through dedicated menus under Tools > Observational references > … (circle, clock, foot, etc.).

These menus are simply wrappers around the creation of an SVG drawing object. To be clear, you can always use the "Import image" menu and point it to an SVG file on your system, it will do the same thing. The only thing special about these menus is that these particular SVG files are builtin. You can find the files under the "guides" folder in the program files.

The collection feels awkward. There is no clear driving logic as to what should be there, nobody is making/contributing new files and I've basically never seen a video where someone was using this feature. I feel it should be acceptable for the few that may be using this to use the import image menu instead.

This would promote the "Import image…" menu directly under tools. (maybe add this to the toolbar).
What do you think?

Cadence and its derived measurements are fundamental metrics in many sports. For version 0.9.7 I want to add a Cadence tool. For the past few days I have gathered a number of ideas for user interaction and features, please add your feedback and comments.

The idea of this thread is to gather everything you can think of that may influence the design. It's a brainstorming exercise: all ideas are welcomed, we'll sort them out later.

Main use cases: Running, Swimming, Cycling, Rowing. (Add your use-case and the kind of metrics you use in the comments).

1. General interaction
- A way to add/remove a "beat" (marking the cycle). This should be a keyboard shortcut and a menu.
- A way to add/remove/update several time sections (connected or disconnected) inside which the cadence will be computed.

2. Cadence display
- count, cadence, half cadence, double cadence.
- The raw count can be interesting for example in 400 m Hurdles where we want to know how many strides are taken between each hurdle. Or simply as a repetition counter for any sort of exercises.
- half cadence and double cadence: for example in swimming it's easier to mark the beat when a specific arm goes down into the water but we may want to know the stroke rate instead. In running it's easier to tap a beat on each step but we might be interested in a tempo based on the full cycle.
- Precision: integer cycles or fractional cycles. (70 rpm vs 70.512 rpm). Fractional raw count may be interesting as well.

Question
- Do you think the simple counter and the cadence tool should be two different tools? It seems a bit convoluted to use a cadence tool if all you want is to quickly count reps.

3. Partial cycles in a given period
- I'm thinking the "beats" should be recorded independently of the time sections, as they may not always align.
- This means we can have partial cycles at the begining and the end of the time section.
- For the "raw count" display we'll need to know if these should be included in the count.
- For calculating the cadence we can probably always use the whole cycles in the period and divide by the time span they cover, it will be more precise than trying to guess the fraction of cycle at the corners.

4. Compute period
- The basic idea is thus to compute cadence by averaging over the time section (full cycles divided by their span).
- Another idea would be to compute the cadence based on the last X seconds or the last X cycles. How useful is this?

5. Distance calibration
- If we know the distance covered during the time period we can compute extra metrics.
- Stride or stroke length.
- Pace (time per distance unit).
- So it should be possible to go and specify the distance coordinate of time section end points.
- However, this calibration is going to be over the whole time section, so now we definitely need to to deal with the partial cycles at the start and end of the section.

6. Units
- Each sport uses a different cycle name and time span for their canonical "frequency". Step, stride, stroke, revolution, rotation… per minute, per second.
- I guess the default unit should probably be "Hertz" to stay neutral and SI.
- Then it would be nice to be able to configure the actual unit name you are interested in computing/displaying.
- Should this be configurable per object or in the global preferences like speed/acceleration units?

7. Cadence deviation
- It could be interesting to be able to set a reference cadence and then have the tool show how much the measured cadence deviates from that reference.
- Possible measures for deviation: raw time delta compared to the expected beat, fraction of cycle.
- Actually this deviation doesn't even need a reference, we could compute the average cadence and display the deviation at the current position compared to that running average.

Cadence

Counter

That's all I can think of for now. Please add more ideas and comments below, so we can have a good overview.