korginc/logue-sdk

This repository contains all the files and tools needed to build custom oscillators and effects for the prologue synthesizer.

logue-sdk

日本語

This repository contains all the files and tools needed to build custom oscillators and effects for the prologue, minilogue xd, Nu:Tekt NTS-1 digital kit, Nu:Tekt NTS-1 digital kit mkII synthesizers, the Nu:Tekt NTS-3 kaoss pad kit, and drumlogue drum machine.

Existing logue SDK Units

To download ready to use oscillators and effects, refer to the Unit Index and follow instructions on the developer's website.

Platforms and Compatibility

Product	Latest SDK Version	Minimum Firmware Version	CPU Arch.	Unit Format
prologue	v1.1.0	>= v2.00	ARM Cortex-M4	Custom 32-bit LSB executable, ARM, EABI5 v1 (SYSV), static
minilogue-xd	v1.1.0	>= v2.00	ARM Cortex-M4	Custom 32-bit LSB executable, ARM, EABI5 v1 (SYSV), static
Nu:Tekt NTS-1 digital kit	v1.1.0	>= v1.02	ARM Cortex-M4	Custom 32-bit LSB executable, ARM, EABI5 v1 (SYSV), static
drumlogue	v2.0.0	>= v1.0.0	ARM Cortex-A7	ELF 32-bit LSB shared object, ARM, EABI5 v1 (SYSV), dynamic
Nu:Tekt NTS-1 digital kit mkII	v2.0.0	>= v1.0.0	ARM Cortex-M7	ELF 32-bit LSB shared object, ARM, EABI5 v1 (SYSV), dynamic
Nu:Tekt NTS-3 kaoss pad kit	v2.0.0	>= v1.0.0	ARM Cortex-M7	ELF 32-bit LSB shared object, ARM, EABI5 v1 (SYSV), dynamic

Binary Compatibility

User units built for prologue, minilogue xd and Nu:Tekt NTS-1 digital kit (mkI only) are binary compatible with each other, as long as the SDK version matches. However, developers are encouraged to optimize their units for each target platform, and thus specialized builds should be preferred if available.

Repository Structure

• platform/prologue/ : prologue specific files, templates and demo projects.
• platform/minilogue-xd/ : minilogue xd specific files, templates and demo projects.
• platform/nutekt-digital/ : Nu:Tekt NTS-1 digital kit specific files, templates and demo projects.
• platform/drumlogue/ : drumlogue specific files and templates.
• platform/nts-1_mkii/ : Nu:Tekt NTS-1 digital kit mkII specific files, templates and demo projects.
• platform/nts-3_kaoss/ : Nu:Tekt NTS-3 kaoss pad kit specific files, templates and demo projects.
• platform/ext/ : External dependencies and submodules.
• docker/ : Sources for a docker container that allows building projects for any platform in a more host OS agnostic way.
• tools/ : Installation location and documentation for tools required to build projects and manipulate built products. Can be ignored if using the docker container.
• devboards/ : Information and files related to limited edition development boards.

Sharing your Oscillators/Effects with us

To show us your work please reach out to [email protected].

Support

The SDK is provided as-is, no technical support will be provided by KORG.

logue-sdk's Issues

Indicate % cpu used for custom OSC

Is your feature request related to a problem? Please describe.
When a OSC uses too much CPU, it apparently becomes stuck and the only way to stop it is to reboot the Minilogue.
Inversely, I would love to know if my OSC uses only a small amount of CPU, because it would mean I can add more features to it !

Describe the solution you'd like
Have an option to display the % of CPU used by the custom OSC voices on the OLED. That way, it would be easy to monitor how changes to the code impact performance.

Issues with float_math.h

In float_math.h, I have seen a few issues:

• some typos with "ampltitude" which should be replaced with "amplitude"
• in the function fastlogf and fasterlogf, the constant "0.69314718f" should be replaced with the macro MN_LN2
• the function "fasterampdbf" might be even faster if the factor is precalculated instead of being 20.f/fasterlog2f(10)
• the function "fasterdbampf" is wrong, it should be "fasterpowf(10.f, 0.05fdb)" instead of "20.ffasterpowf(10.f, 0.05f*db)"

Extend non-percent parameter range.

Сurrent oscillator parameter of type k_user_prg_param_type_select limited to a range of 0 to 100 which is displayed 1 to 101 that looks awkward. Extending the allowed range to a full 7-bit should not be a problem. It will be backward compatible and also provide additional flexibility for developers (like ability to select from ALL of the intergated waveforms, which is more than a hundred)

Open the sources of logue-cli

Is your feature request related to a problem? Please describe.
It looks like you could need some help with polishing things, especially on Linux where #37 is a show stopper at the moment.

Describe the solution you'd like
If you open the sources, things like this will be quickly sorted out by the community. It looks like you don't have much to lose because the MIDI communication is easily sniffable anyway.

Cannot compile (missing CMSIS arm_math.h)

Describe the bug
Trying to compile the demo code in demos/waves gives the following output:

