Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

y-shift encoding strategy #19

Closed
dy opened this issue Feb 17, 2021 · 2 comments
Closed

y-shift encoding strategy #19

dy opened this issue Feb 17, 2021 · 2 comments

Comments

@dy
Copy link
Owner

dy commented Feb 17, 2021

Values are chosen to be direct positive values from 0-100 range from U+0100 unicode range. No negatives.
What would be the right approach to shift? Factors:

  • align: center feature may require negative shift
  • editing not affect parts outside of selected fragment
  • zoom levels - should clutter text with multiple shift symbols

0. Absolute shift

  • Just a bit unusual in editing, since requires guaranteed 1 extra operation per sample, worse than 1. on large scale since relative offset reduces shifts to minimum

1. Cursive + 1 up/down

  • Natural flow (only up/down is needed),
  • reduces number of characters in a font (only up/down needed)
  • reduces number of characters in textarea (no need to provide each character level)
  • removes clipping limit - waveform can go as high/low as required.
  • editing combinings is a bit unusual - cutting a character removes shift of the following character and all subsequents baseline shift.
  • separate up/down character is better than combinings: it makes step "up" by typing it (muscular logic). It can also be visualized as thin connection line. But still redundant and a bit unexpected direction change in editing, 0-width space eats away one..n caret shifts
  • Relative positioning creates a lot of noise on small scales when there's too much vertical variation, like 9,0,9,0,9,0. Absolute values are guaranteed to limit to one extra character overhead.

2. Cursive + n up/down

A mix of 0. and 1.: relative offsets to any amount.

  • Removes small scale clutter, reducing number of shifts to 1
  • still has critical baseline shift drawback
  • requires 2x shifting characters: up 100, down 100

2.1 Cursive with copy-paste compensation

  • can fix critical baseline shift

3. A separate font for sample values (caps-only, or like linefont)

Since bars are almost always 0-aligned, with little decorative shifts up/down, that hardly affects baseline shift (can be handled on copy/paste events); and samples data doesn't need full bar value, but rather single point with nice shift ability, mb there's a sense switching from bars font to samples font for small-scale cases.

That samples font would be just timedata font with features:

  • use any symbol/character
  • shift subsequent absolute markers (combining?) or mb provide shifted characters already for better editing
  • no need for center-align => no need for negative shifts/values
  • it can be even be a linear-data font, connecting chars with proper lines _/ˉ_/ˉ
  • width, weight variables

Originally posted by @dy in #18 (comment)

@dy dy changed the title Shift encoding strategy y-shift encoding strategy Oct 30, 2022
@dy
Copy link
Owner Author

dy commented Oct 30, 2022

Accents add step up or down, but would be meaningful to have +10 accents for faster jumps.

@dy dy mentioned this issue Oct 30, 2022
12 tasks
@dy
Copy link
Owner Author

dy commented Nov 2, 2022

Som

@dy dy closed this as completed Nov 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant