We need a new UI for the ADSR Envelope.
I believe this should the most simple UI on earth. ;-)

This is the one we used to use before:

Any idea/concept/sketch/suggestion is welcome.

This might not be something that has to be done for the Alpha, but i figured it might be nice to get going if someone's interested.

This article explains what an Euclidean Sequencer is (including some code examples);
http://www.computermusicdesign.com/simplest-euclidean-rhythm-algorithm-explained/

I just set up a very rough sketch of what it could look like (don't mind the amount of steps and colours, stuff like this).

I found this on the Googles, this is basically what it looks like in most appliances;

source

Cheers.

This should be a continuously updated list of things that need to be done, mainly on the c++ backend. Some of these are a good place to start contributing.

• Add some useful information to the debug UI.
  This could also be a virtual keyboard, buttons, rotaries, etc

Opening the mixer, then panning the blue or green channel left by one key press (i.e. pressing Shift + A or Shift + S to pan from "C" to "1L") doesn't display "1L" like the other channels do, but continues to display "C". Panning left again will shift the panning from "C" to "2L".

Original position of panning in each channel:

Pressing Shift + A once:

Pressing Shift + A again:

The keybindings for the desktop version suck. It's allways just been for development, but we should really have some buttons for this stuff in the debug ui. And a list of the bindings maybe

using shift-left let's you go beyond 0.

@D-I-S-K-U-S lets share a bit of progress here
Id like to do this before v0.0.1 if possible?

Well hi there.

Here's a bunch of UI stuff I made, some unused, some trashed, some work in progress.

Feel free to share any (new) ideas and thoughts on the following UI ideas.
New purposes for old ideas and/or UI are also more than welcome.

Here they are with some minor explanations:

— Any kind of distortion

— the Blob. : Might actually be finished this way, but room for change.

— Tornado : Would be for a synth, where the different circles can change in 'floating' height (so in first, all circles would align).

— Kind of a glitchy synth, where you make points on various lines move around, so shapes emerge and go.

— Tremolo of some kind; a bit too clear. As in, too self explanatory and not vague enough.

— Was initially for detuning, but thats a system setting and not an effect, so this screen is unnecessary. Could be cool for something else though. Based on DaVinci's work.

— Magnetic field synth. : you move around the coloured dots, making the arrows react to the 'magnetic field' of those. In some positions you can make the arrows go wild and create total chaos.

— Sacred Geometry synth : like the OP-1 equivelant with the dots and connected lines.

— Initially for reverb or ambient room stuff, could be recycled for something

— Swimming Pool. Was gonna be for reverb.

— Compressor. Dont really like this one, bit like the tremolo. Needs revising.

— Drum Mic'er. This was gonna let you move the microphones around to shape the drum sounds.

— Was gonna be for reverb. Quite like this one, could maybe be recycled for something. Rope was gonna have physics of some kind.

— Was gonna be for delay. Found other UI for this purpose.

— Some kind of level meter UI.

— EQ concept. Very weak, still pretty fun though.

— Nuke synth.

— possible Tremolo/phaser UI.

— Reverb.

— Delay.

I was able to fix the previous command but as soon as I run make I get a few errors

pi@raspberrypi:~/dl/cmake-3.12.0-rc1/jack2/OTTO $ make
[ 4%] Built target tiny-process-library
[ 9%] Built target imgui
[ 12%] Built target nanovg
[ 18%] Built target nanocanvas
[ 21%] Built target external
[ 29%] Built target fmt
[ 31%] Building CXX object src/CMakeFiles/otto.dir//boards/parts/ui/egl/src/egl_ui.cpp.o
/home/pi/dl/cmake-3.12.0-rc1/jack2/OTTO/boards/parts/ui/egl/src/egl_ui.cpp:45:32: error: no member named 'WIDTH' in namespace 'otto::core::ui::vg'
vg::Canvas canvas(nvg, vg::WIDTH, vg::HEIGHT);
~~~~^
/home/pi/dl/cmake-3.12.0-rc1/jack2/OTTO/boards/parts/ui/egl/src/egl_ui.cpp:45:43: error: no member named 'HEIGHT' in namespace 'otto::core::ui::vg'
vg::Canvas canvas(nvg, vg::WIDTH, vg::HEIGHT);
~~~~^
/home/pi/dl/cmake-3.12.0-rc1/jack2/OTTO/boards/parts/ui/egl/src/egl_ui.cpp:52:52: error: no member named 'WIDTH' in namespace 'otto::core::ui::vg'
float xscale = egl.draw_size.width / float(vg::WIDTH);
~~~~^
/home/pi/dl/cmake-3.12.0-rc1/jack2/OTTO/boards/parts/ui/egl/src/egl_ui.cpp:53:53: error: no member named 'HEIGHT' in namespace 'otto::core::ui::vg'
float yscale = egl.draw_size.height / float(vg::HEIGHT);
~~~~^
/home/pi/dl/cmake-3.12.0-rc1/jack2/OTTO/boards/parts/ui/egl/src/egl_ui.cpp:87:65: error: no member named 'HEIGHT' in namespace 'otto::core::ui::vg'
canvas.fillText(fmt::format("{:.2f} FPS", fps), {0, vg::HEIGHT});
~~~~^
5 errors generated.
src/CMakeFiles/otto.dir/build.make:426: recipe for target 'src/CMakeFiles/otto.dir//boards/parts/ui/egl/src/egl_ui.cpp.o' failed
make[2]: *** [src/CMakeFiles/otto.dir/__/boards/parts/ui/egl/src/egl_ui.cpp.o] Error 1
CMakeFiles/Makefile2:99: recipe for target 'src/CMakeFiles/otto.dir/all' failed
make[1]: *** [src/CMakeFiles/otto.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

Just ask anyone that has every played an electronic instrument, pressure sensitive buttons is a huge feature. It's a feature missing from the OP-1.

Even if it was just a single one it would help a lot though all being force sensitive would be preferable.

Force sensitive resistors might be a good fit.
http://www.codetinkerhack.com/2013/01/how-to-add-velocity-aftertouch-midi.html

Just went through the onboarding process, just have two pieces of feedback

1. In https://github.com/topisani/OTTO/wiki/Compiling-and-Running for MAC OSX the instructions say that CLang version should be something like 5.0.0, but the instructions actually end up installing 6.0.1 (could be useful to update the expected output)
2. In the https://github.com/topisani/OTTO/wiki/Compiling-and-Running#build, there is a missing step to actually run the Jackd server. The setup has you put preferences in ~/.jackdrc but is missing a step in the build to actually start it up.

Everything else went perfectly!

OTTO records performance data to a json file in data/timers.json in debug builds. It would be great to be able to analyze this data, maybe draw some graphs, or even have an interactive js visualization.

Using travis, this could be built for each commit, and pushed to a webpage.

For reference, this is the interface for recording data:
https://github.com/topisani/OTTO/blob/master/src/util/timer.hpp

There are quite a few reasons why we need to rename the TOP-1.
First of all, i don't know if you noticed, but its just OP-1 with a T in front. It would be nice to have something completely different, both to not infringe on any trademarks, and to change the perception of this project as a direct clone of the OP-1.
Other than that, its a Totally Obnoxious Project name, and we need something better.

There has been quite a bit of discussion in the discord chat, and we have looked at funny, contrived, clever and stupid acronyms like HAROLD - Has Anyone Really Overtaken Loud Doctors?.
I am not sure an acronym like that is really the way to go, even if its better than HAROLD, but lets hear some suggestions.

Personally, i kinda like Arienette, but id prefer not to talk about it, in case she's listening

Lets hear all the ideas down below ↓↓↓↓

Edit: Ideas im currently most fond of:

OTTO
Arienette
Kenopi (KenoPi ?)

we are still looking for decent display.

Here are the specifications:

• Rpi compatibility with low cpu impact.
• at least 320x240 pixels
• preferred size: ~ 2.8"
• nice price
• bright, good contrast and viewing angles

if you add a display, please add a note why it would fit. Most displays on ali, ebay and ada are cheap, but they do not meet the required quality. Please do not list the obvious displays but rather the ones you really know will work for the otto.

I get to git checkout develop-topisani and everythings fine except when i input rm external/src/gl3w.c it says "rm: cannot remove 'external/src/gl3w.c': No such file or directory".
I also tried cmake -DOTTO_BOARD=rpi-proto-1 -DOTTO_USE_LIBCXX=ON . but I get an error instead:

pi@raspberrypi:~/dl/cmake-3.12.0-rc1/jack2/OTTO $ cmake -DOTTO_BOARD=rpi-proto-1 -DOTTO_USE_LIBCXX=ON
Using libc++ instead of libstdc++
-- CMake version: 3.12.0-rc1
CMake Deprecation Warning at external/fmt/CMakeLists.txt:6 (cmake_policy):
The OLD behavior for policy CMP0048 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.

-- Version: 4.0.1
-- Build type:
CMake Error at external/GSL/CMakeLists.txt:26 (message):
The compiler /usr/bin/c++ has no C++14 support. Please use a different C++
compiler.

-- Configuring incomplete, errors occurred!
See also "/home/pi/dl/cmake-3.12.0-rc1/jack2/OTTO/CMakeFiles/CMakeOutput.log".
See also "/home/pi/dl/cmake-3.12.0-rc1/jack2/OTTO/CMakeFiles/CMakeError.log".

I've restarted fresh 3 times and I'm not really sure where I went wrong.

We need dsp and graphics for a lofi/phone/radio type of effect.

when moving the outpoint close to the inpoint the waveform drawing gets screwed up. See the right side of the following screenshot:

develop branch, commit fae860d

the metronome does not play any sound (at least on OSX)

We need UI for Thibault's DSP.

It's a Ring Modulator inspired by a 'stompbox' called Shallow Water. Hence, a new name would also be a welcome addition. Thibault should probably have the final word in picking a name for it though, as he created the DSP (is my opinion).

Quick explanation (by Thibault):

LPG: Cutoff frequency of an enveloppe-follower modulated low pass filter. (low settings will make the effect darker and more expressive, high settings make the filtering more transparent and subtle)

Rate: Speed of pitch modulation (from imperceptibly modulated to audio-rate pitch modulation)

Depth: Depth of pitch modulation (high settings for very crazy, low settings for chorusey, tape wobbley effect)

Damp: Smoothes the pitch modulation (makes it less steppy and more wavey)

This is something I came up with; feel free to evolve this design, or create anything new. Open to all suggestions.

And these are iterations/versions/animations of the same design:

Cheers!

We need new UI for a (step) sequencer. So mind you, it doesn't specifically need to be a step sequencer. Don't let that limit you. :-)

Anything goes, and anything is welcome.

Good luck!

I have written DSP for a simple synthesizer with 4 controls. I was thinking of including this in the alpha, but in the developer build. So it is not a part of the 'real' alpha, but will be there for developers to have a simple way of seeing how the DSP should be written and how it connects with the backend and how UI is made.

I want to do the same thing with an effect, probably something like a volume and pan and then two other things. Suggestions are welcome!

UI should simply be text with numbers. Very simple.

As of the last 2 commits, this is no longer a working version of OTTO on Sierra.

See attached file.
errorlog.txt

Hi!

So a while ago, I have created a rainbow. Wow! Amazing.
Now, I think it looks pretty rad. But there is no DSP to go with it, and I think that's a shame.

As you might have guessed; this is a call for a DSP Synthesizer to go with this UI. :)