:waves > make
Compiler Options
../../../../tools/gcc/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -DTHUMB_PRESENT -g -Os -mlittle-endian -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -fcheck-new -std=c11 -mstructure-size-boundary=8 -W -Wall -Wextra -Wa,-alms=./build/lst/ -DSTM32F401xC -DCORTEX_USE_FPU=TRUE -DARM_MATH_CM4 -D__FPU_PRESENT -I. -I./inc -I./inc/api -I../../inc -I../../inc/dsp -I../../inc/utils -I../../../ext/CMSIS/CMSIS/Include

Compiling _unit.c
In file included from ../../inc/utils/fixed_math.h:47:0,
                 from ../../inc/osc_api.h:46,
                 from ./inc/userosc.h:47,
                 from ./tpl/_unit.c:42:
../../inc/utils/cortexm4.h:45:31: fatal error: arm_math.h: No such file or directory
compilation terminated.
make: *** [Makefile:189: build/obj/_unit.o] Error 1

This is on Linux, but I have the exact same problem on a friends Mac computer.

To Reproduce
Steps to reproduce the behavior:

1. Install tools
2. Go to demo code, run make

Expected behavior

Compilation

Desktop (please complete the following information):

• OS: Linux 5 and Mac os Mojave
• Version Downloaded on March 13th

LUTs in Q31

Oscillator runtime API lookups are in float now, but OSC_CYCLE natively uses Q31 format.
This looks weird and leads to excessive calculations, like

• using f32_to_q31 with one FP multiplication per each sample is required
• clipping in +/-1.0 is needed per each sample in case several waves are combined, but not the case for saturated integer math, natively supported by ARM.

I did the test: reversed necessary funcitons of osc_api and float_math to Q31 math, made a precalculation of useneeded LUTs into Q31 format on oscillator init and used only integer math (including Q31) inside the OSC_CYCLE main loop. This gives roughly 50% performance increase. This really makes sence when you trying to combine dozens of waves in unison.

Maybe it is too late to change horses in midstream, but this could give a glue to performance optimization for someone.

Attempting to probe minilogue XD through logue-sdk fails [Linux]

Describe the bug
When I try to probe my minilogue through the cli it produces either "Search device request timed out" or "API version request timed out"

To Reproduce
Here is my terminal output:

✘ adamdc@AdamHome  ~/Documents/loguesdk modules/KorgCorrosion102/minilogue xd  logue-cli probe
Error: Could not find matching logue MIDI ports.

Logue interface connection failed.
  Available MIDI inputs:
    in  0: Midi Through:Midi Through Port-0 14:0
    in  1: minilogue xd:minilogue xd MIDI 1 32:0
    in  2: minilogue xd:minilogue xd MIDI 2 32:1

  Available MIDI ouputs:
    out 0: Midi Through:Midi Through Port-0 14:0
    out 1: minilogue xd:minilogue xd MIDI 1 32:0
    out 2: minilogue xd:minilogue xd MIDI 2 32:1

 ✘ adamdc@AdamHome  ~/Documents/loguesdk modules/KorgCorrosion102/minilogue xd  logue-cli probe -i 1 -o 1
Error: Search device request timed out.
Logue handshake failed.
 ✘ adamdc@AdamHome  ~/Documents/loguesdk modules/KorgCorrosion102/minilogue xd  logue-cli probe -i 2 -o 2
Error: API version request timed out.
Logue handshake failed.
 ✘ adamdc@AdamHome  ~/Documents/loguesdk modules/KorgCorrosion102/minilogue xd  logue-cli probe -v -d -i 2 -o 2

>>> { f0, 42, 50, 0, 55, f7 }
<<< { f0, 42, 50, 1, a, 55, 51, 1, 0, 0, 2, 0, 1, 0, f7 }
> Device: minilogue xd
> System version: 2.10
>>> { f0, 42, 32, 0, 1, 51, 17, f7 }
Error: API version request timed out.
Logue handshake failed.

Expected behavior
Able to probe my minilogue xd

Desktop (please complete the following information):
Arch Linux 5.8.5-arch1-1

./logue-cli probe not working

Describe the bug
When I run ./logue-cli probe from command line (Mac OS X) with the Prologue connected, I get an error.

Error: API version request timed out.
Error: Prologue handshake failed.

To Reproduce
Steps to reproduce the behavior:

$ cd logue-sdk/tools/logue-cli
$ ./get_logue_cli_osx.sh

$ ./logue-cli probe
Error: API version request timed out.
Error: Prologue handshake failed.

# Presumably the following shows the Prologue is connected?
$ ./logue-cli probe -l
  Available MIDI inputs:
    in  0: IAC Driver Bus 1
    in  1: IAC Driver IAC Bus 2
    in  2: prologue MIDI IN
    in  3: prologue KBD/KNOB

  Available MIDI ouputs:
    out 0: IAC Driver Bus 1
    out 1: IAC Driver IAC Bus 2
    out 2: prologue MIDI OUT
    out 3: prologue SOUND

# Could these be the wrong MIDI channels?
$ ./logue-cli probe -o 2 -i 2
Error: Search device request timed out.
Prologue handshake failed.

Expected behavior
I'm not sure exactly what's supposed to happen, but I would presume it would not be 'Error'.

Screenshots
https://github.com/sqpierce/logue-sdk/blob/master/screenshot1.png

Desktop (please complete the following information):

