How to deal with "no edit buffer" synths

[markusschloesser]

From an adaption perspective, how to best deal with synths that either don't have an edit buffer (k5000s) or pretend to have one, but which doesn't work (andromeda)?
I might have missed something in the documentation 🤔

[Andy2No]

It's in the Adaptation Programming Guide, under "Where to start":

https://github.com/christofmuc/KnobKraft-orm/blob/master/adaptions/Adaptation%20Programming%20Guide.md

"Some synths do not have an edit buffer (the Kawai K3 for example), it is good practice to implement the edit buffer functions to use e.g. the highest program slot in order not to accidentally destroy the contant of program place 1. Remember to make a backup if possible at all of the device before you start sending any commmands to it."

[markusschloesser]

ah I did not see that, thanks!
Also the doc looks much better now (easier to read).
It might be worth listing information on synth capabilities somewhere here, in a table or so. So that when someone thinks about doing an adaptation there is some info on why someone else didn't pursue it. Especially for the "special" synths (Andromeda, mks80 etc).
What do you think about that?

[Andy2No]

Good idea. Links to download user contributed adaptations, in the table, would be good too, with their claimed capabilities listed.

I guess those could be incorporated into a new release, but it would mean a lot of work to check them all, and eventually updates might not really be needed - just providing the .py files, as is, would be useful, then people can hopefully fix any bugs they find in them and submit them again.

[christofmuc]

@markusschloesser Good idea with the table - this can actually be automatically generated, as I now have the new Adaptation tab with its textual context. But it would be easy to just dump a markdown table and incorporate it into the docs, I think.

I was also thinking of creating a decision "flowchart" that asks questions about the synth documentation and then guides you through which functions you need to implement.

@Andy2No I had started to make a KnobKraft-Orm-community repository here on github, but held back since I am not really sure how useful that is. Yes, the adaptations cannot be tested with every release, and we're still in a phase where there are bigger changes upcoming, I assume this will stabilize in a few months when also the bank management is finished.

But what I see is that people a) judge a Librarian by the list of synths supported, so if there are third party adapatations somewhere, they might never find them because they disregard it as irrelevant, and b) like to get eveything out of the box. Already the Python installation on Mac is a hurdle (I need to somehow automate that as I did for Windows), and then looking for py files elsewhere, putting them in the right directory etc. is also an effort.

In the long run, when the API is stable, I think the community repo is a good idea. Somebody started a thread on Gearslutz already just for community-created adaptations, but there is not much traffic there yet.

Also, when we get to see the adaptations, the advantage is to point our e.g. a missing fingerprint implementation of that a MIDI channel is hard coded somewhere which should ideally not be the case, so we could do some kind of quality assurance, even if the synth is not available.

[christofmuc]

Somebody just posted this in a facebook group, not sure if it is legit or what the status of that software is:
https://archive.org/details/emagicsounddiver3.0.5.4

[markusschloesser]

thanks, download it, but after a couple of reboots it wants to get re-authorized. I'm now using a patched version (normally would never do that, but special circumstances)

[christofmuc]

Closing as answered.