DescriptionOn 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. :
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..
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
Panel1.01
Voice1.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..