• OS: Mac OS X
• Version 10.13.4 (High Sierra)

Additional context
I believe I have all the dependencies set up. I was able to compile my program, and when doing ./logue-cli check -u /path/to/my/unit I get a good result

> Parsing unit archive
> Parsing manifest
> Parsing unit binary payload
> Looks okay.

Is the Prologue meant to be started in a special mode for this to work? (i.e. hold down 6 and or 8 as when doing software updates?)

Thanks!

Extra parameters for effects

Is your feature request related to a problem? Please describe.
The API and json files currently support extra parameters for effects, just like custom oscillators, but these can't be accessed through the front panel (that I know of).

Describe the solution you'd like
(this is for the minilogue XD - hopefully it can translate easily to the other hardware units).
In "Program Edit" mode, have button 11 (currently inactive) access parameters for whatever custom delay is selected by the "Mod/Del/Rev" switch. Navigation would work exactly like button 10 (for custom oscillator parameters).

Shape LFO parameter: NTS1 and minilogue xd

Describe the bug
NTS-1 and minilogue xd give different values for shape_lfo parameter in OSC_CYCLE.

To Reproduce
Build square osc in the osc/tests/square and install it to NTS-1 and minilogue xd.
Set LFO rate to slow ( < 1Hz), LFO target to pitch, and maximize intensity.
Hit any key and hear how the pitch changes. NTS-1's pitch never goes down under the key while minilogue xd goes.

Expected behavior
I think minilogue xd's behavior is more preferred.

Screenshots
The attached image shows how PWM changes with LFO. In both cases, the intensity is the max value.

Minilogue XD: Arp does not stay in sync via MIDI

Describe the bug
The Arpeggiator does not stay on time/in sync to a MIDI clock signal

To Reproduce
Steps to reproduce the behavior:

1. Connect the MLXD via MIDI to a PC with a DAW installed, f. E. Ableton
2. Set the MLXD clock to external & Midi
3. (also the arp clock)
4. play a simple drum sequence in the DAW, or anything similar as reference
5. Play any arpeggiator on the MLXD and keep it running for a while
6. 5. Notice how the rythm drifts off from the time

Expected behavior
After a short while the arpeggiator drifts off from the time.
Seems also to be a problem with bpm delays.

Desktop (please complete the following information):

• Win
• 10

Additional context

Seems also to be a problem with bpm delays!

Notenumber overflow occurs when downward pitch bend receive during playing lowest note.

Describe the bug

The note# is stored in higher 8bit of user_osc_param::pitch as uint8_t datatype.

In my recognition, when NTS-1 receive a pitch bend MIDI message, note# stored in higher 8bit of user_osc_param::pitch is decremented (for pitch down) or incremented (for pitch up) from actual MIDI note# by NTS-1 system software.

Upward pitch bend message is OK, but downward pitch bend seems like:

MIDI Pitch bend value	user_osc_param::pitch
-4096 <= pitchbend < 0	actual MIDI note# -1
-8192 <= pitchbend < -4096	actual MIDI note# -2

So, when playing MIDI note#0 and any downward pitchbend received, overflow occurs because of unsigned integer (same problem occurs when playing MIDI note#1 and pitchbend less than -4096 received).

If this occurs, the playing tone's pitch gets extremely high (seems overflowed value is treated as higher note# by NTS-1 system software).

This problem occurs in both of preset oscillators and user oscillators.
The developer has no way to get real MIDI note# or pitch bend value, it should be fixed in NTS-1 system software.

To Reproduce
Steps to reproduce the behavior:

1. Choose any oscillator in NTS-1
2. Send note#0 on midi message
3. Send negative (any value within -1 to -8192) pitch bend midi message
4. The tone frequency gets incorrect

Expected behavior
The tone should be played correct frequency

Screenshots
N/A

Environment
NTS-1

send data to midi out

Hi
I did not find any code example to send midi messages to midi output. Is this feature already implemented or even is it technically possible for the api to access to physical input/output (cv would also be interesting)
Thanks

Modulation improvements

Are the LFO waveforms in the XD are software generated? If so, a feature request would be to replace the seldom-used shift-square and shift-triangle waves with S&H and slew-limited S&H waveforms, respectively. Another feature that might be possible, because the input CV can be routed to control so many destinations under processor control, is to open the mod destinations up via a software API to developers, which would allow developers to implement all sorts of software modulation sources and sequencers.

logue-cli load issue on Linux

Hi,
I am trying to upload third-party oscillators using logue-cli to a Minilogue XD on Linux. Unfortunately, I seem to get different symptoms consistently for different respective oscillators. One symptom is a timeout, with the message ALSA: seq_midi: MIDI output buffer overrun showing up in dmesg at the time of the issue. The other symptom is an actual midi error from the application, without the same message in dmesg. I am speculating that these could be similar. I am wondering what steps I could try, to help get to the bottom of the issue. I was able to upload a self-compiled version of the waves sample oscillator, which makes me wonder if it's something specific with size or something else about the oscillators that causes the MIDI error. I tried both compiling the third-party oscillators myself and using the precompiled version, without luck. Please let me know if more verbose output would help; I can see a wall of hex when I run the tool in debug mode, before it times out.

