
- #Osculator tutorial install
- #Osculator tutorial software
- #Osculator tutorial code
- #Osculator tutorial free
Use this callback to perform any required initializations. Void OSC_INIT(uint32_t platform, uint32_t api): Called on instantiation of the oscillator. Your main implementation file should include userosc.h and implement the following functions. Here's an overview of the core API for custom oscillator/effects. You definitely want to use it if floating point math is easier than fixedpoint math for the algorithms you want to develop.

no dynamic memory allocations of any kind.īTW.
#Osculator tutorial software
So all regular software development practises apply, just be sure to use only static memory areas, i.e. In Korg's case you're only allowed to use part of the CPU cycles, but it should still be the same thing. Developing the thing was mostly like working on an old school computer: it's just a processors with low megahertz and you can get every singe CPU cycle out of it for your own purposes. I've designed one HW music making machine which used a 100 MHz STM32F4.
#Osculator tutorial free
Those should be very specific operations but everything that happens between those two points, should be irrelevant as long as the output data isn't corrupted by you (If someone spots an error in my thinking, please feel free to correct me.) Only thing that comes to mind is the data input and output to/from the oscillator algorithm. There should be no HW requirements to do so. It would be weird if you were forced to use the Korg's DSP libraries.
#Osculator tutorial code
So you should be free to use any DSP code you come up with. The microcontroller in question is just that: a standard microcontroller. So a simple shift or multiplication by a reciprocal operation should suffice and no actual division is necessary. I would hazard a guess that the processing block length stays a power of 2. Maybe I was just too stupid, but if there exists one, somebody could point to it, please. I haven't found any other thread on the net. So as I said, if people are running into common problems, this could be a nice exchange. The next step for me is to understand how much of the provided DSP libraries are really required in order to make use of this specific CPU in the best way or if one can more carelessly create his own code. If you know that the frame chunk is limited to powers of two and the ones in question (64, 32, 16) then it is a shift operation and takes much less time. So you have to make a division for a linear approximation to support any value for the frame size. There is no hint how big the data chunk actually is what they use and where this is defined.įor example: since you get only one pitch value per function call, you have to interpolate between the last value and the current in order to realize a nice pitch sweep. If this is right, according to the spec it has a FPU, and the following tips might be helpful.Ĭurrently I am running into the following problem: The SDK says the code should be optimized for 64 frames (samples), but it could also support 32 or 16 if the user wants to. These guysĬlaim that it is a ARM Cortex STM32F446xC/E Not sure which processor is actually used for the voices.

The voice chip also controls the analog part, so if the code is too slow it might also affect the behavior of envelopes. There is no tool to say whether the code violates timing rectrictions. In order to make the best out of it including oversampling one has to be aware of all the hardware limitations.
#Osculator tutorial install
In my case I was able to install MSYS2 on a Win10 machine, together with the required tools and was able to rebuild the Waves oscillator and test oscillators. So if there is some interest this could be a common thread to share and exchange information since Korg does not provide any technical support and leaves some stuff rather unclear or I overlooked some information. I read that some people might be interested or already active in programming their own user oscillators for the Prologue/Minilogue XD.
