-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Alesis Andromeda A6 #62
Comments
wow, will test tonight! Thanks! |
Great! That should simply be a timing issue - add a long timeout. That should fix the detection problem, i.e. add a function
would make it wait 600 ms for a reply before moving on to the next MIDI interface. Edit Buffer won't work, because it has none. Importing Sysex banks from Internet works, I could do that ;-) Importing Banks should work when it gets detected |
…led adaptations yet, waiting for feedback. (cherry picked from commit bf0a823)
…led adaptations yet, waiting for feedback.
didn't work with 600ms. Also tried 1000ms
|
@markusschloesser If the detection worked (green bar), but on the wrong MIDI port, it must be timing. Sometimes MIDI loops can also cause problems. What I'd need here is the MIDI log of the auto detection run, ideally only with the A6 enabled and a green bar (but wrong MIDI output) result. The sysex strings are ok, that's what we do. Though I don't get the difference between 1.) and 3) user preset 1. |
I disabled all other devices and ran auto config again. The Andromeda is "green" but the lower log says "No ... could be detected", the previously manually selected port stayed identical. However for the first time, when I do "import patches from synths" I get the "select bank" dialogue. But nothing is received, the A6 doesn't dump anything. When I do the "get patches from synth" the midi log shows When you do a bank request and knobkraft sends out [f0 00 00 0e 1d 01 00 00 f7] shouldn't that be F0 00 00 0E 1D 0A 00 F7? But where in your adaptation do you do bank requests? I can only see program requests |
|
@markusschloesser Well, it works, it's just slower than expected! Look at the log:
You can see from the timestamps that the Andromeda needs 1250 ms to answer the request, so even 1000 was not long enough. That's probably becaue the A6 needs to prepare the 2 Kilobyte+ download of a patch first. Put in 1500 and try again. The bank request is not yet implemented, but the Orm will just iterate over all 128 patches in a bank with single requests (you see the first message), so this is more a comfort/speed function we can do once the basic functions work. It might be that we are sending the request for the second patch ([f0 00 00 0e 1d 01 00 01 f7]) too quickly for the A6 to respond, as it is a rather slow synth, this is when the bank dump will come in, or I need to add more pauses between the requests, which is missing I think. |
|
Strange. I have to make you a version that ignores failed autodetection so that the manual override will allow you to try anyway - normally, if no green bar then it will not even try to request the bank. That's old behavior that needs to be removed when manually configuration is the only way. Do you have the MIDI log of the failed autodetection? Depending on how you setup the MIDI patch bays, I found that sometimes my MKS80 makes problems during auto-detection of other synhs since it echoes Sysex messages. Maybe turn it off for one try. Again, depends on your MIDI routing. |
no no, the light is actually green, but the log says "nothing found" |
Ok, getting slightly confused, but good news about the f0 7e 7f message. I finally checked and found the sysex spec in the net, so it's always best to go to the source itself. There, the Universal Device Inquiry (that's what it is) is even specified, that should make detection a breeze. Here is a version largely untested I hacked together after two beers that does use the f0 7e 7f for detection, and also has proper bank dump requests: Please provide the MIDI logs where possible, it makes it easier for me to understand what it is we send and what the reply is (if any) |
:-)
|
… the Alesis Andromeda A6. This should work soon... #62
…eSysex() implementation with all shifts. Also, fixed the isBankDumpFinished() method to only stop at 128 patches. (#62)
New version released with 1.10.6 - I am optimistic. |
I successfully retrieved 127 new patches from the User Bank!!! :-) Currently receiving the preset banks.
|
Awesome!
Yes, the software can do it, but currently the idea is to request a single patch always as the edit buffer, because there is no UI to select which patch you want to receive. With no edit buffer implemented, we need a different way. In Bank Management mode (v 2.0) that would be easy, because you would see the bank structure of the synth, and can just click "refresh" for a single patch. Without it, we could only make an import dialog that not only offers banks but also individual patches. A bit awkward, but might work for the moment.
Yes, this is straightforward now that the communication works. Fast solution - copy A6.py and change it into one synth called "A6 Mixes" and adjust the parameters. Better solution - I expose the LoadDataFileCapability and we start introducing multiple data types per synth.
Will take a look. Could be a bug in the name extraction, or the A6 uses a different character set (common in synths). I didn't see the character set specified, it normally is not (except for Roland!). Then it is trial and error. and some characters are not even possible with JUCE (the Virus has some arrow characters that refuse to come up on the PC).
Yes, the function numberFromDump() needs to be implemented ;-)
Amazingly complex device, but the settings make sense. I think a text string that gives users some guidance on how to setup the synth totally makes sense, and could be trivially implemented and displayed in the Adaptation tab. Not sure if users will find it there, but the UI already is a bit overloaded? Theses setup guides I had seen in LaserMammoth, and I think they do make sense especially for some of the older devices. |
I looked at the patch, and the 16th character of the name (at position 17 in the patch data) is an ordinal 36, which is an ASCII '$'. So I wouldn't know why the A6 doesn't display it. I don't hope we have an encoding / decoding problem hidden somewhere, does the patch sound as expected when you audition? |
I now imported around 350 patches from the internet, and for the first time since I got the andromeda, actually sent them to the a6 and played them for hours and categorized them. The duplication detection seemed to work fine and I enjoyed playing new sounds so much. So thank you! Your tool is fantastic :-) |
MS: a button "request singular patch" could be added and after that, first do the bank thing, than a specific program. Problem might be that you ideally should do a full bank request first?
MS: I think I'll wait for the latter
MS: that would be cool, also the new side panel you proposed, could/should show meta data. Meta data from import: date, which bank (or from which file/folder when sysex from computer), org prog number and name. But also user meta data: tags, comments, "used in song", etc?
MS: I have mine set to "here" and just select 127 before clicking something in knobkraft. And yes, the a6 is one of the most complex out there. As I still (and similar to every forum) have no clue how to multi-quote, as put it inline |
Freut mich! I know how you feel, these moments are why I wrote it in the first place!
Possible.
I'll think of something and let you know! |
Renaming a patch can be done by just clicking on the patch name button in the current patch display (at the top). |
I am sorry, that's way over my head. I don't know exactly what you do in the tests (and only very roughly everywhere else). |
Okay, I was hinting that the convertEditBuffer() would create somethign like
while isEditBuffer says:
So from the 0x1d, 0x02 I can see that isEditBufferDump() will be false for the output of convertToEditBuffer()... that could cause problems. What are you trying to accomplish? So we have now a way to request the edit buffer, which is good, and recognize it as an edit buffer, which is great. Is it possible to send the edit buffer as well? Because the current implementation turns it into a singleProgramBuffer, and then we could just say
So what is the new information you got over what we had before? |
So I understand that the information is that we can request the edit buffer, but cannot send it, but need to send a program dump? |
no, I am only trying to request the edit buffer (or as written further above, receive it manually). So
Maybe some communication / language thing :-) |
Ah, more that I am not 100% paying attention as I am in the middle of a big repair required for the multi-data-type downloads. That was a bit more work than expected. So... Understood. We cannot change the edit buffer before it reaches the database. But we can change it out the way out, so the edit buffer dump we got from the A6 never is sent back (that's probably the bug that was mentioned in the thread in 2013 or so). So... Your request edit buffer is correct But... nameFromDump() now needs to work for edit buffers as well, and convertToProgramDump() as well, because EditBuffers will be stored in the database and when you click on them they should be transformed into program Dumps. Actually, convertToEditBuffer() is more important because once it is there, it takes precedence over convertToProgramDump(), because we assume this is what you want. Let me quickly code this and paste it here. |
|
Thanks!
|
Phew. Did you add my version of the nameFromDump()? That should have worked for the edit buffer? Else, here is a version I just made, maybe try this with a fresh database: |
Okay, with my adaptation you database works - it was the nameFromDump() function, that also needs to work now for the edit buffer dumps (as we request them and store them immediately in the database) |
it works!! this is fantastic! Thank you.
btw you ok with me doing some advertising for kk on forums? |
@markusschloesser Not enough code yet ;-), the code duplication you are seeing comes from an unchanged createFingerprint() function, that does not yet match edit buffer dumps and program dumps. What I learned from this: Currently, the idea is to store everything we get from the synth as is in the database, and convert it fit for the purpose when sending out. Now, with the edit buffer that can be received but never must be send, we would need less code if we could convert a received edit buffer before storing it in the database, because then we'd only have one data type in the database. On the other hand, if there is a bug in the conversion you end up with crap in the database, which never is a good idea. The current design allows us to store what ever message we accept as valid answer (isEditBuffer()) into the database, and take care when sending to the synth that the right message is created. This is why we needed to adjust both the convertToEditBuffer() as well as the convertToProgramDump() functions. Though convertToProgramDump() is not used when convertToEditBuffer() is present, until we get the bank management feature, then we'll need it. In addition, all other functions must be aware that we could now get either an edit buffer dump or a program dump as a parameter, increasing the code required. Plus, in the convertToEditBuffer() function, we need to append a MIDI program change message if we want the synth to automatically switch to our "edit buffer program place". This is done automatically in case there is not edit buffer capabiltiy implemented, but now we have. Another solution would be to split the EditBufferCapability into a "ReceiveEditBufferCapability" and a "SendEditBufferCapability", but as this is a special case hopefully not happening with too many synths, I am not sure it's worth the effort. You will see more code coming in when we do the multi-data types :-) And please, feel free to advertise, that would help me a lot! |
Been enjoying the new functionality a lot in the last couple of days, so thank you again! 🌻
MS: does that also mean, that I cannot run the manual deduplication? I haven't dared to try it yet.
MS: what I don't understand is, that "stuff that's coming from the A6" is identical, no matter if program or edit buffer. Can't you just treat it identically? With the exception of "how to request it" of course. Or is that what you're proposing?
MS: but might make maintenance easier! And the sysex for that is different anyway
MS: will do! |
@markusschloesser You can run the Deduplicate/Reindex when the log tells you that there are patches that need reindexing. Did I already give you the fixed adaptation with the fingerprinting implemented? Maybe I forgot. |
you haven't :-) |
But I did the Kijimi ;-) Here is the new version, which should complain about needing reindexing: |
Kijimi indeed! :-) |
Patch comparison should open a window with a side-by-side diff of the the last two selected patches. Like send on to synth, send the second one to synth, press Patch comparison -> popup window with diff. If the synths have parameter info (only very few for now), you can even see the difference. Here is an example from the Oberheim Matrix 1000, which can unpack the paramters into clear text: |
Closing this as the 1.11.0 now contains the latest and greatest version of the A6, which apart from being a bit more complex than necessary seems to work and have all features the synth offers. |
found 2 issues (latest version):
|
Wouldn't that be expected? Did you change the preset and stored it in memory? E.g. my Rev2 will always send the program dump, not edit buffer, when I force it manually dump.
Ouch. |
|
Yeah, many synths do that. But in this case it seems to be either a bug or an oversight in the A6, as it does provide an edit buffer request, but somehow does return the program place. And it does not accept an edit buffer when sent (that's the original bug).
That's ok (and the reason for all the code added to the adaptation) - an edit buffer dump has code 0x02, 0x10 (marking the edit buffer), a program dump has code 0x00, [bank], [program], thus the program dump message needs one byte more. All the rest is identical. So in the database there'll be messages both with 2350 and 2349 bytes, and we convert on send/export.
Thanks! This time even the automatic crash upload into Sentry worked. That should be an easy fix. |
To clarify: requesting via sysex works fine and retrieves the actual edit buffer. |
Crash fixed with 1.11.1 |
When I'm done with the K5000 adaptation, I'm gonna try bank management for the andromeda |
Given that this device seems so tricky, I made an adaption as an exercise. The most ugly thing was its 8 bit storage format involving lots of bit shifts, the rest seems to be fairly normal.
@markusschloesser Do you want to give it a try?
AlesisAndromedaA6.zip
The text was updated successfully, but these errors were encountered: