meadowlarkdaw/meadowlark

A (currently incomplete) open-source Digital Audio Workstation

Meadowlark

Meadowlark is a (work in progress) FREE and open-source DAW (Digital Audio Workstation) for Linux, Mac and Windows. It aims to be a powerful recording, composing, editing, sound designing, mixing, and mastering tool for artists around the world, while also being intuitive and customizable.

Meadowlark is in a temporary hiatus while I figure out a direction for this project. Stay tuned for updates.

If you wish to see the old code, it is in the old and dev-(old) branches.

---

Get Involved

Before participating in discussions with the community, you should familiarize yourself with our Code of Conduct.

• Come join us on our Discord Server! (music artists, designers, developers, and general users welcome!)

• If you have experience with mixing and/or mastering music, please help us with researching open source mixing plugins.

• Any sound designers (or anyone who knows of any good public domain samples) is free to contribute to our factory library. See this readme for more details.

• Any donations are very much appreciated! (donation link)

Note that I am not accepting code contributions to this project for the foreseeable future.

meadowlark's Issues

Timeline grid widget

Build the timeline grid as a widget.

Note that this widget will not actually scroll within a tuix scroll container. Instead, this will just draw the various grid lines as a function of the input data.

When zoomed in far enough, this should show additional detail like beats and beat divisions.

Every beat division is marked with a thin vertical line, every beat is marked with a slightly thicker vertical line, and every 4 beats (1 measure) is marked with an event thicker vertical line.

Every 4 measures (16 beats), the background color of the grid should alternative between two different values of gray.

This widget will take these data points as inputs:

• width and height of the timeline area (in pixels)
• horizontal zoom level (1.0 is default zoom level, < 1.0 is zoomed out, and > 1.0 is zoomed in). Just pick something that feels reasonable for a scale of 1.0 (like around 100 pixels).
• horizontal scroll position (represented in units of beats)
• vertical scroll position (represented in units of pixels)
• list vertical heights of each track/division (in pixels). This is where the horizontal grid lines should be drawn.

UI Workflow Discussion - Views and Workspaces

How should the workflow of showing, hiding, and arranging various views and panels work?

There are two likely methods for going about this:

Magnetic Floating Windows

This is the approach that "FL Studio" takes. The idea is that every view/panel is a floating window, and these windows can "snap" magnetically to any edge of the screen.

Pros

• Very flexible and allows the user easily organize windows in whatever manner they wish.
• Windows can easily be sent to separate monitors.

Cons

• Less space efficient on smaller screens, and usually requires the user to constantly show/hide various windows.
• Saving various preset "workspaces" would be more difficult and finicky.
• Extra work will be needed to ensure views will scale and stretch correctly on different sizes and orientations.
• Usually looks less "clean" requiring window titlebars and borders on every view.

Tiling Panels

This is the approach that DAWs like Bitwig Studio and Ableton Live take. In this approach every view is a non-floating panel that can be tiled with other panels. Usually each panel has a pre-defined location.

Pros

• More space efficient on smaller screens.
• Easier to create and switch between various preset "workspaces".
• Usually looks cleaner.

Cons

• Less flexible for the user to organize views how they want, usually locking in the user to preset locations for views.
• Harder and more finicky to send views to separate monitors.

Please post any ideas and design mockups of how each of these approaches could work in this thread.

test

DSP Discussion

Here are my current thoughts about what we should do for DSP.

Note that we should reference the GNU fork of the Vital plugin called Vitalium and not Vital itself. This is so we can safely assure that any code we are borrowing is GPL licensed.

Basic DSP that needs done before MVP:

• Stereo Panning with preferably circular pan law (we can add more pan laws too)
• Sub-sample interpolator. This will allow us to create much needed effects such as resampling and doppler stretching, as well as future effects such as delay and wavetables. I've heard good things about the "optimal" designs described in this paper: https://github.com/BillyDM/Awesome-Audio-DSP/blob/main/deip.pdf
• We could also look into using bindings to the libsamplerate library for high-quality offline resampling.

Other framework DSP needed at some point (not MVP):

• Fast integer oversampling/downsampling. This is commonly used for anti-aliasing non-linear effects such as distortion.
• The common digital filter types: high shelf, low shelf, high pass, low pass, bell, peak, bandpass, and allpass
  • I have heard great things about the SVF filter design, which can be used in place of the biquad filter design, and I would like to incorporate it as much as possible.
  • As for calculating filter coefficients, I'm not sure if we should develop our own design, or if we should borrow this from existing plugins. Potential plugins that come into mind are Vitalium, x42 Equalizer (aka fil4.lv2), and Ardour's EQ.
  • These filters should not "cramp" on the high end, which has a noticeable effect on the sound quality of the filter.

Internal plugins I would like to have (but not MVP):

A long term goal of this project is to have a complete suite of "fairly good quality" internal plugins that can be used to mix and master a track. Therefore I would like to focus more on effect plugins rather than synth plugins.

We of course don't have the resources to create industry-leading quality plugins. But I do want it to the point where musicians can get a satisfying mix without needing to reach for 3rd party plugins.

For each of these listed plugins, we could either choose to develop it ourself or we can borrow the DSP from one of the listed sources:

Higher priority plugins:

• EQ
  • x42 Equalizer - A fairly decent EQ (used in Harrison Mixbus).
  • Vitalium - Has a built-in equalizer, as well as different filter models.
  • Ardour's EQ
• Basic Compressor
  • x42 Compressor - Probably the best quality open source compressor IMO.
  • ZamCompX2 - Another pretty good quality compressor.
  • Vitalium - Has a built-in compressor effect (both single band and multiband).
  • Ardour's Compressor
• Multiband Splitter
• Mid/Side Splitter
• Multiband Compressor
  • This will just be the basic compressor but one for each band.
• Basic Gate Plugin
  • ZamGateX2
• Basic Limiter
  • x42 Limiter - A fairly decent limiter
  • ZamMaximX2 - Another decent limiter
• Soft Clipper/Hard Clipper/Waveshaper
  • Vitalium - Has common built-in waveshapers including soft clip
  • It would also be nice to have pre/post filters
• Spectrometer (For use in EQ plugins & as its own plugin)
  • Wolf Spectrum - FL-style spectrometer
  • Spectacle - Nice standard-style spectrometer
• Chorus
  • YK Chorus - A really nice chorus effect based on a certain well-known analog synthesizer
  • Vitalium - This has a built-in chorus effect
• Phaser/Flanger
  • Vitalium - This has a built-in phaser/flanger effect
• Comb Filter
  • Vitalium - This has a built-in comb filter
• Delay
  • Tal-Dub-3 - Very nice sounding delay plugin
  • Vitalium - This also has a delay effect
• Reverb
  • Vitalium - This has a pretty nice sounding reverb effect
  • Tal-Reverb-2 - A popular great-sounding free plate reverb
  • Dragonfly Reverb - Ok sounding but highly configurable reverb
• Bus Compressor
  • This is probably the hardest one. This is pretty essential in getting a satisfying mix, but there is no open-source plugin I know of we can reference.
• Sampler Instrument
• Basic Subtractive Synth (akin to 3xOSC in FL Studio)
  • This is mainly just to have some-kind of built in synth to begin with. If we already have an EQ,
    chorus, phaser, compressor, delay, and reverb implemented, then we're already most of the way there.

Not as high priority plugins:

• Convolver
  • (There are a bunch of algorithms for this online)
• Shimmering Reverb
  • Cloud Reverb - A port of the amazing CloudSeed reverb. This sounds amazing as is.
• OTT Compressor
  • Vitalium - The built-in multiband compressor is pretty much this
• Tube Distortion
  • ZamTube - Really nice tube distortion effect with a lot of different models.
  • IronOxide5
  • Density2
• Tape Saturation
  • ToTape5 - Really nice sounding tape saturation plugin
• Vocal Exciter
  • ZamExcite
• Dynamic Equalizer (We can pretty much just add our compressor to our EQ once we have those)
• Desser (Pretty much a dynamic equalizer but focused on the high-end)
• "Aggressive" Compressor
  • Pressure4 - Really nice punchy and aggressive compressor
• Guitar Amp
  • Guitarix LV2 Ports
• Graph-based Waveshaper
  • Wolf Shaper - A really nice and powerful graph-based waveshaper plugin
• Analogue-modeled/Mastering EQ
  • Luftikus - Pretty nice sounding mastering EQ. Although the bands are fixed, but maybe we can change that?