r@r-desktop:~/scratch/korg_testing/eurorack-prologue/eurorack_minilogue-xd$ logue-cli load -i 2 -o 2 -u mo2_va.mnlgxdunit 
> Parsing minilogue xd unit archive
> Parsing manifest
> Parsing unit binary payload
> Handshaking...
> Target platform: "minilogue xd"
> Target module: "Oscillator"
> No slot specified, using first available.
size: 2bdc crc32: ba535d39
Error: Unit load request timed out.
Error: Failed to load unit.
r@r-desktop:~/scratch/korg_testing/eurorack-prologue/eurorack_minilogue-xd$ logue-cli load -i 2 -o 2 -u mo2_add.mnlgxdunit 
> Parsing minilogue xd unit archive
> Parsing manifest
> Parsing unit binary payload
> Handshaking...
> Target platform: "minilogue xd"
> Target module: "Oscillator"
> No slot specified, using first available.
size: 4174 crc32: e8c31dc6

MidiOutAlsa::sendMessage: error sending MIDI message to port.

Error: Unit load request timed out.
Error: Failed to load unit.

OS version: Linux Mint 19.1 (based on Ubuntu 18.04)
Minilogue XD firmware version: 2.10
Kernel version: 4.15.0-88
alsa-base package version: 1.0.25

Display issue with long parameter values on drumlogue

Under certain conditions when two adjacent parameter have long string values the rendering area might overlap, thus producing pixel artefacts with parameter value changes.

Support MSYS2 64-bit platform for windows

Is your feature request related to a problem? Please describe.
Template and demo project Makefiles broken for 64-bit msys2 / windows environment.

Describe the solution you'd like
Fix Makefiles to ensure ZIP tool dir is correctly set for msys2 64-bit windows env.

Describe alternatives you've considered
Use 32-bit version of msys2 for building projects or manually fix makefile conditional logic to check for msys2 / windows build flavor more appropriately.

Additional context
Makefile expects $(MSYSTEM) to equal "MSYS" for msys2 platform. However, when using the 64-bit version, $(MSYSTEM) is MINGW64. Ideally, a less flakey approach for checking the build env should be used, or the Makefile should be modified at line 31 to check for both cases before overriding ZIP path.
E.g.,
ifneq ($(MSYSTEM), MSYS)
ifneq ($(MSYSTEM), MINGW64)
ZIP = ....
endif
endif

See:
Makefile.fixed.txt

logue-cli fails to detect the Minilogue XD on Linux

After installing logue-cli on Linux (Xubuntu 19.10), it doesn't seem to recognize the Minilogue XD, even though it lists it clearly.

The output of logue-cli probe is shown below:

EDIT: Scratch this. I was able to get it to work by specifying MIDI ports. It'd be nice to have the auto-detection work though. For those interested:

logue-cli not working for minilogue xd

get_logue_cli_osx.sh currently fetches:

http://cdn.storage.korg.com/korg_SDK/logue-cli-osx-0.03-0b.zip

That utility does not yet support the minilogue xd.

Pls check

Panel issues with string parameter value under certain conditions on drumlogue

Panel and display become garbled when the displayed value of string type parameter in motion edit exceeds some length or display width. The same value are correctly displayed with the parameter change itself.
e.g.
HARPSICH 1

Waves Makefile error

I'm trying to build "waves" project on msys using "make" command and getting this error

Compiling _unit.c
Compiling waves.cpp
Linking /home/logue-sdk/platform/nutekt-digital/waves/build/waves.elf
c:/msys64/home/logue-sdk/tools/gcc/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/.
./../../../arm-none-eabi/bin/ld.exe: cannot open linker script file /home/logue-sdk/platform/nutekt-
digital/waves/ld/userosc.ld: No such file or directory
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:187: /home/logue-sdk/platform/nutekt-digital/waves/build/waves.elf] Error 1

Any suggestions?

OSC_NOTEOFF not invoked until all keys are released

OSC_NOTEOFF documentation says it is "Called whenever a note off event occurs." This is a bit vague, but arguably the behavior should mirror midi note off events.

When multiple keys are held down and released one-by-one, the release of each key produces a midi note off event. However, when these midi messages are passed to the NTK1, OSC_NOTEOFF is only invoked when the last held note is released.

To Reproduce
I used sendmidi to send the midi commands below.

1. Replace the OSC_NOTEOFF code of the Waves oscillator to turn on bit crush:

  s_waves.params.bitcrush = clip01f(1.5f);
  s_waves.state.flags |= Waves::k_flag_bitcrush;

2. Compile, load and select oscillator.

3. Send midi note on 50. Sound starts as expected.

4. Send midi note on 51. Pitch goes up one semitone as expected.

5. Send midi note off 51.
   Expected: Pitch goes down one semitone, bitcrush is enabled.
   Actual: Pitch goes down one semitone, bitcrush is not enabled - i.e. OSC_NOTEOFF is not invoked.

6. Send midi note off 50. Sound stops as expected. Bitcrush is enabled (can be verified by setting EG to Open).

Debugging features

Is your feature request related to a problem? Please describe.
It's really hard to investigate what's going on when things don't play the way I'd expect

