Hmm. I wonder if different mice will give different scroll speeds? The arrow keys are also mapped. Also, I assume you are referring more to when you are wiggling parameters and not when you are scrolling around in the GUI? If so, the fine/coarse/super fine/super coarse behaviors work:
When focused on a parameter:
Use A to toggle between fine/coarse modes.
Hold the N key (SHIFT) while turning your mouse wheel (or using the arrow keys) to activate the super fine (or super coarse) mode.
Correct, seems normal enough when navigating. When wiggling, for example, the phase control on the Sine Osc in coarse mode, I get values of
0.0
0.11
0.25
0.39
0.53
0.67
etc.
Same values on the fdbk control. Going back the other direction in coarse mode I don’t land on 0.0 but on -0.03. Seems like on the hardware in coarse mode I get 0.1 increments.
However, now that I see supercoarse/coarse/fine/superfine work the same way as on the hardware, I can get to the values I need to.
The emulator is built on the excellent Simple DirectMedia Layer (SDL2) which is cross-platform and works on Linux, OS X, and Windows as well many other platforms. It abstracts away all of the window creation, mouse/keyboard events, audio, threading etc. We would just need someone (not me!) to add another ER-301 hardware abstraction layer (HAL) for their target architecture. In fact, the HAL written for Linux is pretty generic POSIX so minimal changes possibly for OS X and Windows?
So I guess you don’t have that file installed. I pushed a commit that allows the emulator to try to load the font from er-301 project tree when the above doesn’t work. So pull and try again, please.
I thought so as well, but even with 4gb and 4vCPUs it was struggling. At least this docker approach is running smoothly, it’s just hard to configure correctly. Might be my specific machine/display or something, I think I read that retina displays cause issues.
This blog post is targeting the exact same case of running an SDL2-based graphical application in docker through an X server. Unfortunately, it is not on OS X.
Actually, I’ve been looking through the emulator source with an eye towards how specific it is to Linux and I don’t see anything at all…
Could someone on OS X, please try following the instructions for compiling the emulator as-is and report back? You will need to do the OS X equivalent things for the sudo apt install ... stuff but other than that it might just work.
[lua.mk linux testing] LINK testing/linux/libs/liblua54.a
make[1]: gcc-ar: No such file or directory
but it’s easy enough to just update the AR value in scripts/linux.mk. Trying to see how deep I can get…
Edit: hal/pump/rfifo4.c complains about the missing malloc header. Updating to stdlib.h gives:
[emu.mk linux testing] C hal/pump/rfifo4.c
clang: warning: argument unused during compilation: '-fmax-errors=5' [-Wunused-command-line-argument]
hal/pump/rfifo4.c:13:33: error: implicit declaration of function 'memalign' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
fifo->buffer = (float32x4_t *)memalign(CACHELINE_SIZE_MAX, bytes);
^
hal/pump/rfifo4.c:13:18: warning: cast to 'float32x4_t *' (aka '__m128 *') from smaller integer type 'int' [-Wint-to-pointer-cast]
fifo->buffer = (float32x4_t *)memalign(CACHELINE_SIZE_MAX, bytes);
^
1 warning and 1 error generated.
So probably need a different version of gcc or something