• Goniometer (Shows a polar graph representing stereo phase correlation)
  • EasySSP
• Drum Sampler (This will be easy once we have the sampler instrument)
• Drum synth?
• Advanced subtractive synth?
• Wavetable synth?
• Additive synth?
• Soundfont/SFZ sampler?
• Linear Phase EQ?
• Vocal Compressor?

Add cargo.lock file?

Hello, cool project! Any chance you guys can include a cargo.lock file? It's needed to package it in NixOS.

UI Workflow Discussion - Timeline Clip Workflow

How should the workflow of arranging synths, audio clips, automation clips, and midi clips?

First, some terminology:

• "Vertical workflow" shall refer to the more "traditional" method of restricting a synth or "audio clip track" to a single row on the timeline. Automation clips appear in a row below the track it's automating, and these automation lanes can be shown/hidden. These lanes are a one-to-one correlation to the tracks in the mixer.
• "Pattern workflow" shall refer to the "FL Studio"-style method where synths and audio clips are not tied to a specific row on the timeline. Instead, synths and "audio clip tracks" are free to be assigned to any mixer track. Also midi clips, automation clips, and audio clips are free to be placed anywhere on the timeline grid.

For context, here are some pros and cons to each method:

Vertical Workflow

Pros

• There is a clear and easy to understand one-to-one correlation between the lanes on the timeline and the tracks on the mixer.
• It is more clear which midi, automation, and audio clips are assigned to which synth / "audio clip track".
• It is easier to copy-paste clips between different instruments.
• It is easier to group tracks/instruments together into "folders".
• The "track header" (the little panel that shows the track name, a fader to control volume, a db meter, arm/record/solo/mute buttons) is very standard and familiar.
• The one-to-one correlation makes organizing projects easier.

Cons

• It is more restrictive on how the user is allowed to organize their project.
• Hiding/showing/adding automation lanes for a particular track is very finicky.
• In a project with a lot of tracks and automation, a lot of vertical space will be taken up by lanes resulting in either a lot of scrolling or showing/hiding of lanes.
• Copying-pasting and looping/linking clips is more finicky.
• Extra work would need to go into making the whole "grouping tracks into folders" feature.
• Creating "layers" of instruments (using a single midi clip to control all the layers) is more clunky and requires special "routing plugins" on the track fx.
• Non-destructive loop recording will be more difficult (Do we add another tab to hide/show various takes on the track header? How does the user select which take takes precedent?)

Pattern Workflow

Pros

• It is a very "free-flow" way of working, allowing the user to place and organize clips in whatever manner they like.
• It is easy to select various patterns and copy-paste them wherever in the project, and to have these clips "linked" together so when one is edited it affects all the other instances in the timeline.
• In a project with a lot of clips, the user can organize all the clips on the timeline in a way that they are always visible, as opposed to the vertical workflow where a lot of vertical space would be taken up by each lane resulting in either a lot of scrolling or showing/hiding of lanes.
• It it easier to "layer" instruments together so you can use a single midi clip to control all synth layers for example.
• It it easier to route multiple synths and audio clips into the same mixer track.
• Non-destructive loop recording is easier (just add the recording clip on the next available timeline row).

Cons

• It is not as obvious and intuitive for users who are completely new to DAWs.
• There is no clear correlation between the synths / audio clips and the mixer track they are assigned to.
• There is no clear correlation between the midi / automation clips and the synth / "audio clip track" they are assigned to.
• It can be confusing for the user to keep track of all the patterns and clips in the project, and can obviously lead to very messy projects if the user doesn't take the time to organize.
• We would need an additional view for a sort-of "channel rack". We don't have to do this exactly like FL does though.
• We would also need some way to distinguish when the user wanted to open the piano roll/automation editor, and when they want to open the instrument plugin that the clip is assigned to.
• It can be more finicky to distinguish between when the user wants to copy-paste a "linked" clip or a new unique "unlinked" clip.

It is clear there is a split of workflow preference here. This issue is meant to be the place of discussion on how to solve the issue of satisfying both workflow tastes.

Please post any ideas and design mockups of those ideas here :)

ui_dev branch fails to build

