Mustang GT 40: No device found #25
Comments
|
The device PID isn't supported and not listed here. The main question is though: Does it use the Mustang protocol, or something different like the LT series?
Nice, thank you! 😃 |
|
Ha! I didn't see the list... Shame on me. Regarding the similarity with the LT, I don't know, both products look surprisingly similar from an external point of view. I've only used the Fender Tone android App to access it via Bluetooth. I now wonder if the GT provides anything more than an audio interface over USB... I will check that. |
|
You can do a simple test:
|
|
I added diff --git a/src/com/ConnectionFactory.cpp b/src/com/ConnectionFactory.cpp
index 6c52c31..71b6b2d 100644
--- a/src/com/ConnectionFactory.cpp
+++ b/src/com/ConnectionFactory.cpp
@@ -41,6 +41,7 @@ namespace plug::com
inline constexpr std::uint16_t mustangFloor{0x0012};
inline constexpr std::uint16_t mustangI_II_v2{0x0014};
inline constexpr std::uint16_t mustangIII_IV_V_v2{0x0016};
+ inline constexpr std::uint16_t mustangGT_40{0x0032};
}
inline constexpr std::initializer_list<std::uint16_t> pids{
@@ -50,7 +51,8 @@ namespace plug::com
usbPID::mustangMini,
usbPID::mustangFloor,
usbPID::mustangI_II_v2,
- usbPID::mustangIII_IV_V_v2};
+ usbPID::mustangIII_IV_V_v2,
+ usbPID::mustangGT_40};
DeviceModel getModel(std::uint16_t pid)
{
@@ -70,6 +72,8 @@ namespace plug::com
return DeviceModel{"Mustang I/II", DeviceModel::Category::MustangV2, 24};
case usbPID::mustangIII_IV_V_v2:
return DeviceModel{"Mustang III/IV/V", DeviceModel::Category::MustangV2, 100};
+ case usbPID::mustangGT_40:
+ return DeviceModel{"Mustang GT40", DeviceModel::Category::MustangV2, 100};
default:
throw CommunicationException{"Unknown device pid: " + std::to_string(pid)};
}Last changed line: total guess! I also added the productId in a udev file rule with: Running the compiled version: $ LIBUSB_DEBUG=4 ./src/plug
[timestamp] [threadID] facility level [function call] <message>
--------------------------------------------------------------------------------
[ 0.000019] [000fd316] libusb: debug [libusb_init_context] created default context
[ 0.000024] [000fd316] libusb: debug [libusb_init_context] libusb v1.0.27.11882
[ 0.000031] [000fd316] libusb: debug [usbi_add_event_source] add fd 16 events 1
[ 0.000037] [000fd316] libusb: debug [usbi_io_init] using timer for timeouts
[ 0.000040] [000fd316] libusb: debug [usbi_add_event_source] add fd 17 events 1
[ 0.000047] [000fd316] libusb: debug [get_kernel_version] reported kernel version is 6.6.16-2-MANJARO
[ 0.000065] [000fd316] libusb: debug [op_init] found usbfs at /dev/bus/usb
[ 0.000069] [000fd316] libusb: debug [op_init] max iso packet length is (likely) 98304 bytes
[ 0.000074] [000fd316] libusb: debug [op_init] sysfs is available
[ 0.000250] [000fd31d] libusb: debug [linux_udev_event_thread_main] udev event thread entering
[ 0.005661] [000fd316] libusb: debug [linux_get_device_address] getting address for device: usb1 detached: 0
[ 0.005669] [000fd316] libusb: debug [linux_get_device_address] scan usb1
[ 0.005693] [000fd316] libusb: debug [linux_get_device_address] bus=1 dev=1
[ 0.005697] [000fd316] libusb: debug [linux_enumerate_device] busnum 1 devaddr 1 session_id 257
[ 0.005713] [000fd316] libusb: debug [linux_enumerate_device] allocating new device for 1/1 (session 257)
[ 0.005795] [000fd316] libusb: debug [linux_get_device_address] getting address for device: 1-2 detached: 0
[ 0.005799] [000fd316] libusb: debug [linux_get_device_address] scan 1-2
[ 0.005821] [000fd316] libusb: debug [linux_get_device_address] bus=1 dev=16
[ 0.005823] [000fd316] libusb: debug [linux_enumerate_device] busnum 1 devaddr 16 session_id 272
[ 0.005827] [000fd316] libusb: debug [linux_enumerate_device] allocating new device for 1/16 (session 272)
[ 0.005849] [000fd316] libusb: debug [linux_get_parent_info] dev 0x55a5a14a4d50 (1-2) has parent 0x55a5a14eefa0 (usb1) port 2
[ 0.005922] [000fd316] libusb: debug [linux_get_device_address] getting address for device: 1-3 detached: 0
[ 0.005929] [000fd316] libusb: debug [linux_get_device_address] scan 1-3
[ 0.005955] [000fd316] libusb: debug [linux_get_device_address] bus=1 dev=2
[ 0.005959] [000fd316] libusb: debug [linux_enumerate_device] busnum 1 devaddr 2 session_id 258
[ 0.005962] [000fd316] libusb: debug [linux_enumerate_device] allocating new device for 1/2 (session 258)
[ 0.005987] [000fd316] libusb: debug [linux_get_parent_info] dev 0x55a5a14ef0c0 (1-3) has parent 0x55a5a14eefa0 (usb1) port 3
[ 0.006052] [000fd316] libusb: debug [linux_get_device_address] getting address for device: 1-4 detached: 0
[ 0.006056] [000fd316] libusb: debug [linux_get_device_address] scan 1-4
[ 0.006078] [000fd316] libusb: debug [linux_get_device_address] bus=1 dev=3
[ 0.006080] [000fd316] libusb: debug [linux_enumerate_device] busnum 1 devaddr 3 session_id 259
[ 0.006083] [000fd316] libusb: debug [linux_enumerate_device] allocating new device for 1/3 (session 259)
[ 0.006104] [000fd316] libusb: debug [linux_get_parent_info] dev 0x55a5a14a4a50 (1-4) has parent 0x55a5a14eefa0 (usb1) port 4
[ 0.006162] [000fd316] libusb: debug [linux_get_device_address] getting address for device: 1-4.1 detached: 0
[ 0.006165] [000fd316] libusb: debug [linux_get_device_address] scan 1-4.1
[ 0.006188] [000fd316] libusb: debug [linux_get_device_address] bus=1 dev=4
[ 0.006192] [000fd316] libusb: debug [linux_enumerate_device] busnum 1 devaddr 4 session_id 260
[ 0.006195] [000fd316] libusb: debug [linux_enumerate_device] allocating new device for 1/4 (session 260)
[ 0.006218] [000fd316] libusb: debug [linux_get_parent_info] dev 0x55a5a14a5b30 (1-4.1) has parent 0x55a5a14a4a50 (1-4) port 1
[ 0.006276] [000fd316] libusb: debug [linux_get_device_address] getting address for device: 1-4.4 detached: 0
[ 0.006278] [000fd316] libusb: debug [linux_get_device_address] scan 1-4.4
[ 0.006299] [000fd316] libusb: debug [linux_get_device_address] bus=1 dev=6
[ 0.006301] [000fd316] libusb: debug [linux_enumerate_device] busnum 1 devaddr 6 session_id 262
[ 0.006304] [000fd316] libusb: debug [linux_enumerate_device] allocating new device for 1/6 (session 262)
[ 0.006330] [000fd316] libusb: debug [linux_get_parent_info] dev 0x55a5a14a5a10 (1-4.4) has parent 0x55a5a14a4a50 (1-4) port 4
[ 0.006382] [000fd316] libusb: debug [linux_get_device_address] getting address for device: usb2 detached: 0
[ 0.006385] [000fd316] libusb: debug [linux_get_device_address] scan usb2
[ 0.006406] [000fd316] libusb: debug [linux_get_device_address] bus=2 dev=1
[ 0.006409] [000fd316] libusb: debug [linux_enumerate_device] busnum 2 devaddr 1 session_id 513
[ 0.006412] [000fd316] libusb: debug [linux_enumerate_device] allocating new device for 2/1 (session 513)
[ 0.006482] [000fd316] libusb: debug [linux_get_device_address] getting address for device: usb3 detached: 0
[ 0.006486] [000fd316] libusb: debug [linux_get_device_address] scan usb3
[ 0.006507] [000fd316] libusb: debug [linux_get_device_address] bus=3 dev=1
[ 0.006510] [000fd316] libusb: debug [linux_enumerate_device] busnum 3 devaddr 1 session_id 769
[ 0.006513] [000fd316] libusb: debug [linux_enumerate_device] allocating new device for 3/1 (session 769)
[ 0.006581] [000fd316] libusb: debug [linux_get_device_address] getting address for device: 3-2 detached: 0
[ 0.006585] [000fd316] libusb: debug [linux_get_device_address] scan 3-2
[ 0.006606] [000fd316] libusb: debug [linux_get_device_address] bus=3 dev=2
[ 0.006609] [000fd316] libusb: debug [linux_enumerate_device] busnum 3 devaddr 2 session_id 770
[ 0.006611] [000fd316] libusb: debug [linux_enumerate_device] allocating new device for 3/2 (session 770)
[ 0.006635] [000fd316] libusb: debug [linux_get_parent_info] dev 0x55a5a14a4bf0 (3-2) has parent 0x55a5a14a6340 (usb3) port 2
[ 0.006688] [000fd316] libusb: debug [linux_get_device_address] getting address for device: usb4 detached: 0
[ 0.006690] [000fd316] libusb: debug [linux_get_device_address] scan usb4
[ 0.006711] [000fd316] libusb: debug [linux_get_device_address] bus=4 dev=1
[ 0.006715] [000fd316] libusb: debug [linux_enumerate_device] busnum 4 devaddr 1 session_id 1025
[ 0.006717] [000fd316] libusb: debug [linux_enumerate_device] allocating new device for 4/1 (session 1025)
[ 0.078059] [000fd316] libusb: debug [libusb_get_device_list]
[ 0.078087] [000fd316] libusb: debug [libusb_get_device_descriptor]
[ 0.078090] [000fd316] libusb: debug [libusb_get_device_descriptor]
[ 0.078093] [000fd316] libusb: debug [libusb_get_device_descriptor]
[ 0.078097] [000fd316] libusb: debug [libusb_get_device_descriptor]
[ 0.078100] [000fd316] libusb: debug [libusb_get_device_descriptor]
[ 0.078102] [000fd316] libusb: debug [libusb_get_device_descriptor]
[ 0.078107] [000fd316] libusb: debug [libusb_get_device_descriptor]
[ 0.078110] [000fd316] libusb: debug [libusb_get_device_descriptor]
[ 0.078114] [000fd316] libusb: debug [libusb_get_device_descriptor]
[ 0.078116] [000fd316] libusb: debug [libusb_get_device_descriptor]
[ 0.078124] [000fd316] libusb: debug [libusb_open] open 1.16
[ 0.078151] [000fd316] libusb: debug [usbi_add_event_source] add fd 24 events 4
[ 0.078156] [000fd316] libusb: debug [libusb_claim_interface] interface 0
[ 0.078459] [000fd316] libusb: debug [libusb_submit_transfer] transfer 0x55a5a1a813f0
[ 0.078469] [000fd316] libusb: debug [add_to_flying_list] arm timer for timeout in 1000ms (first in line)
[ 0.078495] [000fd316] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.078498] [000fd316] libusb: debug [handle_events] event sources modified, reallocating event data
[ 0.078503] [000fd316] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 0.078837] [000fd316] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 0.078847] [000fd316] libusb: debug [reap_for_handle] urb type=2 status=0 transferred=4
[ 0.078851] [000fd316] libusb: debug [handle_control_completion] handling completion status 0
[ 0.078855] [000fd316] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 0.078860] [000fd316] libusb: debug [usbi_handle_transfer_completion] transfer 0x55a5a1a813f0 has callback 0x7fd1d1679c90
[ 0.078863] [000fd316] libusb: debug [sync_transfer_cb] actual_length=4
[ 0.078869] [000fd316] libusb: debug [libusb_free_transfer] transfer 0x55a5a1a813f0
[ 0.078873] [000fd316] libusb: debug [libusb_submit_transfer] transfer 0x55a5a1a814e0
[ 0.078877] [000fd316] libusb: debug [add_to_flying_list] arm timer for timeout in 1000ms (first in line)
[ 0.078887] [000fd316] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.078890] [000fd316] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 0.079202] [000fd316] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 0.079211] [000fd316] libusb: debug [reap_for_handle] urb type=2 status=0 transferred=56
[ 0.079214] [000fd316] libusb: debug [handle_control_completion] handling completion status 0
[ 0.079217] [000fd316] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 0.079221] [000fd316] libusb: debug [usbi_handle_transfer_completion] transfer 0x55a5a1a814e0 has callback 0x7fd1d1679c90
[ 0.079225] [000fd316] libusb: debug [sync_transfer_cb] actual_length=56
[ 0.079228] [000fd316] libusb: debug [libusb_free_transfer] transfer 0x55a5a1a814e0
[ 0.079254] [000fd316] libusb: debug [libusb_submit_transfer] transfer 0x55a5a1a81720
[ 0.079258] [000fd316] libusb: debug [add_to_flying_list] arm timer for timeout in 500ms (first in line)
[ 0.079263] [000fd316] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 64
[ 0.079268] [000fd316] libusb: error [submit_bulk_transfer] submiturb failed, errno=2
[ 0.079272] [000fd316] libusb: debug [submit_bulk_transfer] first URB failed, easy peasy
[ 0.079275] [000fd316] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 0.079279] [000fd316] libusb: debug [libusb_free_transfer] transfer 0x55a5a1a81720
ERROR: Input/Output Error
`` |
|
That's a different error than expected. Do you get this error each time? |
|
No. If I start the application, I get the IO Error. |
|
This might be an indication of a different protocol. Usually it should fail with some kind of 'invalid id', not on USB writing. |
|
That is sad news. |
|
Just to cement the disappointment a bit further, I'm presently working on support for the LT40S but I also have a Mustang Micro, and based on my experience with that I dont think there is going to be much hope of getting the GT working over USB. The original mustang-plug by piorekf was based on reverse engineering the USB protocol of amplifiers released up until around 2015. Fender released an official control application for this on Windows and macOS called 'Fender Plug'. I believe that the Fender Mustang hardware released from 2015 on were accompanied by iOS/Android mobile applications which controlled the amp wirelessly (probably over Bluetooth) and didn't have a USB control app. The current version of the mobile control app is called Fender TONE v4 but I don't have a device this works with. The LT series of Mustangs go back to USB control, but are driven by a desktop app, also called Fender Tone (I think the version number might be 1.5... but I would need to run it up). The work under way at the moment is focussing on reverse engineering the LT USB protocol. The Mustang Micro has both Bluetooth and USB capability, but no control app - the Bluetooth can only be used to capture an input audio stream which the amp will play through its speaker as accompaniment to the guitar input. The USB exposes a generic audio device, so the sound can be captured on Linux, but the USB descriptors don't declare proprietary control endpoint (the LT does). I'm guessing the GT 40's USB service offering will be similar - generic audio so players can capture on a DAW, but no control capability over USB. I'm guessing that for both the Mustang Micro and the GT series (and newer GTX), Fender have no intention of supporting USB control, and have built firmware which doesn't accept commands of any protocol over USB. It is possible that GT/GTX series could be integrated into offa-plug if someone with the right skills was able to snoop the Bluetooth wireless traffic and add a Bluetooth option to the connecton factory, but this is an order of magnitude more work than adding support for a variant protocol under the existing USB connection management. NB if anyone wants to take this on, they might want to look at the new Mustang Micro Plus |
|
@tim-littlefair I got a Mustang Micro Plus for Christmas and have some free time over the holidays so I have started to explore it a little. I have pushed rough notes etc to https://github.com/spod/fmmp Briefly, I don't think it will work with plug without a large set of code changes. The app appears to be based on Presonus technology, like the LT amp series it uses protocol buffers. Connected via usb it appears to be just an audio interface (although when firmware updates become available they will be delivered via USB). The physical device appears to be manufactured by GP Electronics, a subsidiary of the holding company which owns KEF, Celestion and others - they also do design work and their name crops up in Internet search for other smart Fender amps. |
|
@spod thanks very much for your comments and the pointer to your work. I've been working on this problem quietly for a while, not making much progress, but this has spurred me to come back to the work, and I feel I've made some progress today. @offa apologies for not noticing your confused icon on my October 18 comment, which is quite justified, as I used your project's ticket to push out a rambling discussion of possibilities which are well outside your maintenance project's well-defined scope. To try to clear this up, like @spod, I've come to the conclusion that the protocol and preset data model differences between the original amps supported by the plug codebase and the USB-controlled Mustang LT25/LT50/LT40S (+Rumble LT25) are too major for it to be sensible to try to extend plug to cover these properly at the present time. This goes doubly so for the Mustang GT/GTX, Mustang Micro Plus devices which are controlled over Bluetooth instead of USB. I recommend that @offa should close this issue as WONT_FIX. I came to this conclusion some time ago, I've been hoping to be able to offer a public repo containing at least a minimal proof of concept to which owners of LT-series devices could be referred, I don't have this in a state where I'm ready to expose publicly yet, but I have created an issue on my public fork of plug which anyone who is interested can comment on or follow. My issue is here: tim-littlefair#2. I encourage anyone who wants to continue discussion of this to migrate to the issue ticket above, unless @offa responds to positively encourage further discussion of LT/GT/GTX/MMP support here. |
At least without a proper refactoring at the moment. But once the protocol is understood, maybe we can try figure out how to support different protocols and generations.
Feel free to use this ticket for discussion and keep interested people connected. 👍 |
I'm trying to make plug work with my Mustang GT 40.
I took to ownership of the AUR package for this plugin as the previous versions did not compile anymore.
I'm using version 1.4.5.
Is there any successful attempt by someone fro this amp ?
Seems that the amp is seen by the system. I can use it as an audio device.
I don't see anything useful here.
Is there something I can try to make this work ?
The text was updated successfully, but these errors were encountered: