Interest in Yamaha Reface CP adaptation?

[milnak]

I hacked together one for the Reface CP, which is a bit weird as the CP has 1 bank, 1 program (essentially just an "edit buffer"), and no program names.

One issue I'd like to fix is that I'm using a hash to provide a generated name, but it would be nice if I could use the filename from the saved sysex (when imported). Any way to do that?

Let me know if you're interested in a PR and I'll send one.

[Andy2No]

A function for a Python adaptation to retrieve the sysex filename would be good, yes.

Have you done it in Python? If so, you could just attach the file to a comment and anyone who wants to try it could add it manually. Options -> Set User Adaptation Dir... opens a File Open dialog to that folder, but it's usually in C:\Users{YOU}\KnobKraft-Adaptations, in Windows.

You may need to put it in a .zip file, to be allowed to attach it.

[milnak]

Here's my hack -- it seems to work.

[christofmuc]

Wow, awesome! I have to dig into this a bit more. I still have a CP lying around somewhere myself, so I'll definitely have to give it a try.

About the name - the import dialog displays a bulk rename dialog when importing from more than one file. You can get the same functionality by using the Edit.. Bulk rename patches... function in the menu. There is a generate from filename button there. Is a bit indirect, but does what you want, and it even works with a single patch.

[milnak]

"There is a generate from filename button there."

I tried that, but I get "0 files renamed" after choosing it. Is it because my adaptation overrides nameFromDump()?

Edit: That was the issue. I've removed the implementation of that method for now and updated the gist.

[christofmuc]

Interesting. Maybe it is a combination of nameFromDump() and a missing implementation of renamePatch()? I would assume you need both, but would need to check on the concrete logic implemented.

[christofmuc]

Confirmed this was a bug - when nameFromDump() was implemented, but renamePatch() was not, adaptations would not accept the rename command because they would try to change the stored patch data and fail, and not update the name field which is only stored in the database. Not sure how many adaptations were affected, but that was certainly not ideal. Changed it so you would now change the name in the database.

This can now lead to the interesting situation that a patch has two names - one stored in the patch and retrieved by nameFromDump(), and the one in the database. If you now implement renamePatch() later, things will get interesting.