OK, I think the release version now. Poly mode working with pitch range of +/- 2, 3, 12, 24 or 48.

The Presets have changed. As the text name of the plugin has changed the editor refused to send the patches to the oscillator (why they don't use the 4 char code for the unit is anyones guess), so I had to go in and hex edit them to change the unit name! Worth remembering if you are going to change the text name.

Edit: just changed to make lowest volume setting lower.

First FM64 build for mkII is available at dev page (http://dukesrg.ddns.net/logue-osc/)
No custom parameters and other bells& whistles for now - only the bare minimum to play around: velocity, FB offset and voice select from up to 4 banks.

upd: good news - the new runtime looks luke not hanging, tried 10x inner render loop for FM64, a lot noice from sound skipping but nothing hangs.

New versions of firmware and editor available: https://www.korg.com/us/support/download/product/0/933/

how much more involved are you folks finding it is coding the callback set other using just the basic calls we used in SDK 1.0?

i would hope starting up is not worse than installing the new SDK and toolset, and just doing some callback substitution. or are datatypes changed and so forth?

i have my plate 1/2 way cleared off and ready f*ck up some new stuff!!! :0)

They fixed the Note Off issue

But still Note Ons are not correct for "legato mode 1", you still only get one for the first note and then no more until all notes released :(

I have added an issue: https://github.com/korginc/logue-sdk/issues/111

Maybe you guys could add support there to get this fixed as they actually seem to be fixing things at the moment.

this is the first time i saw the KORG DIY CLUB code base https://korginc.github.io/logue-sdk/...korg_examples/

very cool to have some more elaborate examples.

Yeah I only knew there was an update because boochow updated some of the issue with a link to those.

Thanks for adding another voice to the issue on GitHub.

Concerning the sdk1->sdk2 question, I didn't really use SDK1, well I did a bit but not enough to remember it.

The interface for SDK2 is pretty simple though, for the oscillators look at: https://github.com/korginc/logue-sdk...my-osc/unit.cc

The most complicated bit is the parameter stuff, if you look at https://github.com/korginc/logue-sdk...y-osc/header.c and the parameter stuff in https://github.com/korginc/logue-sdk...ummy-osc/osc.h though it will make sense.

Also version 1.2 firmware apparently fixes the parameter bugs that were there, so I guess it should all work now.

Checked fw 1.2 - looks like FM64 is restoring the last state on boot correctly. Didn't have an issue with 1.1 though

A little bit on that Legato mode pain - more on why is it like that and how to tackle it, rather than how it should normally work (I already told numerous time KORG's MIDI implemintation is crap, right?)
- NTS-1 was released as a monophoic synth of a single oscillator. Рaving prologue dev kit as an initial prototype, so no one at that moment ьщые thought about the any polyphonic mode.
- NTS-1 fw 1.2 introduced the Legato mode global parameter.
Legato=On was similar to the original mode, close to how prologue/mxd works - NoteOn/NoteOff calbacks is not a MIDI event calbacks, those are at least behind the voice allocation mechanism of the polyphonic logues.
The new Legato=Off does not retrigger the internal EG and allows multiple NoteOn callbacks with no NoteOff in between, to imlement some kind of polyphonic. Unfortunately NoteOffs was not adjusted and it was called only once on the last note released. There is still an old feature request opened issue: https://github.com/korginc/logue-sdk/issues/26.

- NTS-1 mkii pre fw 1.2 was behaving the same way as NTS-1 fw 1.2
- NTS-1 mkii fw 1.2 now fixes the issue with the lack of the NoteOff calbacks in Legato=Off mode, though it does the same for the Legato=On mode. It should not be like that, but the workaround is just as simple as responding to the NoteOff for the NoteOn that has been registered before and ignore any unaligned NoteOffs. That will work for both legato modes, though in Legato=On you will never get two NoteOn calbacks with no NoteOff in between.

Once again, don't treat calbacks as direct MIDI event because they don't, even if SDK2.0 made it looks more like. If Legato=On NoteOff count will be aligned with the NoteOns AND the same will be implemented for NTS-1 fw, that will be fair ennough, as that is the way as old big logues work. While the Legato=Off mode is for pure-digital synths only. Implementing mkii that way still give changes for the new SDK2.0 hybrid logues.

I finally read thru the mk2 MIDI implementation, and found a discrepancy: most of the controllers have MSB/LSB entries, including unit parameter NRPNs that clearly states full 14-bit range. Though the program dump table states 10-bit range (while stil having a pair of 7-bit entries).

The MIDI to unit parameter values conversion in both directions also are not stated I.e. it is not clear:
- How the values exceeding 14-bit range a treated?
- How the negative parameter values are treated?
- Does values with the span not exceeding 7-bit are controlled with MSB or LSB part?
- Does center value affect MIDI value ...

It is important as with the enhanced parameter range control over MIDI, more weird things can be done! As soon as mk2 have no encoders. but a potantiometer, evern 14-bit parameter values will be still controllable from the panel, while having more preciese control over MIDI.

Support reslonded - there is a 14-bit<=>10-bit rescaling for NRPN values :triplefacepalm:
Will have some time soon to tesh all of this.

did they respond directly to you? i don't see an update on github?

this online repository stuff is weird.

https://www.sinevibes.com/korgflare/

yes. better posted on the Prologue/XD/NTS threads please.

Confirmed :(
Just noticed that even numeric values are not displayed for A/B even with typek_unit_param_type_none

BUSTED

- Both OSC A/B CCs and param NRPNs sends over MIDI full 14-bit values for the full potentiometer stroke
- Program data scales OSC value to 10-bit
- Program data keeps 14-bit data for Param values

UPD:
- Sendinhg MIDI data seems to be performs the reverse conversion properly
- Params with range -32768, 32767 seems to have issue with NRPN calculation, as LSB is garbled. Neither OSC, nor 0, 32767, nor -16384, 16383 are affected (all in all it does not make much sense to have parameter span over 14-bit range, as it won't be fully accessible neither over MIDI, nor with the potentiometer input)
- OSC A/B prog values is just like shifted value of the correcponding 14-bit CC pairs got from the potentiometer position. No negative minimum or center points respected
- Param prog value is the real 16-bit signed parameter value, according to the header descriptor range.

What a freaking mess :(

So if one want to control the user unit in the uniform way over MIDI and with programs, all the parameter ranges must be set to 0-16383 keeping in mind, OSC A/B will not store lower 4 bits in the Prog data. Such way 14-bit CCs values are easy to map 1:1 wiht the parameter values inside of the unit.

P.S. droppet a couple of emails to the dev's. Will wait for a couple of weeks and add an issue at github.

Can you show me? Thanks!

sure! these are the relevant threads:

Korg Prologue

Korg Minilogue xd Module

Korg NTS-1 Nu:Tekt DIY Synthesizer

this is more of a developer thread. thanks!

welp, that didn't happen. maybe this month...

Strange thing: if sprintf is used in mkII unit, Kontrol Editor shows a "Warning - ELF error: Resolve Symbol", but unit still works. Not the best idea as it steals over 6KB of space, but never the less, looks weird.

yeah but, does the sprintf still work? lol. j/k

Now I’m not sure as worked on custom params so might miss header changes ))

Oleg, Question for you: how many lines did you have to change in your C code to support major SDK callback routines to port it to SDK2? i have no machine dependencies in my code, so it should only be callback changes. i use the MIDI note info a lot though for key tracking.

trying to gauge the amount of effort i need to push this through the knot hole and get started. i'm not motivated unless there's a synth at the end... or it's not a lot of work lol.

i have a lot of work on SDK1 to finish, it's just less interesting if there's something new to apply it to instead.

For mkII it was just as easy as creating a hader with params based on the original manifest and copy handler contents to new ones and change OSC_CYCLE params to oscillator runtime context for the pitch. The rest worked as is, including ARM ASM parts.
Drumolue is a different story.

P.S. and yes sprintf works with mkII

well, sir. you may well have encouraged me to try. we shall see! thank you!

I'll have to sprintf me some time to do it now. :0)

The MIDI implementation on mkII suck.
Even if the unit parameter is defined with the 0-16383 range, the value received by the SetParameter handler might be different from both received and trasmitted CC/NRPN values. Something that can't be explained even with <10-bit resolution for the potentiometers, as even values receied from CC/NRPN differs and sometimes even MSB is affected.
I was going to implement precise FM64 parameter control over MIDI, but this bug is a no-go.

this "ship it broken, and fix it in the field someday... maybe." stuff is getting ridiculous. it would be ok, if there was a quick turn around at korg... but even the worst stuff in SDK1 never got a 2nd thought with these guys.

Made a batch. Sent to Param 1 NRPN 16350...16383 and made program dumps, here is what was stored in the dump for the param:
16335
16335
16351
16351
16351
16351
16351
16351
16351
16351
16351
16351
16351
16351
16351
16351
16351
16351
16383
16239
16383
16239
16383
16239
16383
16239
16383
16239
16383
16239
16383
16239
16383
16239

are you using decimal here duke?

Let it burn...
https://github.com/korginc/logue-sdk/issues/116