Describe the solution you'd like
A method allowing to print a string to the OLED display would be ideal for debugging purposes.

NOTEON handler invocation is deffered

Tried to implement a software voice assignment on NTS-1 and failed. Looks like NOTEON handler is delayed untill oscillator is currently in progress so it is virtually impossible to mix a polyphonic sound inside CYCLE handler. I realize this is something out of the scope of the device specification but anyway there is a reasonable question how actually NOTEON/NOTEOFF handlers are expected to work.

SDK 2.0 Pitch Bend sensitivity and range should be documented

It worth to mention explicitly here
https://github.com/korginc/logue-sdk/blame/master/platform/drumlogue/README.md#L326
what is the range and sensitivity for Pitch Bend implied.
One can only assume it is 0-16383 raw for +/- 24 semitones.

OSC_PARAM changes all parameters to zero before first OSC_CYCLE call

Describe the bug
(It may not be a bug but an issue of API specification. Anyway, I report this because someone might come into the same issue or have some solution for this issue.

I set a global variable to a non-zero value in OSC_INIT(). The variable also can be modified from OSC_PARAM(). At the first OSC_CYCLE() call, the variable is always zero. If I remove the lines modifying the variable from OSC_PARAM(), the issue would disappear. I think this is because OSC_PARAM() is invoked with all parameters are zero' ed, after OSC_INIT() and before the first OSC_CYCLE() call,
So, how can I initialize parameters in OSC_INIT() with keeping it modifiable from OSC_PARAM()?

To Reproduce

#include "userosc.h"

#define SINE   0
#define SQUARE 1

typedef struct State {
  float phase;
  uint8_t wave;
} State;

static State s_state;

void OSC_INIT(uint32_t platform, uint32_t api)
{
  s_state.phase = 0.f;
  s_state.wave = SQUARE;          /* wave is set to SQUARE, but... */
}

void OSC_CYCLE(const user_osc_param_t * const params,
               int32_t *yn,
               const uint32_t frames)
{
  const float w0 = osc_w0f_for_note((params->pitch)>>8, params->pitch & 0xFF);
  float phase = s_state.phase;

  q31_t * __restrict y = (q31_t *)yn;
  const q31_t * y_e = y + frames;

  for (; y != y_e; ) {
    float sig;
    switch (s_state.wave) {        /* wave is ALWAYS SINE ! */
    case SINE:
      sig = osc_sinf(phase);
      break;
    case SQUARE:
      sig = osc_sqrf(phase);
      break;
    }

    *(y++) = f32_to_q31(sig);

    phase += w0; phase -= (uint32_t)phase;
  }
  s_state.phase = phase;
}

void OSC_NOTEON(const user_osc_param_t * const params){}
void OSC_NOTEOFF(const user_osc_param_t * const params){}

void OSC_PARAM(uint16_t index, uint16_t value) {
  switch (index) {
  case k_user_osc_param_id1:
    s_state.wave = value;          /* removing this line solves the problem */
    break;
  default:
    break;
  }
}

Expected behavior
OSC_PARAM() initializes all parameters to "initial values," which should be specified in the manifest file.

Desktop (please complete the following information):

• OS: [NTS1]
• Version [1.1-0]

Cycling74 ~gen / RNBO example

Is your feature request related to a problem? Please describe.
No available example for building Louge engines using Cycling74 ~gen or RNBO.

Describe the solution you'd like
A simple example along with the documentation of building engines using ~gen and RNBO.

I'm not sure if there is a possibility to export a ~gen or RNBO project and use it as a sound engine for Korg. If so, is there any available documentation with a simple example?

Thanks

(XD) User mod effect initialization clears a portion of memory used by the user delay effect

Description
On API Version 1.0.0 (no support for 1.1.0 on minilogue yet), currently, a user delay effect that is using sdram will have part of it's memory cleared whenever you select a user MOD effect. This will occur with any user mod effect, even one that 'does nothing', as described below. This does not appear to occur with the factory delays.

Reproduction:
1. Create a MOD effect that does nothing - i.e. just passes audio through (thus is not clearing or initializing any memory of its own)
E.g. :

#include "usermodfx.h"
void MODFX_INIT(uint32_t platform, uint32_t api)
{
}
void MODFX_PROCESS(const float *main_xn, float *main_yn,
const float *sub_xn, float *sub_yn,
uint32_t frames)
{
const float * mx = main_xn;
float * __restrict my = main_yn;
const float * my_e = my + 2*frames;
const float *sx = sub_xn;
float * __restrict sy = sub_yn;

for (; my != my_e; )
{
// pass through sub channel
*(sy++) = *(sx++);
*(sy++) = *(sx++);
// Pass through for main channel
*(my++) = *(mx++);
*(my++) = *(mx++);
}
}
etc....

2: - Ensure this mod effect is loaded in to the synthesizer (must be at least 1 loaded).

3: Either create a user delay that uses using __sdram, or much easier, build and load the supplied example "Delay line". Set the delay time to the maximum, and with a sustained note held, you should hear the 'doubling' caused by the delay (expected).

3:. While holding this note (to keep the delay active), cycle through the MOD fx until you land on USER - you should hear the 'doubling' delay briefly silence before being refreshed by the delay line effect.

Now, with the delay line effect, this appears only as an intermittent dropout. However, if you are creating a significantly longer delay, you will notice that a significant chunk of the audio (at the beginning of the buffer typically) is 'wiped out' when selecting a USER mod effect.

Expected behavior
Initializing a user MOD effect should not clear memory outside of the allocated range for user MOD effects.

** Software Versions **
System : 1.11
Panel 1.01
Voice 1.01

Additional context
I can "work around" this issue by allocating ~724000 (or so - was determined empirically) bytes of "wasted" __sdram ( 181000 floats) "before" my actual memory usage (note you have to actually "do something" with this ram to prevent it being optimized out). This shortens the total delay time, but it works around this issue..

Customize display of parameter values

Is your feature request related to a problem? Please describe.
The manifest.json file is used to specify ranges for the parameters, but there is no way to customize how these display on the OLED. For example a parameter with 3 values for setting a LFO shape to Sine, Square and Triangle, will display as "1", "2", "3".

Describe the solution you'd like
Add a new hook method:
void _hook_display(uint16_t index, uint16_t value, char* display);
The custom osc/fx would write in the provided "display" buffer string, which text to show when parameter 'index' has value 'value'.

Question: what is the range of the value parameter for effects?

I have a simple question: in the following code what is the range of the value of valf? Is it [-1,1] or is it [0,1]?

void DELFX_PARAM(uint8_t index, int32_t value)
{
  const float valf = q31_to_f32(value);
// range of valf = ??
  
...

Thanks for any help!

`user_osc_param` does not expose velocity data

Is your feature request related to a problem? Please describe.
I would like to modulate my oscillators based on velocity input. Currently this is unavailable via the user_osc_param, which would seem like a likely place to pull this from.

Describe the solution you'd like
I do see that the user_osc_param has an extra three bytes of padding. Allocating one of those bytes for velocity measurements seems like a reasonable solution.

missing dependencies for compiling Waves on OSX El Capitan v10.11.6

Describe the bug
I have an iMac running OSX El Capitan v10.11.6. I followed instructions in https://github.com/korginc/logue-sdk/blob/master/platform/prologue/README.md under Building a Project section including all the instructions for setting up the toolchain. I went into the logue-sdk/platform/prologue/demos/waves directory and ran make. The following error

Justins-iMac:waves justin$ make
Compiling _unit.c
In file included from ../../inc/utils/fixed_math.h:47:0,
from ../../inc/osc_api.h:46,
from ./inc/userosc.h:47,
from ./tpl/_unit.c:42:
../../inc/utils/cortexm4.h:45:31: fatal error: arm_math.h: No such file or directory
compilation terminated.
make: *** [build/obj/_unit.o] Error 1

To Reproduce
Steps to reproduce the behavior:

1. clone logue-sdk
2. follow instructions for setting up toolchain for OSX
3. from logue-sdk/platform/prologue/demos/waves directory run 'make'

Expected behavior
results in compilation error
In file included from ../../inc/utils/fixed_math.h:47:0,
from ../../inc/osc_api.h:46,
from ./inc/userosc.h:47,
from ./tpl/_unit.c:42:
../../inc/utils/cortexm4.h:45:31: fatal error: arm_math.h: No such file or directory
compilation terminated.
make: *** [build/obj/_unit.o] Error 1

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: OSX El Capitan v10.11.6.
• Version: El Capitan v10.11.6.

User facing osc-specific parameters are not exposed to MIDI

User facing osc-specific parameters are not transmitted to MIDI and either changeable with control change messages. Given Shape and ShiftShape is sent/received from MIDI, developer expectations are to include the user messages too.

Option for NTS-1 to recall last used settings...

Is your feature request related to a problem? Please describe.
I'm always frustrated when... turning NTS-1 on and having to start from scratch even though I usually just want the same filter and effect settings. :)

Describe the solution you'd like
Option to recall last used settings (and perhaps an "init" shortcut).

Describe alternatives you've considered
I have tried to look into how I could implement this myself in code, but I have sadly failed.

Params that can hold negative values are not initialized properly

Describe the bug
I'm creating an oscillator that uses a param with range -100% to 100%. When I switch to an Init Program on the Prologue, and switch to my custom oscillator, it sounds like the parameter is set to -100% (i.e. a call was made to OSC_PARAM with a value argument of 0). However, when you go into the "edit mode" on the prologue, it displays a value of 0% (which means the argument to OSC_PARAM should have been 100). Changing the value in the edit menu resumes correct and expected behavior.

To Reproduce

1. Create a simple oscillator program that uses a param range of -100% to 100%. Design this program such that the sound will be audibly different with values of -100% and 0%.
2. After uploading the oscillator to the device, open an init program. Verify in the menu (without changing the value) that the parameter is set to 0%.
3. Play some notes with the oscillator. Note the sound generated.
4. Change the parameter's value to 1%, then back to 0%.
5. Play some notes with the oscillator. Note the change in the sound generated.

Expected behavior
I would expect the sound heard in steps 3 and 5 to be the same. Instead, when you play notes in step 3, it sounds like the param is set to a value of -100%.

Desktop (please complete the following information):

• OS: [Ubuntu in WSL]
• Device: [prologue ver 2.00]

Additional context
This seems related to issue #35 . It's my expectation that calls to OSC_PARAM should be made upon initialization of the oscillator, in order to set up the oscillator if it is a part of a preset. However, we ought to be able to set default values, and even if we can't, there should never be a situation where the value the user is shown is different from the last value sent to the custom OSC_PARAM.

Number of presets in header misinterpreted in drumlogue

When num_presets header field of the user synth (at least checked with it) equals to N > 0, drumlogue allows to select from 0 to N.

MIDI messages callbacks value resolution increase for dtumlogue SDK

To avoid API changes in future it make sense to increase the resolution for the values passed to the callbacks in this section:
https://github.com/korginc/logue-sdk/blame/master/platform/drumlogue/README.md#L319 in compliance with MIDI 2.0 specs:
Velocity should be 16-bit
Pitch bend, Channel pressure and Aftertouch - all 32-bit

Knob controls being sent to incorrect FX module (delfx and revfx)

Describe the bug
Even if the FX mode is switched from delfx to revfx, the knob values is being sent to delfx, and vice-versa.

To Reproduce
Steps to reproduce the behavior:

1. Push DELAY button to set the FX mode to delfx.
2. Select any delay module by TYPE knob.
3. Use A or B knob to control the module.
4. Push REVERB button to switch the FX mode to revfx.
5. Without touching TYPE knob, twist the A or B knob.

(Issue) Then, the knob controls will be sent to the delfx module, although the FX mode is in revfx currently (due to the step 4 above).

6. Select any reverb module by TYPE knob.

Then, the knob controls will start to be sent to the correct revfx module.

Expected behavior
The knob controls should be sent to the selected modules.

Screenshots
N/A

Desktop (please complete the following information):

• OS:
  $ sw_vers
  ProductName: Mac OS X
  ProductVersion: 10.15.2
  BuildVersion: 19C57

• Version
  $ ./logue-cli probe -i 0 -o 0

Device: nutekt digital
System version: 1.03
Logue API version: 1.01-0
Available modules:

Additional context
N/A

fastpow2f bug

logue-sdk/platform/prologue/inc/utils/float_math.h

Line 680 in ab654af

float clipp = (p < -126) ? -126.0f : p;

Current fastpow2f suffer from the lost of precision. depending on the input value it could be times worse then with faster2f

offset must be applied like in the original verion https://github.com/pmineiro/fastapprox/blob/master/fastapprox/src/fastexp.h#L54

Demos for the effects?

This is a really amazing resource. The NTS-1 is the kind of synthesizer I've always dreamed of, being able to program with a really well developed framework is fantastic.

I found all the instructions useful for cloning the repo, installing the toolchain, etc. I found that the demo for the waves is absolutely crucial for me to get going on programming difference oscillators.

Is there any demo for the effects? I'm interested in making a delay. The template folder for the effect is a crucial starting point, but the included code is still a little too bare bones for me to tinker with.

Please let me know if this repo has any effects demos I missed, or if anyone else out there has effects demos that they could share! I did find @dukesrg's fork with cool effects but it looks as if its deviated quite a bit from the original template in this repo.

Panel issues under certain conditions with the parameter name on drumlogue

When the name of 4th parameter on a parameter page exceeds the display length (presumably), the panel and display are garbled.
e.g.

        {0, 10000, 0, 0, k_unit_param_type_hertz, 3, k_unit_param_frac_mode_decimal, 0, {"LFO X"}},
        {0, 10000, 0, 0, k_unit_param_type_hertz, 3, k_unit_param_frac_mode_decimal, 0, {"LFO Y"}},
        {0, 10000, 0, 0, k_unit_param_type_hertz, 3, k_unit_param_frac_mode_decimal, 0, {"LFO Z"}},
        {0, 10000, 0, 0, k_unit_param_type_hertz, 3, k_unit_param_frac_mode_decimal, 0, {"LFO Rate W"}},

Redundant masking of X1 value in osc_wave_scanf/osc_wave_scanuf

logue-sdk/platform/prologue/inc/osc_api.h

Line 559 in ab654af

const uint32_t x1 = (x0 + 1) & k_waves_mask;

Waves LUT already has a trailing entry, so x0 + 1 newer will be out of bounds.

user_osc_param::cutoff and user_osc_param::resonance not working...

Description
Currently, with the minilogue xd running the latest 2.01 firmware, with a user oscillator, at
void OSC_CYCLE(const user_osc_param_t * const params, int32_t *yn, const uint32_t frames)

, params->cutoff and params->resonance appear to constantly return values of what appear to be 0x1FFF (8191), regardless of the settings of the cutoff, resonance, any filter modulation, or the multi oscillator being routed pre/post VCF.

To Reproduce
Steps to reproduce the behavior:
Do something with params->cutoff and/or params->resonance. To test this, I created a simple oscillator that used the params->cutoff as the oscillator frequency. With the multi oscillator selected and a simple (default) gated amplitude EG, this oscillator's frequency should change with the filter cutoff knob, and / or when filter EG / LFO is applied (if applicable)

Expected behavior
The params->cutoff and params->resonance should perform the expected behaviour. Note at this time this isn't explicitly specified in the current API documentation, I myself am hoping it follows the current filter value including any modulation or envelope generation.

Additional context
I am curious to know how this will perform, as mentioned earlier - at least for my current use case - it would be ideal if it followed the existing VCF frequency including any modulation. Note, in testing I also divided this params->cutoff value by 4 and sure enough the generated frequency was fixed at around ~2047hz, so I can be reasonably sure the maximum value of 0x1FFF was only ever being passed.

Cant Compile

ve just set up the project accordingly but receive an error when I try to compile the demo:
user@pc:~/prologue_sdk/logue-sdk/platform/prologue/demos/waves$` make
Compiler Options
../../../../tools/gcc/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -DTHUMB_PRESENT -g -Os -mlittle-endian -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -fcheck-new -std=c11 -mstructure-size-boundary=8 -W -Wall -Wextra -Wa,-alms=./build/lst/ -DSTM32F401xC -DCORTEX_USE_FPU=TRUE -DARM_MATH_CM4 -D__FPU_PRESENT -I. -I./inc -I./inc/api -I../../inc -I../../inc/dsp -I../../inc/utils -I../../../ext/CMSIS/CMSIS/Include

Compiling _unit.c
make: ../../../../tools/gcc/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc: Command not found
Makefile:190: recipe for target 'build/obj/_unit.o' failed
make: *** [build/obj/_unit.o] Error 127
I checked if its a simple path-missmatch but the file is there. I use an up to date Ubuntu 16.04 system. Any suggestions are welcome.

Waves Demo Build Error

When trying to compile the waves demo for NTS-1 on Windows 10 I get the following error:

Compiler Options
../../../../tools/gcc/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -DTHUMB_PRESENT -g -Os -mlittle-endian -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -fcheck-new -std=c11 -mstructure-size-boundary=8 -W -Wall -Wextra -Wa,-alms=./build/lst/ -DSTM32F446xE -DCORTEX_USE_FPU=TRUE -DARM_MATH_CM4 -D__FPU_PRESENT -I. -I./inc -I./inc/api -I../../inc -I../../inc/dsp -I../../inc/utils -I../../../ext/CMSIS/CMSIS/Include
ECHO is off.
The syntax of the command is incorrect.
make: *** [Makefile:173: build] Error 1

I've followed the instructions including necessary tools/updates. Any suggestions? Thanks.

get_gcc_linux.sh does not work on Raspbian

Describe the bug
The script logue-sdk/tools/gcc/get_gcc_linux.sh does not work on Raspbian - it returns "This script is meant for Linux."

To Reproduce
Steps to reproduce the behavior:

1. Install clean Raspian (Raspberry Pi 3 Model B V1.2)
2. Clone logue-sdk.git
3. Run get_gcc_linux.sh
4. See error

Expected behavior
The script should be able to run on Raspberry PI.

I had a look around the web and this let me install a version of gcc-arm-none-eabi:
sudo apt-get install software-properties-common
sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi

Desktop (please complete the following information):

• OS: Raspbian Stretch With Desktop, Image with desktop based on Debian Stretch
  Version: April 2018
  Release date: 2018-04-18
  Kernel version: 4.14

Negative parameter values displayed as "999"

Describe the bug
Negative parameter values for both percent and typeless values displayed as "999" at leas at NTS-1

To Reproduce
Steps to reproduce the behavior:

1. Make custom oscillator with parameter of percent type from -100 to +100
2. Set parameter knob to anything less than 12 o'clock
3. observe '999' displayed while listen that sound actually reflects parameter changes.

Expected behavior
Should correctly display -100...100 at least for percent type values according to SDK manual.

Screenshots
If applicable, add screenshots to help explain your problem.

unable to compile waves demo on WLS

Describe the bug
When attempting to make waves for the XD the following error occurs:

Compiling _unit.c ../../../../tools/gcc/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc: 1: ../../../../tools/gcc/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc: Syntax error: word unexpected (expecting ")") Makefile:190: recipe for target 'build/obj/_unit.o' failed make: *** [build/obj/_unit.o] Error 2

I am running WSL with my loge-SDK repo inside D:\ the the SKD is a submodule of another project

To Reproduce*
Steps to reproduce the behavior:

1. make wthin the waves dir

Expected behavior
successful compilation

Desktop:

• Windows 10:
• WSL v.1

Additional context
gcc works

Provide ARM Linux binary for logue-cli

Please consider providing the cli-logue command for ARM architecture. What i mostly have in mind are Raspberry Pi users.

The cli-logue command is available to a number of platforms including x86 based GNU/Linux, but not ARM. I would like ARM to be one of the alternatives for get_logue_cli_*.sh in tools/logue-cli, or for the Linux downloader to get a binary which runs on ARM.

I've tried to implement some of the features, most notably probing installed custom oscillators and effects, in custom tools but have not yet succeeded. Anything I would be able to make would however not have from the great visibility to other users as this central repo with Korg.

This would help integrate these great Korg devices with RasPi based setups involving e.g. monome norns, SonicPi or other RasPi-based devices serving as computing nodes.

Preset name is not displayed on drumlogue

The preset nama returned with unit_get_preset_name(...) callback function is ignored and preset number is displayed instead.