korginc / logue-sdk Goto Github PK
View Code? Open in Web Editor NEWThis repository contains all the files and tools needed to build custom oscillators and effects for the prologue synthesizer.
License: BSD 3-Clause "New" or "Revised" License
This repository contains all the files and tools needed to build custom oscillators and effects for the prologue synthesizer.
License: BSD 3-Clause "New" or "Revised" License
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.
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.
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:
Expected behavior
Compilation
Desktop (please complete the following information):
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.
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:
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.
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.
Oscillator runtime API lookups are in float now, but OSC_CYCLE natively uses Q31 format.
This looks weird and leads to excessive calculations, like
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.
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
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.
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.
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?
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
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"}},
The preset nama returned with unit_get_preset_name(...) callback function is ignored and preset number is displayed instead.
Under certain conditions when two adjacent parameter have long string values the rendering area might overlap, thus producing pixel artefacts with parameter value changes.
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
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:
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.
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
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):
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.
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.
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:
make
wthin the waves dirExpected behavior
successful compilation
Desktop:
Additional context
gcc works
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.
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!
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
E.g.,
ifneq ($(MSYSTEM), MSYS)
ifneq ($(MSYSTEM), MINGW64)
ZIP = ....
endif
endif
See:
Makefile.fixed.txt
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:
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):
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.
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
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
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:
Expected behavior
The tone should be played correct frequency
Screenshots
N/A
Environment
NTS-1
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.
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.
С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)
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).
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.
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):
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!
In float_math.h, I have seen a few issues:
Describe the bug
The Arpeggiator does not stay on time/in sync to a MIDI clock signal
To Reproduce
Steps to reproduce the behavior:
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):
Additional context
Seems also to be a problem with bpm delays!
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.
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.
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:
(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).
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
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.
logue-sdk/platform/prologue/inc/osc_api.h
Line 559 in ab654af
Waves LUT already has a trailing entry, so x0 + 1 newer will be out of bounds.
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
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.
s_waves.params.bitcrush = clip01f(1.5f);
s_waves.state.flags |= Waves::k_flag_bitcrush;
Compile, load and select oscillator.
Send midi note on 50. Sound starts as expected.
Send midi note on 51. Pitch goes up one semitone as expected.
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.
Send midi note off 50. Sound stops as expected. Bitcrush is enabled (can be verified by setting EG to Open).
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:
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):
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..
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
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):
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'.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.