Running 'cargo build' results in:

   Compiling femtovg v0.2.2 (https://github.com/femtovg/femtovg?branch=master#e9a74da0)
error: failed to run custom build command for `speech-dispatcher-sys v0.5.2`

Caused by:
  process didn't exit successfully: `/home/alex/soft/sound/meadowlark/target/debug/build/speech-dispatcher-sys-1056a37c40a9ff0d/build-script-build` (exit code: 101)
  --- stdout
  cargo:rustc-link-lib=speechd

  --- stderr
  wrapper.h:1:10: fatal error: 'speech-dispatcher/libspeechd.h' file not found
  wrapper.h:1:10: fatal error: 'speech-dispatcher/libspeechd.h' file not found, err: true
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ()', /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/speech-dispatcher-sys-0.5.2/build.rs:22:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

Expected usize

Doesn't run because compiler complains about the isize:

Meadowlark/src/backend/sample_browser_plug.rs

line 336
pcm.fill_stereo_f32(playhead as isize, buf_l_part, buf_r_part);
line 369
old_playhead as isize,

Changed to usize. Now DAW starts

Make a folder of SVG icons from the design mockup

Pull out all every unique icon from the design mockup into its own SVG file.

The Inkscape file for the design mockup can be found here:
https://github.com/MeadowlarkDAW/Meadowlark/blob/main/assets/design/gui-mockup-main.svg

It will help to refer to the design doc on what each icon represents:
https://github.com/MeadowlarkDAW/Meadowlark/blob/main/DESIGN_DOC.md

These icons were hastily made, so cleaning up these icons would be appreciated (but not necessary for this task).

Cannot run via `cargo run`

The error is here.

thread 'main' panicked at 'Cannot create renderer: ShaderCompileError("Vertex stage: ERROR: 0:1: '' :  Version number not supported by OGL driver\n\n")', C:\Users\Zean\.cargo\git\checkouts\vizia-a7ac1d316660c1f9\f9f06ce\crates\vizia_winit\src\window.rs:117:65

Expected: run smoothly

test

testing testing testing

Permission to make own repository for Name: Meadowlark (midnight) AKA Nightly

Hello There, I want to help your project, I am glad to help you
Here my forked repository
https://github.com/unknownK19/Meadowlark
;) Actually I pause my work at my repository until my Exam over

set one tag

to allow easier packaging and automatic version number creation it would be cool to have one initial version tag set. like 0.0.0 or so.

created an arch linux package at https://aur.archlinux.org/packages/meadowlark-git. it takes latest from git and tries to compile it. currently it does not, anything i'm doing wrong?

==> Starting build()...
   Compiling meadowlark v0.1.0 (/srv/http/repos/meadowlark-git/src/meadowlark-git)
error[E0308]: mismatched types
   --> src/backend/sample_browser_plug.rs:336:37
    |
336 |                 pcm.fill_stereo_f32(playhead as isize, buf_l_part, buf_r_part);
    |                     --------------- ^^^^^^^^^^^^^^^^^ expected `usize`, found `isize`
    |                     |
    |                     arguments to this function are incorrect
    |
note: associated function defined here
   --> /home/rt/.cargo/git/checkouts/pcm-loader-955ad95aec379986/e5cbddb/src/ram.rs:249:12
    |
249 |     pub fn fill_stereo_f32(&self, frame: usize, buf_l: &mut [f32], buf_r: &mut [f32]) -> usize {
    |            ^^^^^^^^^^^^^^^
help: you can convert an `isize` to a `usize` and panic if the converted value doesn't fit
    |
336 |                 pcm.fill_stereo_f32((playhead as isize).try_into().unwrap(), buf_l_part, buf_r_part);
    |                                     +                 +++++++++++++++++++++

error[E0308]: mismatched types
   --> src/backend/sample_browser_plug.rs:369:21
    |
368 |                 old_pcm.fill_stereo_f32(
    |                         --------------- arguments to this function are incorrect
369 |                     old_playhead as isize,
    |                     ^^^^^^^^^^^^^^^^^^^^^ expected `usize`, found `isize`
    |
note: associated function defined here
   --> /home/rt/.cargo/git/checkouts/pcm-loader-955ad95aec379986/e5cbddb/src/ram.rs:249:12
    |
249 |     pub fn fill_stereo_f32(&self, frame: usize, buf_l: &mut [f32], buf_r: &mut [f32]) -> usize {
    |            ^^^^^^^^^^^^^^^
help: you can convert an `isize` to a `usize` and panic if the converted value doesn't fit
    |
369 |                     (old_playhead as isize).try_into().unwrap(),
    |                     +                     +++++++++++++++++++++

For more information about this error, try `rustc --explain E0308`.
error: could not compile `meadowlark` due to 2 previous errors
==> ERROR: A failure occurred in build().
    Aborting...

UI Workflow Design Brainstorming

Here I'm posting my thoughts on the current design mockup to explain my reasoning behind each element. However, while writing this I noticed a bunch of issues with my inital design. I would love to get any feedback and ideas for this!

Top Bar

This was mostly inspired by this blogpost of an Ableton Redesign. I liked the concept so I thought I'd roll with it. http://nenadmilosevic.co/ableton-live-redesign/

(from left to right)

• File Section
  • Drop-down menu for file/project related stuff
  • Open dialog
  • Save
  • Save As
  • Undo/Redo
• Tempo Section

  • Current tempo (can be edited by double-clicking and typing in the tempo)

  • A button that can be tapped in series to set the tempo

  • Time signature

  • Open a dialog for editing swing/groove

  • Concerns: How should this respond when we eventually make the tempo automatable?

• Record Section
  • Main record button
  • Select what to record (audio, midi, audio & midi)
    • Concerns: Should there be some system here where the user can select which input source they want?
  • Loop recording mode (overwrite, new track, etc.)
• Transport Section
  • Current position of the playhead in musical time
    • Concerns: Should this have an option to display realtime?
  • Play/Pause button
  • Stop Button
  • Button that brings the playhead to the previously seeked position
    • Concerns: Should there be a button here that toggles between just stopping the playing when pausing and bringing the playhead back the the previously seeked position when pausing?
  • Button that toggles looping on/off
• Monitor
  • Select type of audio montitor (oscilloscope, spectrograph, etc.)
  • Audio monitor
  • CPU monitor
• View Section
  • Toggle to open/close the timeline.
    • Concerns: Should the timeline even be floatable?
  • Toggle to open/close the mixer
    • Concerns: Should this mixer even be floatable? Would it be easier/cleaner to have a Bitwig-like tab system where you toggle between "edit mode" and "mixer mode"?
  • Toggle to open/close the piano roll
  • Toggle to open/close automation editor
    • Concerns: Should we even have a dedicated automation editor?
  • Toggle to open/close audio clip editor
    • Concerns: Should we even have a dedicated audio clip editor?
  • Other concerns:
    Should we have tabs to toggle the Track FX panel as well?

Left Panel

(tabs from top to bottom)

• Sample browser

• Preset browser

• Plugin browser

• File-system browser

  • Concerns: Should we even have this?

• Properties - This will contain a list of editable properties of whatever element (timeline track, audio clip, piano roll note) is currently selected

• Improvements: I think we should aim for an Ableton-like search system. We could have a keyboard shortcut to open this search as well. We could also have a toggle in the settings where the left panel is only shown when searching.

• We could also have a fuzzy command palette/runner similar to VSCode

Timeline

Timeline Toolbar

• Select mode - Used to select & move clips

• I Beam

  • (I can't actually remember what this was supposed to do, lol)

• Pencil mode - Pencil-in clips onto the timeline

  • Actually now that I think about it, we could probably figure out a better way to add new clips to the timeline.

• Erase tool - Erases clips

• Slice mode - Slices a clip into two pieces
  (on right side)

• Drop-down to select grid snapping mode

• Button that opens a dialog for editing timeline settings

• Improvements: We have a lot of room to fit stuff here. I'm thinking we can add tool buttons that automatically appear based on what is selected (like tools to reverse, pitch shift, time stretch, etc.) when an audio clip is selected.

• I also just realized the lack of zoom tools. We should definitely have those.

Timeline Markers

(top to bottom)

• Bar indicator. The user can also drag on this bar to zoom/pan Bitwig-style.
• Loop indicator - Displays the current loop region. The user can drag handles on the loop region to move it.

Timeline Track Headers

Track Header

• Name of the track. The user can double-click on this to edit the name.
• Decibel meter
• Mixer fader
• Pan knob (to the right of the mixer fader)
• Record arm button
• Solo & mute buttons
• Button that toggles showing/hiding automation lanes underneath
• Botton that opens the synth plugin UI
• Tracks can be re-ordered by dragging on their respective headers
• Add button on the bottom of the last track header that adds a new track

Automation Lanes

• Close/delete button
• Drop-down to select what parameter to automate
• The arrow on the right side can be used to toggle between compact mode (small vertical height) and normal mode
• Automation lanes can be re-ordered by dragging on their respective headers
• Add button on the bottom of the last automation lane that adds a new automation lane

Timeline Grid

Clip

• Titlebar with name. This name can be double-clicked to be edited by the user

  • Concerns: Should clips even have names?

• The little arrows on the left/right sides of the titlebar can be dragged to resize clips

• Dragging anywhere else on the titlebar will move the clip

• The audio clip also has little handles that adjust the fades on the edges of audio clips

• Automation nodes can added/removed/moved directly on the clip itself (like FL Studio)

• Concerns: How should we tackle looping clips? Should we have "linked" clips, or should we have a sort-of looped clip mode like Bitwig has?

• What should audio waveforms look like when the timeline is really zoomed in? Should we display individual samples (like Audacity)? Should there be a limit to how far the user can zoom in?

• How should we handle automation of the tempo (when we get to that after MVP)? Where should the automation lane appear?

Piano Roll

Piano Roll Toolbar

• Pencil mode - Bitwig/Ableton like editing (double-click to add/remove note, single-click and drag to select)
  • Concerns: Should we have an option to have it draw notes on single click for users who are used to FL Studio?
• Paintbrush mode - Paints in notes by clicking and dragging
• Select mode
  • Actually now that I think about it, this is just what the "Pencil mode" should be
• Erase mode - Erases notes
• Slice mode - Slices note in half
• I Beam
  • (I can't actually remember what this was supposed to do, lol)
    (on right side)
• Drop-down to select grid snapping mode
• Button that opens a dialog for editing piano roll settings (like scale, tuning, etc.)

Piano view (left panel)

• Display a musical keyboard and the octave
  • Concerns - How will this look when using a non-12-EDO scale?
  • Should we also have a drum-machine-like mode?

Grid

• Top bar - Like the timeline bar, this can be dragged to zoom/pan Bitwig-style.

Clips

• Clip headers will appear on top. Like on the timeline, the little arrows on the sides can be dragged to resize a clip.
• Piano roll notes

Per-note value editor (bottom panel)

• Dropdown to select what to edit (velocity, pan, etc.)
• Sliders below each note to adjust the value

Track FX Panel (right side)

This design is very up in the air. We may end up doing something completely different.

(top to bottom)

• Drop-down to select the track/bus

• A traditional effect rack. Clicking on a plugin will open its UI. Some simple built-in effects can have inline controls like a slider on a "send" plugin.

• A button below the bottom plugin that can be clicked to add a new plugin

• Pan/Mixer fader

• DB Meter

• Drop down to select which track/bus to send this track to

• Concerns: Should this be on the right side?

Big Concern: Should we even use a traditional vertical-stacked effect rack? The idea is to have a built-in patching plugin. This patching plugin will have built-in controls for things like macros, LFOs, and other control effects (a lot like Bitwig's modifiers). However, I would like more opinions on whether this is a workflow people even want.

We could also opt for a Bitwig/Ableton style horizontal rack with inline UIs. That would definitely have more of a "cool"/"wow" factor. But of course we would need to figure out a system for modulation and modifiers (I don't want it to feel like we're just copying Bitwig).

One issue I have with inline horizontal FX racks is how you constantly have to move back and forth when editing EQs or something across multiple tracks while mixing. I suppose this could be solved by making both an inline and floating version of our built-in plugins, but of course that would be more work.

Status Bar

• A status bar

• Concerns: Should we even have a status bar?

NOT an issue, this is an issue mockup

*Current issue mockup, not an issue. Final issue is subject to change.

Suggestion: Add topics such as "daw" to the project description

In this way, this project can be show up on this page:
https://github.com/topics/daw

This may help the project increase the popularity of visits.

Test Discord Webhook

testing testing testing!

[Design] Fixed point numbers may be better suited to represent time than `f64`

Currently the MVP Design Doc states:

• "MusicalTime - unit of "musical beats" - internally represented as an f64"
• "Seconds - unit of time in seconds - internally represented as an f64"

I have some non-optimal experience using f64 to represent time:

• In a (not publicly available) software synthesizer, I used an f32 and later an f64 to represent the offset in a particular audio file (playing speed was not 100%, but depended on the note being played). I used two counters: one that counted samples (or frames, if you wish) and one that counts "blocks" (groups of samples). Because of rounding errors, the two diverged very quickly, resulting in audible artifacts. It took me quite some time to figure out what was going on. In the end, I used fixed point arithmetic.
• In another project, I used f64 to represent timestamps. Since f64 doesn't implement Ord, I had to do some trickery e.g. for a simple binary search.

In my experience, floating points have the following problems:

• rounding issues
• what to do with nan and inf? (i.e.: it doesn't implement Ord)

How can these be solved when still using floating points?

• rounding issues: be very careful, e.g. do not use two counters, but only one to avoid inconsistency
• use some specialised crate to avoid the possibility of storing nan etc.

What does fixed point solve?

• Fixed point representation does not really fix rounding issues in all situations, but it forces you to think about it.
• Fixed points implement Ord, but instead you need to watch out for overflow/underflow

Does fixed point arithmetic introduce new problems?

• Yes: it leads to more complicated code.

Is there anything that fixed point arithmetic does really fix?

• Yes: with fixed point arithmetic, a + (b + c) = (a + b) + c. This isn't always the case with floating points. I haven't yet encountered a problem where I could pinpoint this floating point behaviour as the cause, but when it does matter, you can be stuck.

All in all, with my experience, using fixed point to represent time would be my first attempt, rather than floating points (even high precision floating points). I think my point is more "Have you considered fixed point representations for time", rather than "Fixed point representations are better."

Note: I'm not suggesting to use fixed point numbers to represent actual audio frames. I'm only talking about time here.

Timeline beat marker bar

Build the bar on top of the timeline grid that displays marker for measures/beats.

Note that this widget will not actually scroll within a tuix scroll container. Instead, this will just draw the various text as a function of the input data.

When zoomed in far enough, this should display additional detail such as beats & beat divisions. This should be displayed as "measure:beat:beat division". For example, "5:3:1/4" means the 1/4 beat division after the 3rd beat after the 5th measure.

This widget will take these data points as inputs:

• width of the timeline area (in pixels)
• horizontal zoom level (1.0 is default zoom level, < 1.0 is zoomed out, and > 1.0 is zoomed in). Just pick something that feels reasonable for a scale of 1.0 (like around 100 pixels).
• horizontal scroll position (represented in units of beats)

CI for building and releasing meadowlark on each commit

I can do this myself (I want to). Should I do it? any inconveniences?

Github actions failing

Github actions shows failures. Pull requests and straight commits should not be allowed if the actions are failing. For this issue:

• Fix all github action failures
• Update repository settings to prevent a pull request being merged in if github actions CI fail to run

Current failures from commit: 8c94a41

check

  error: could not compile `meadowlark` due to 3 previous errors; 95 warnings emitted
  {"reason":"build-finished","success":false}
Clippy results: 0 ICE, 2 errors, 95 warnings, 0 notes, 0 help
Error: Clippy had exited with the 101 exit code

miri - Memory Leak```
error: the evaluated program leaked memory
Error: the evaluated program leaked memory
note: pass -Zmiri-ignore-leaks to disable this check

error: aborting due to previous error; 3 warnings emitted
Error: aborting due to previous error; 3 warnings emitted
error: test failed, to rerun pass -p meadowlark --bin meadowlark

Caused by:
process didn't exit successfully: /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner /home/runner/work/Meadowlark/Meadowlark/target/miri/x86_64-unknown-linux-gnu/ci/deps/meadowlark-c20dddbb7b88e334 (exit status: 1)
Error: The process '/home/runner/.cargo/bin/cargo' failed with exit code 1

[clippy](https://github.com/MeadowlarkDAW/Meadowlark/runs/10662656321)

Executing cargo clippy (JSON output)
Clippy results: 0 ICE, 2 errors, 95 warnings, 0 notes, 0 help
Error: Clippy had exited with the 101 exit code