First steps towards support for Mustang/Rumble LT series amps #28
Conversation
Add Clang 17 (#278)
…ps and effects is disabled for all models
… is 'Input/Output Error'
... both with and without the --enable-v3usb-enabled flag
…ang USB device with vendor id 1ed8
…GT/GTX and Mustang Micro
|
I can see the failing checks, will try to work through these over the next week or so. |
src/com/Mustang.cpp
Outdated
|
|
||
| case DeviceModel::Category::MustangV3_USB: | ||
| { | ||
| const auto name = decodeNameFromData(fromRawData<NamePayload>(data[0])); |
There was a problem hiding this comment.
It is now clear that the package reflected in data[0] does not contain anything useful for building a name.
Hopefully the name is available somewhere in the JSON we expect to be able to extract in the next iteration of this change.
| @@ -681,4 +680,26 @@ namespace plug::com | |||
| header1.setDSP(DSP::none); | |||
| return {{Packet<EmptyPayload>{header0, EmptyPayload{}}, Packet<EmptyPayload>{header1, EmptyPayload{}}}}; | |||
| } | |||
|
|
|||
| std::array<Packet<EmptyPayload>, 3> serializeInitCommand_V3_USB() | |||
| { | |||
There was a problem hiding this comment.
Packet data in this function is copied from the attached JSON capture file, at lines 4631, 4867, 5103.
As yet I have no understanding of the meaning of these packets.
| @@ -120,11 +123,18 @@ namespace plug::com::usb | |||
| std::vector<std::uint8_t> buffer(dataSize); | |||
| int transfered{0}; | |||
|
|
|||
| if (const auto result = libusb_interrupt_transfer(handle_.get(), endpoint, buffer.data(), dataSize, &transfered, usbTimeout.count()); (result != LIBUSB_SUCCESS) && (result != LIBUSB_ERROR_TIMEOUT)) | |||
| const auto result = libusb_interrupt_transfer(handle_.get(), endpoint, buffer.data(), dataSize, &transfered, usbTimeout.count()); | |||
| #ifndef NDEBUG | |||
There was a problem hiding this comment.
I added this output so I could tell when the libusb call was succeeding and when it was timing out. It may have served its purpose now if @offa wants to remove it.
| # .kdev4 which contains a single file .kdev4/offa-plug.kdev4. | ||
| # As this file contains the full path my local build directory | ||
| # I'm guessing that it should not be committed to git. | ||
| .kdev4 |
There was a problem hiding this comment.
Feel free to submit this line directly, extending .gitignore might help others too.
There was a problem hiding this comment.
I'm not sure what the invitation is here - do you want me to create a PR with the file ./offa-plug.kdev4 in it, and whatever else is required so that the kdevelop project works out of the box on a fresh clone?
I can't see the point of adding a line for the .kdev4 subdirectory to .gitignore unless it is alongside the project file. I added this because the files the in .kdev4 subdirectory contained information the full path to the sandbox directory on my computer, so I'm guessing that these files are not particularly helpful to others (and might be harmful).
Experimentation shows that adding the offa-plug.kdev4 file only doesn't seem to give a clean startup so I'll look into what is required for a path-neutral project and I'm happy to do a PR containing this if it is what is preferred.
There was a problem hiding this comment.
I'm not sure what the invitation is here - do you want me to create a PR with the file ./offa-plug.kdev4 in it, and whatever else is required so that the kdevelop project works out of the box on a fresh clone?
No, just add project files to the .gitignore so others that might use the IDE don't commit their local files accidentally.
| @@ -27,3 +27,4 @@ | |||
| | Mustang LT 40S | 1ed8 | 0046 | | | |||
| | Rumble LT 25 | 1ed8 | 0038 | | | |||
| | Mustang GT 40 | 1ed8 | 0032 | | | |||
| | Mustang Micro | 1ed8 | 0043 | | | |||
There was a problem hiding this comment.
Nice, could you submit this in a separate PR?
There was a problem hiding this comment.
Will do shortly. Unfortunately, experimentation to date shows that the Mustang Micro is completely unresponsive to the commands which are getting responses on the LT40S, so this may only be useful to put a disclaimer to say this device is not supportable. It is not surprising, as the 'Micro is not interoperable with the Desktop Fender Tone app either.
There was a problem hiding this comment.
PR for this will come in in a couple of minutes.
|
It would be great to reverse the protocol used and finally integrate it into plug. Do I understand this correctly and those devices uses JSON for data transmission? The project is quite tailored to Mustang-like devices, but maybe we can get support for other devices too. Still quite some work on both sides, but great to see the first steps. |
I've done some more work in a new branch. Some way from being ready to do a PR yet, but with the following commit: Note that the attached file has been parsed and re-serialized with linefeeds and indentation - the actual JSON packaged in the protocol is single line tightly compacted and hard to read. |
|
It's now clear to me that this PR contains far to much change in one hit for me to expect @offa to accept it, so I am going to withdraw the request and close it. Hopefully within a week or two I'll be able to put in the time to bring in a PR with some leel of useful support for the LT40S at least with less change to the main app. |
|
I'll delete the branch on my fork once I've made something more useful visible, but for now I'll leave it there for reference. |
Last year I ran some FenderTone sessions in a VM on my laptop with my Mustang LT40S amp, and captured the USB traffic.
I've finally got round to bringing my forked copy of offa-plug up to date and attempting to apply knowledge from the captures to adding support for the LT40S (and presumably other Mustang/Rumble amps in that series) to it.
This is an early pull request so that anyone who is working with similar goals can see the progress I've made so far - it doesn't achieve any meaningful integration with the offa-plug GUI yet, but running a debug build it is possible to see on the console that I've managed to replicate the first three frames sent to the amp by Fender Tone, and I'm receiving similar looking responses to all three.
The first two frames get single packet responses which are just a echo back of the command sent out with a 0x00 byte prepended and the last byte (always 0x00) dropped. The response to the third packet is more interesting, it consists of 24 frames, and I suspect from earlier hacking on the FenderTone capture data that it will contain a large single-line JSON text object when I've worked out the right amount of header to strip from each response packet.
Please find attached a JSON export of capture file, and a log of the debug output from a debug build of my baseline for this PR, when run with the command line option --enable-v3usb-devices. The first command I have replicated occurs at line 4631 in the capture. Searching for the string '"usbhid.data": "35' in the capture will find all 127 commands sent, the response packets all start with '"usbhid.data": "00' and there are many more of them.
It's up to @offa whether to integrate pick this up soon, or watch and see if I get any further with it before bringing it in, or whether just to say its not of interest and leave it out. I'm getting it out there now as I think this might be interesting to some other people looking at offa-plug, particularly some of the people who commented on #7. If @offa does want to integrate now or soon he is welcome to keep or discard some of the extra files in this PR which do things like open up the udev rules for developer convenience without requiring plugdev group membership and kdevelop project files, and also to get rid of my horrible wordy comments about different amps in the ConnectionFactory.cpp file.
I'll carry on, see whether I get any further, but no promises...
fendertone-synced.json
output-lt40s-7e25b0e.txt
(If anyone is interested in the raw pcapng capture file, or captures from other ooperations like changing the selected preset please message me directly, or if @offa wants to host them in his tree I'm happy to contribute them).