First of all thanks for this project, looks pretty cool already, super excited to see a DAW written in Rust make progress.

Running it on arm64 (M1) macOS currently crashes with the message:

thread 'main' panicked at 'Could not determine the UTC offset on this system. Possible causes are that the time crate does not implement "local_offset_at" on your system, or that you are running in a multi-threaded environment and the time crate is returning "None" from "local_offset_at" to avoid unsafe behaviour. See the time crate's documentation for more information. (https://time-rs.github.io/internal-api/time/index.html#feature-flags): IndeterminateOffset', /Users/<user>/.cargo/registry/src/github.com-1ecc6299db9ec823/simple_logger-1.16.0/src/lib.rs:409:85

Other apps have encountered the same issue and while local time doesn't seem to really work yet, simple-logger 2.0 defaults to UTC time as a fallback instead of crashing, thereby fixing the issue for now.

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

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

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

In clip.rs, there's an import called "SuperFrames" and this causes a compiler error, because "SuperFrames" is actually "SuperFrame". I have renamed the two instances of SuperFrame in clip.rs, and the dev branch should now compile.

This is my first PR. 😳 I hope I did this right.

I added a simple meter implementation that still needs work, but is works good enough just to add it somewhere currently. I also added all the buttons and a few style elements for everything in the top right

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.

I implemented a basic timeline containing lane manipulation and a basic grid.

Current keybindings (just some settings, nothing set in stone in any way):

• Delete => Delete the selected lane.
• CTRL + T => Insert a new lane.
• CTRL + D => Duplicates the selected lanes.
• CTRL + ArrowUp => Moves the selected lanes up by one lane.
• CTRL + ArrowDown => Moves the selected lanes down by one lane.
• ArrowUp => Moves the focus to the lane above the currently active lane.
• ArrowDown => Moves the focus to the lane below the currently active lane.
• 0 => Toggles the activation state of the currently selected lanes.
• CTRL + O => Enables the currently selected lanes.
• SHIFT + O => Disables the currently selected lanes.
• W => Zooms in vertically.
• S => Zooms out vertically.
• SHIFT + ArrowUp => Decreases the size of the selected lanes.
• SHIFT + ArrowDown => Increases the size of the selected lanes.
• CTRL + A => Selects all lanes.

After playing around with other views and trying to copy the mock-up using the Icon view, I realized that some icons don't maintain a constant size based on the frame it's held in. E.g: Given a frame of size x px, the icon is always x * 0.66 px.

This changes makes sure you can create any icon with the framing and icon size that you want.

I also added a small other function just so you can quickly create an icon with the default size that the mock-up uses.

Created a wrapper for an icon.

Currently, it supports no functionality, but I've thought about adding in a future the following features:

• Icon swapping
• onhover functionality (change color for example)

TO-DO:

• [x] Figure out how to wrap the Label on a Frame so it matches the Figma design (frame is 24px wide, icon is 16px wide inside the frame). --> ~~I don't know if HStack is the preferred solution for the wrapping~~ Fixed
• [x] Change the constant values to an enumerator so no other value can be passed inside the Icon (an thus, not rendering anything).

Fixed some formatting, spelling, phrasing and consistency issues in the MVP_DESIGN_DOC.md file that I noticed while reading through it. A lot of it is me changing - lists to * lists to keep it consistent throughout.

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

Testing the implementation of the LeftBar.

Current things to change:

• [x] Be able to hide the browser with content in it
• [x] The ResizableStack doesn't let resizing: You can hide&show the browser if the window is not resized, but you can't otherwise.
• [x] ~~A better way to modularize the way the browser content is displayed (E.g. adding dynamic content using a HashMap<String, F> where F: FnOnce(&mut Context) or by functions)~~
• [ ] Animations don't work.

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?

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.

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 :)