Repository navigation
First steps towards support for Mustang/Rumble LT series amps - #28
tim-littlefair wants to merge 30 commits into
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. |
|
|
||
| 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.
| } | ||
|
|
||
| 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.
|
|
||
| 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 No newline at end of file |
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.
| | 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. |
|
It took a bit more than 2 weeks, but I've finally managed to get minimal proof of concept going for an framework which offers plug-like capabilities for LT series amps. I've published this here: https://github.com/tim-littlefair/feral-horse-amp-utils The new app is written in Java, so it's not capable of evolving into a direct contribution to plug, but I'd encourage users interested in support for the LT series to take a look at it. It's not a direct replacement for plug - presently it is more focussed on just two use cases which are:
With what I now know, I'd be happy to look at contributing back to plug in the future if @offa decides that he wants to add LT series support - my only concern is that I don't have access to any of the earlier Mustang models which were interoperable with Fender FUSE, so its difficult to see how the heavy changes required for LT support can be cut in without risking problems for users who are happy with plug as it stands for the older devices. If the plug community can establish a testing capability with access to both older devices and the newer LT series, I think this problem can be dealt with. Apologies to @offa for using this stale PR for this announcement, but I hope he's OK with me contacting the plug community via this channel as there is clearly an overlap with my new effort. |
|
Contributions always welcome! 👍 For the control and communications part there's an extensive test suite already (none for UI yet unfortunately). But it might be better to implement a new model (like the Mustang class, serialization etc.) in parallel and provide a base API around it. Getting a completely different protocol into the existing legacy Mustang one might be difficult. It even could be a good idea to refactor the existing API to better support new devices. |
2 participants
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).