I would say, let your imagination to you to cool places, and make something that you think fits.
Personally, I can see this being really lush and pretty, until you turn an encoder, and it goes all wobbly, modulates some weird parameters, introduces some dirt that yet still sounds dreamy.

Love to hear from anyone.

(This is no priority for the Alpha, but if anyone comes up with something really awesome just in time, it might just go in there? We'll see). ;-)

When I'me in this state

pressing Shift + Right Arrow does this

Edit: seems that the issue is already reported on #31

do I need to say more?
https://en.wikipedia.org/wiki/Open_Sound_Control

Hello there.

So, we (people in the Otto Discord) have been busy coming up with graphics for the delay that 'Jonna (@jmidt)' is working on (DSP-wise). The idea of this graphic is that it represents a tunnel, with a row of lights on the ceiling. It is also partly inspired by the way the new Ableton Live echo works.

Okay, very cool D-I-S-K-U-S; what do all these things on the screen do?
Right. Let me explain.

• F D B
  is the amount of feedback. It's currently a square, but it goes all way round like a circle would. The dial in the square could be feedback-mix or -level.
• T u n n e l
  does all the delay representation. Tone would possibly change the colours of the lines and lights, while spread would split up the two sides, like the Ableton echo does too. You could probably move around the gradient, make it come forward to make the tunnel seem deeper/darker. This is probably also the part (the whole tunnel-part) that we will want to animate a tiny subtile bit, to make it look lively.
• T i m e
  is represented as a number. It tells the amount of (milli)seconds and can be switched to time signatures, so you can have it on 1/4, etcetera.

What I'd love to hear from you guys is;

• What do you think?
• What kind of sounds do you think this DSP should do/make?
• Any things I should change?
• In what way could this animate/move around/interact?

Animation
To illustrate how the OP-1 handles it's delay animation, here's a gif.

OK. Back to the OTTO;
All ideas are very welcome.

There needs to be a UI for the Delay DSP that Jonatan has done.

There is 4 parameters for the Delay:

• Delay time
• feedback
• filter frequency
• stereo spread+flanger

Any suggestion/idea/concept is welcome; please see the UI guidelines.

This "look" like agreat project, but without a video or playable sound file of what this project can do right now, its...eh kind of hard to tell. So please upload something to listen to.

Curious if anyone has successfully built this under OSX - perhaps the right set of homebrew requirements (or even a recipe to install TOP-1). The dependencies don't look too out of the ordinary. I'll give it a shot sometime soon hopefully and submit a PR if I get anywhere with it.

Currently each engine owns at least one buffer, and references to these buffers are passed around in ProcessData. I feel like this is a fairly solid aproach, but with a few problems.

• A lot of unneccessary copying between buffers, especially when faust is involved (take a look at core/audio/faust.hpp
• A few syntactical problems in main_audio.

I feel like the best aproach in the OTTO style, would be to hand over a bit more control to main_audio.cpp, and make it more customizable from there.
So i propose passing an out buffer to Engine::process as well as an in buffer, and let the modules write directly to that. This out buffer then has runtime information, like whether audio should be added to it, or it can be overwritten, as well as which of its channels should be used.

Not sure i explained it perfectly, still gotta flesh it out completely in my head, but id like to hear any thoughts, questions and suggestions (@cbsrobot & @dacarley)

Hey y'all. I figured some sort of shallow water clone would be cool to have.

For reference, here's the original effect: https://www.youtube.com/watch?v=sYWuTmgVU9k

At first I thought I'd try to model it like they did on the pedal, with a repitching delay, but that is not possible with Faust, so I did a rough approximation with Faust's transpose

Here's the code, so far:

import("stdfaust.lib");

// CONSTANTS
nyquist = ma.SR / 2;

lp_min_freq = 10;               //(Hz)
lp_max_freq = 10000;            //(Hz)
lp_default_freq = lp_max_freq;  //(Hz)
lp_env_attack = 0.02;           //(s)
lp_env_release = 0.05;          //(s)
lp_res = 0.4;
noise_filter_order = 2;         //(number of poles)
window_length = 2048;           //(samples)
xfade_duration = 1024;          //(samples)
max_repitch = 3;                //(semitones)
min_rate = 0.02;                //(Hz)
default_rate = min_rate;
max_rate = 20;                  //(Hz)
step_rate = 0.02;               //(Hz)
env_lp_normalizer = 5000;       //(Hz)

//Controls
lpg   = hslider("lpg",lp_max_freq,lp_min_freq,lp_max_freq,0.001) : si.smoo;
rate  = hslider("rate",default_rate,min_rate,max_rate,step_rate) : si.smoo;
depth = hslider("depth",0,0,1,0.001) : si.smoo;
damp  = hslider("damp",0,0,0.999,0.001) : si.smoo;

noise = no.lfnoise(rate) : si.smooth(damp);
repitch = _ : ef.transpose(window_length, xfade_duration, max_repitch * noise * depth) : _;
cutoff(in) = lpg + an.amp_follower_ud(lp_env_attack, lp_env_release,in) * env_lp_normalizer;

process(in) = in : repitch : ve.moog_vcf_2b(lp_res, min(nyquist,cutoff(in))) : _;

It needs refining, like log scale controls and autofilter, but the idea is there

maybe in a config file.

I'd like to start diving into this project but with my limited time and knowledge of C++, it's complicated. I'm sure it would help many other potential contributors if there was a quick setup guide/Docker container/VM image/etc to get started hacking on this. Creating this issue mostly so I get a notification if it's ever done :)

Thanks and best of luck with this project!

We need a generic menu system for settings like

• picking a midi input device
• colour themes
• system updates
• at some point, wifi, bluetooth and other connectivity

similar to vi's insert mode it would be grate to be able to switch from controlling OTTO to playing OTTO with a simple keystroke.

We need the DSP for some synths/effects. These would optimally be written in faust.

• String synth
• Other synths (bring in ideas, ill add them)
• Effects (bring in ideas, ill add them)
• Rewriting the simple-drums (808 style maybe?)

If you do one, remember this:

• 4 continuous settings pr module.
  • can be extended to 8 using the shift key, but only if the synth consists of two "groups" of data, like the simple-drums synth
• 4 toggling settings pr module.
  • should be related to the 4 continuous ones
  • can be extended in the same way
• Each synth also has an envelope screen, which could, if necessary be customized. Lets talk about that

Its a hack, and its very unsafe, as it exposes pretty much everything that should be thread local.
For example, all the audio/midi buffers should be passed to the process methods, as its very important not to touch those outside the audio thread.

One problem could be the isRunning func, but that can maybe be replaced with an exception, which would probably be the correct way, since it shouldnt be catched before main anyway

For now just based on raspbian i think. Might take another stab at a custom distro, but whichever way we go, we need a .img download thats ready to flash on an sdcard. It should have the tools needed for development, along with a compiled binary.

In rpi_input.cpp, the keyboard detection fails on my setup, even though I do have a keyboard plugged.

The culprit is the string device_type passed as an argument:

static int open_device(const std::string& device_type)
  {
    LOGI("Device Type: {}", device_type);
    LOGI("about to auto path = fs::path(\"/dev/input/by-id\"");
    auto path = fs::path("/dev/input/by-id");

    for (const auto& entry : fs::directory_iterator(path)) {
      LOGI("Entered open_device for loop");
      auto file = entry.path().string();
      LOGI("file:{}", file);
      if (ends_with(file, device_type)) {
        auto fullpath = path / file;
        auto fd       = open(fullpath.c_str(), O_RDONLY | O_NONBLOCK);
        LOGI("Opening device {}", fullpath);
        if (fd < 0) {
          LOGE("Couldn't open a file descriptor for {}", fullpath.string());
          return -1;
        }

        auto result = ioctl(fd, EVIOCGRAB, 1);
        if (result != 0) {
          LOGE("Couldn't get exclusive input access to {}", fullpath.string());
          return -1;
        }

        return fd;
      }
    }

    return -1;
  }

2018-06-26 22:02:35.245 (   0.095s) [main thread     ]          rpi_input.cpp:33       0| Device Type: 0-event-kbd
2018-06-26 22:02:35.245 (   0.095s) [main thread     ]          rpi_input.cpp:34       0| about to auto path = fs::path("/dev/input/by-id"
2018-06-26 22:02:35.245 (   0.096s) [main thread     ]          rpi_input.cpp:38       0| Entered open_device for loop
2018-06-26 22:02:35.245 (   0.096s) [main thread     ]          rpi_input.cpp:40       0| file:/dev/input/by-id/usb-Razer_Razer_Arctosa-event-kbd
2018-06-26 22:02:35.245 (   0.096s) [main thread     ]          rpi_input.cpp:38       0| Entered open_device for loop
2018-06-26 22:02:35.245 (   0.096s) [main thread     ]          rpi_input.cpp:40       0| file:/dev/input/by-id/usb-Razer_Razer_Arctosa-event-if01
2018-06-26 22:02:35.245 (   0.096s) [main thread     ]               main.cpp:67     ERR| Could not find a keyboard!
2018-06-26 22:02:35.245 (   0.096s) [main thread     ]               main.cpp:68     ERR| Exception thrown, exitting!

// rpi-input.cpp:108
- static int keyboard = open_device("0-event-kbd");
+ static int keyboard = open_device("-event-kbd");

Can't really be bothered to do a PR at this hour tbh

if anyone can cook up some presets for the current drum synth (avalibable at ctrl-u), and then submit their data.json file here, it would be awesome!

The following code causes a segfault on my setup.

//fbcp.cpp:21    
fbfd = open("/dev/fb1", O_RDWR);

/dev/fb1 does not exist on my setup, and it caused a segfault somehow. Replacing it with /dev/fb0 solved the segfault, as /dev/fb0 exists.

Currently, the order of the rotaries is:

R B W G 

Red needs to go to the far right, since its often used as a gain setting with a slider on that side. Also, white stands out, and for that reason needs to either go to the far left, or be included in the middle. Blue makes a good middle option. Main contenders are:

W G B R 

G B W R 

The order of course has to match the settings on screen, so that's the major thing to consider.

Thoughts?

I can actually do this now that i dual boot and have a windows installation.

Its very low priority though.

And we are only talking about development support, not actually being useful as a dekstop app on windows!

From alpha v0.0.1 master should be stable, and it would be cool to have an in-otto update option. This can either execute the compiler in the background or download a precompiled version. The latter is probably safer

atm jack needs to be started in a terminal window to get the coremidi support with:

jackd -X coremidi -d coreaudio -r 48000 -p 1024

Let's talk about modulation.

In synth mode, there should be a module for modulating the sound. We already have an ADSR envelope for the volume (well, it's not implemented yet, but it is a part of the Faust DSP synth files). So we really just need a screen that controls those variables. But this is our very own MOD matrix!

The following are my thoughts on what it would look like in my little dream world, so feel free to comment!

The modulation (MOD) module should contain two modulation sources: an AD envelope and an LFO. Each source has a DESTINATION (knob 1), and three parameters (knobs 2-4). You would change between controlling the two sources by perhaps an encoder click or shift+mod or something, but it should be possible to have both running at the same time

Controls:

AD envelope:

1. Destination options
   • None/off
   • Synth knob 1
   • Synth knob 2
   • Synth Knob 3
   • Synth knob 4
   • LFO Speed
   • LFO Amount
2. Attack
   Determines the envelope attack time (time from starting value to maximum value). Turning it completely counterclockwise sets it to zero so it skips the attack step.
3. Decay
   Determines the envelope decay time (time from maximum value to ending value). Turning it completely clockwise sets it to infinity so it stays on the maximum value.
4. Amount (±)
   Determines the strength of the envelope. The maximum value of the envelope is always the current value of the destination. This sets the difference between that value and the value where the envelope starts and ends. It can be either positive or negative. If the Amount knob is on the counterclockwise half, the envelope starts lower and moves up to zero (the current setting of the destination). If Amount is set on the clockwise half, it starts above and moves down to zero. If Amount is directly in the middle, the envelope has no effect.

LFO:

1. Destination options
   • None/off
   • Synth knob 1
   • Synth knob 2
   • Synth Knob 3
   • Synth knob 4
   • Volume (tremolo)
   • Pitch (Vibrato)
2. Wave
   • Switches between different waveforms. (Triangle, Saw, Reverse Saw, Square).
3. Speed
   • Determines the speed of the LFO.
4. Amount
   • Determines the strength of the LFO. Setting it completely counterclockwise sets Amount to zero, so the LFO does not change the sound.

Open questions:

• Should the LFO retrigger every time a key is pressed? Or be free running?

Why not just use satellite ccrma?

https://ccrma.stanford.edu/~eberdahl/Satellite/

https://ccrma.stanford.edu/wiki/CCRMA_Satellite_How_To_Connect_RevC

hi,

I got stuck trying to compile OTTO on macOS.

export PATH="/usr/local/opt/llvm/bin:$PATH"

export CC=clang
export CXX=clang++
export CXXFLAGS="-I/usr/local/opt/llvm/include -I/usr/local/include"
export LDFLAGS="-L/usr/local/lib $(brew info llvm | grep LDFLAGS= | cut -d = -f 2 | tr '"' ' ')"

cmake .
make

↓↓↓

Scanning dependencies of target external
[ 18%] Building C object external/CMakeFiles/external.dir/src/gl3w.c.o
In file included from /bla/OTTO/external/src/gl3w.c:31:
In file included from /bla/OTTO/external/include/GL/gl3w.h:34:
/bla/OTTO/external/include/GL/glcorearb.h:616:10: fatal error:
      'KHR/khrplatform.h' file not found
#include <KHR/khrplatform.h>
         ^~~~~~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [external/CMakeFiles/external.dir/src/gl3w.c.o] Error 1
make[1]: *** [external/CMakeFiles/external.dir/all] Error 2
make: *** [all] Error 2

there is a khrplatform.h file, but it's in external/glfw/deps/KHR/khrplatform.h.

$CXX --version:

clang version 6.0.1 (tags/RELEASE_601/final)
Target: x86_64-apple-darwin17.6.0
Thread model: posix

with commit 3573ea3 the sampler crashes when using A ans Q Keys
in the debugger it looks like p2 has no values.

Process 8232 stopped
thread #1: tid = 0x26a16, 0x000000010009a648 otto`void otto::ui::vg::Canvas::plotRounded<std::__1::__wrap_iter<otto::ui::vg::Point const*> >(this=0x00007fff5fbfe4c0, first=__wrap_iter<const otto::ui::vg::Point *> @ 0x00007fff5fbfc6f0, last=__wrap_iter<const otto::ui::vg::Point *> @ 0x00007fff5fbfc6e8, max_radius=2.97855616) + 728 at canvas.hpp:435, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x101400000)
    frame #0: 0x000000010009a648 otto`void otto::ui::vg::Canvas::plotRounded<std::__1::__wrap_iter<otto::ui::vg::Point const*> >(this=0x00007fff5fbfe4c0, first=__wrap_iter<const otto::ui::vg::Point *> @ 0x00007fff5fbfc6f0, last=__wrap_iter<const otto::ui::vg::Point *> @ 0x00007fff5fbfc6e8, max_radius=2.97855616) + 728 at canvas.hpp:435
   432           moveTo(*first);
   433           for (auto [p1, p2] : util::adjacent_pairs(first, last))
   434           {
-> 435             float dx = std::abs(p2.x - p1.x);
   436             float dy = std::abs(p2.y - p1.y);
   437             float r = std::min({dx / 2.f, dy / 2.f, max_radius});
   438             vg::Point md = (p1 + p2) / 2.0;

I'm getting the following error after running make

➜  OTTO git:(master) ✗ make
[  3%] Built target imgui
[  6%] Built target nanovg
[ 11%] Built target nanocanvas
[ 14%] Built target external
[ 20%] Built target fmt
[ 41%] Built target glfw
[ 42%] Building CXX object src/CMakeFiles/otto.dir/core/audio/faust.cpp.o
warning: unknown warning option '-Wc++17-compat' [-Wunknown-warning-option]
In file included from /Users/amila/Documents/Projects/OTTO/src/core/audio/faust.cpp:1:
In file included from /Users/amila/Documents/Projects/OTTO/src/./core/audio/faust.hpp:14:
/Users/amila/Documents/Projects/OTTO/src/./util/type_traits.hpp:6:10: fatal error: 
      'variant' file not found
#include <variant>
         ^~~~~~~~~
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal (use -v to see invocation)
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s).
make[2]: *** [src/CMakeFiles/otto.dir/core/audio/faust.cpp.o] Error 254
make[1]: *** [src/CMakeFiles/otto.dir/all] Error 2
make: *** [all] Error 2
➜  OTTO git:(master) ✗ 

Clang version

Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin