You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Plug v1.2.1 identifies the amp and works correctly, but this version does not. I'm not sure what the difference is. If you need any info from the Mustang V v2, just let me know and i'll get it.
Thanks for reporting. Can you check die usb vid / pid of your amp (eg. using lsusb)? It should show a vid of 0x1ed8 and a pid of either 0x0014 or 0x0016 (supported pid's).
The vid is still 0x1ed8? The supported pid's don't have changed between both versions and 0x0016 is still available. What kind of error do you get btw.?
Since there's a working earlier version, the udev rule or other permission issues aren't the root cause.
If you have some time left, you can use git bisect to figure out the causing commit. There are tags for the mercurial v1.2.1 and initial importing commit. Unfortunately I don't have a V2 around.
Hi, I didn't noticed this issue, so i forked your project and added an initial support for V2 amps.
To be more precise, my Mustang II V2 was recognized and works correctly, but plug lacks the "V2-only" features (some mod, stomp and amp).
moreover, I am trying to fix some weird issue on raspberry pi with USB communication, and changed something in USBComm to handle transmission retries (as in mustang-midi-bridge). Some other changes including loadfromfile to handle (maybe) incorrect fuse files.
Still no changes in updater
Could you please review my changes and in case take them into account?
Just to be sure: udev rules are installed and working?
Ok, the issue was I forgot to create the plugdev group and add my user to that group. Might be a good idea to include the same note piorekf added to his wiki to your README.md file.
Could also be a good idea to change the links to a wayback machine link, since apparently piorekfs repository is no longer available.
Is there a still a reason to keep the updater code? If so, it definitely needs some improvements.
Could be useful if someone is still running an older version of the firmware and wants to update. Some digging would need to be done to find the firmware files, as fender decided to stop hosting everything Mustang V1/V2 related. I keep a backup of everything on my computer just in case.
On another note, have you included anything from zavorra's repo?
Ok, the issue was I forgot to create the plugdev group and add my user to that group. Might be a good idea to include the same note piorekf added to his wiki to your README.md file.
make install takes care of the udev files already. Is it a good idea to include another target, which installs the udev files only (in case someone wants the rules, but not the application installed)?
Could also be a good idea to change the links to a wayback machine link, since apparently piorekfs repository is no longer available.
Good point, all links back to Bitbucket are dead now. Well done Atlassian.
Could be useful if someone is still running an older version of the firmware and wants to update. Some digging would need to be done to find the firmware files, as fender decided to stop hosting everything Mustang V1/V2 related. I keep a backup of everything on my computer just in case.
The updater code is still there, but the updater is disabled in the UI (however, just a boolean to flip). Let's see if someone realy needs it.
On another note, have you included anything from zavorra's repo?
Coming back to the origial issue: To get some more infos out of the USB device error, it's neccessary to replace the related libusb code, allowing error handling. It shouldn't be difficult though. But at this point it's worth thinking about replacing plain C libusb calls with something improved, eg. libusbpp or libusbpp11 (suggestions welcome).
I'm unsure if I'm experiencing the same issue, but I have been receiving a ERROR: Invalid amp id: 0 error for my Mustang I (V.2) with a lsub output of ID 1ed8:0014 FENDER MUSICAL INSTRUMENTS CORPORATION Mustang I (V.2).
The exception indicates a corrupted amp packet – unfortunately not more information. Does this happen always? I've experienced the issue too, but quite rarely. Typically a reconnect of the usb connection solved it.
In doubt, we could try to dump all received packets to get some more insight of what's transmitted actually.
This has happened to me every single time I've tried to run plug with this amp. I have never been able to connect successfully (tried with other versions in the past as well but can't recall the exact versions).
I tried reconnecting the USB five times but kept getting the same error. The only difference was that id went from 0 to 1 on the second reconnection:
ERROR: Invalid amp id: 0 (Running plug first time)
ERROR: Invalid amp id: 0 (First USB reconnection while plug was still open)
ERROR: Invalid amp id: 1
ERROR: Invalid amp id: 1
ERROR: Invalid amp id: 1
ERROR: Invalid amp id: 1
Forgive my stupid question, have you tried different cables? And, you are
using an usb3 port? An USB hub? Could you try different hw?
Z
P.S. Is It a Raspberry Pi or a PC?
Il mar 13 lug 2021, 20:08 Omar Dzinic ***@***.***> ha scritto:
This has happened to me every single time I've tried to run plug with this
amp. I have never been able to connect successfully (tried with other
versions in the past as well but can't recall the exact versions).
I tried reconnecting the USB five times but kept getting the same error.
The only difference was that id went from 0 to 1 on the second reconnection:
ERROR: Invalid amp id: 0 (Running plug first time)
ERROR: Invalid amp id: 0 (First USB reconnection while plug was still open)
ERROR: Invalid amp id: 1
ERROR: Invalid amp id: 1
ERROR: Invalid amp id: 1
ERROR: Invalid amp id: 1
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4BNMWHWHZCNGRF7O2JIOLTXR6I3ANCNFSM4KLHEQJA>
.
Does the amp setting on your amp show any amp listed here?
It could be interesting to see whether you'll get past the amp packet or fail on the next. Eg. replace the throw clause with a return of a valid value (one of the switch statements).
Forgive my stupid question, have you tried different cables? And, you are using an usb3 port? An USB hub? Could you try different hw? Z P.S. Is It a Raspberry Pi or a PC?
I have used multiple cables and have had the same issue on all. I just tested both USB2.0 and 3.0 but it persisted on both. I have tested this on a PC and just tried testing it on my RPi but it seems I have to have a display connected to run the program due to its GUI.
This is strange ...
Does the amp setting on your amp show any amp listed here?
It could be interesting to see whether you'll get past the amp packet or fail on the next. Eg. replace the throw clause with a return of a valid value (one of the switch statements).
The amp that I was testing with was FENDER_65_TWIN_REVERB but I just tested it with every other amp setting in that list and they all returned ERROR: Invalid amp id: 0. If I try connecting to the amp again after I get that error without removing the usb cable I get ERROR: Resource busy.
A thought that popped into my mind was that I do recall connecting the amp to the official fender amp program a while back. I can't recall if it was through Wine or a dual boot but could that have possible changed around the amp ids to make them undetectable by plug?
I'll write a dumper so we get some insight what's going on here.
A thought that popped into my mind was that I do recall connecting the amp to the official fender amp program a while back. I can't recall if it was through Wine or a dual boot but could that have possible changed around the amp ids to make them undetectable by plug?
No, the former FUSE software doesn't change anything persistent on the amp (except doing an update of course 😄). A simple power off, power on reverts back to the state saved on the amp.
I've pushed a test branch: test/amp_id_repro. It'll print all packets received.
Additionally, building with -DINTEGRATIONTEST=ON creates a simple test executable test/integration/CommIT without UI. It connects to the amp, receives the stored preset data and closes.
Activity
offa commentedon Jan 24, 2020
Thanks for reporting. Can you check die usb vid / pid of your amp (eg. using
lsusb)? It should show a vid of0x1ed8and a pid of either0x0014or0x0016(supported pid's).beelzebud commentedon Jan 25, 2020
Ok today I had a chance to see the output of lsusb. In normal mode the amp reads 0x0016, and in maintenance mode it reads 0x0017
beelzebud commentedon Jan 25, 2020
Also if it helps, the old software recognized the amp at v1.2.1. https://bitbucket.org/piorekf/plug/src/default/ is the version that works with the MustangV v2.
offa commentedon Jan 26, 2020
The vid is still
0x1ed8? The supported pid's don't have changed between both versions and 0x0016 is still available. What kind of error do you get btw.?Since there's a working earlier version, the udev rule or other permission issues aren't the root cause.
If you have some time left, you can use git bisect to figure out the causing commit. There are tags for the mercurial v1.2.1 and initial importing commit. Unfortunately I don't have a V2 around.
zavorra commentedon Feb 19, 2020
Hi, I didn't noticed this issue, so i forked your project and added an initial support for V2 amps.
To be more precise, my Mustang II V2 was recognized and works correctly, but plug lacks the "V2-only" features (some mod, stomp and amp).
moreover, I am trying to fix some weird issue on raspberry pi with USB communication, and changed something in USBComm to handle transmission retries (as in mustang-midi-bridge). Some other changes including loadfromfile to handle (maybe) incorrect fuse files.
Still no changes in updater
Could you please review my changes and in case take them into account?
You can find them in https://github.com/zavorra/plug.git
offa commentedon Feb 19, 2020
Are there still updates for V2? V1 is dead.
Great to see people working on this! Feel free to submit PRs – either here or on Gitlab, whatever suits best for you.
Snayler commentedon Mar 8, 2021
Getting a similar issue on a Mustang IV V2.
lsusboutput as follows:Bus 002 Device 007: ID 1ed8:0016 FENDER MUSICAL INSTRUMENTS CORPORATION Mustang IV v.2On the GUI it only says:
Error: Failed to open usb deviceAre there any log files that I can check?
The latest firmware update for V2 is 2.2, it's some years old and with fender removing support for Mustang V1/V2, I doubt there will be more updates.
offa commentedon Mar 8, 2021
VID / PID look good, so the application should pick it up correctly. The error indicates there's no device found though. Does this happen always?
Just to be sure: udev rules are installed and working?
Unfortunately no, the application itself doesn't write any logs yet. Maybe you can get some hints through the system logs.
So the situation is the same as V1. 👎
Is there a still a reason to keep the updater code? If so, it definitely needs some improvements.
Snayler commentedon Mar 8, 2021
Ok, the issue was I forgot to create the plugdev group and add my user to that group. Might be a good idea to include the same note piorekf added to his wiki to your README.md file.
Could also be a good idea to change the links to a wayback machine link, since apparently piorekfs repository is no longer available.
Could be useful if someone is still running an older version of the firmware and wants to update. Some digging would need to be done to find the firmware files, as fender decided to stop hosting everything Mustang V1/V2 related. I keep a backup of everything on my computer just in case.
On another note, have you included anything from zavorra's repo?
offa commentedon Mar 8, 2021
make installtakes care of the udev files already. Is it a good idea to include another target, which installs the udev files only (in case someone wants the rules, but not the application installed)?Good point, all links back to Bitbucket are dead now. Well done Atlassian.
The updater code is still there, but the updater is disabled in the UI (however, just a boolean to flip). Let's see if someone realy needs it.
Not yet.
offa commentedon Mar 8, 2021
Coming back to the origial issue: To get some more infos out of the USB device error, it's neccessary to replace the related libusb code, allowing error handling. It shouldn't be difficult though. But at this point it's worth thinking about replacing plain C libusb calls with something improved, eg. libusbpp or libusbpp11 (suggestions welcome).
Odzinic commentedon Jul 11, 2021
I'm unsure if I'm experiencing the same issue, but I have been receiving a
ERROR: Invalid amp id: 0error for my Mustang I (V.2) with a lsub output ofID 1ed8:0014 FENDER MUSICAL INSTRUMENTS CORPORATION Mustang I (V.2).offa commentedon Jul 11, 2021
@Odzinic what version are you using? The usb vid / pid are ok.
Odzinic commentedon Jul 11, 2021
1.4.2 compiled from git yesterday.
offa commentedon Jul 12, 2021
Could you test with latest master? I've rewritten most of the USB code. You can enable additional libusb logging by setting
LIBUSB_DEBUG.Odzinic commentedon Jul 13, 2021
Sorry my previous message was my convoluted way of saying I compiled from master so I think I'm as up to date as possible.
I ran debugs 1-3 and didn't get anything other than
ERROR: Invalid amp id: 0but I captured the debug output if it can help:plug_debug.txt
offa commentedon Jul 13, 2021
The exception indicates a corrupted amp packet – unfortunately not more information. Does this happen always? I've experienced the issue too, but quite rarely. Typically a reconnect of the usb connection solved it.
In doubt, we could try to dump all received packets to get some more insight of what's transmitted actually.
Odzinic commentedon Jul 13, 2021
This has happened to me every single time I've tried to run plug with this amp. I have never been able to connect successfully (tried with other versions in the past as well but can't recall the exact versions).
I tried reconnecting the USB five times but kept getting the same error. The only difference was that id went from 0 to 1 on the second reconnection:
zavorra commentedon Jul 13, 2021
offa commentedon Jul 13, 2021
This is strange ...
Does the amp setting on your amp show any amp listed here?
It could be interesting to see whether you'll get past the amp packet or fail on the next. Eg. replace the throw clause with a return of a valid value (one of the switch statements).
Odzinic commentedon Jul 13, 2021
I have used multiple cables and have had the same issue on all. I just tested both USB2.0 and 3.0 but it persisted on both. I have tested this on a PC and just tried testing it on my RPi but it seems I have to have a display connected to run the program due to its GUI.
The amp that I was testing with was
FENDER_65_TWIN_REVERBbut I just tested it with every other amp setting in that list and they all returnedERROR: Invalid amp id: 0. If I try connecting to the amp again after I get that error without removing the usb cable I getERROR: Resource busy.A thought that popped into my mind was that I do recall connecting the amp to the official fender amp program a while back. I can't recall if it was through Wine or a dual boot but could that have possible changed around the amp ids to make them undetectable by plug?
offa commentedon Jul 13, 2021
So at least we can eliminate a HW issue.
I'll write a dumper so we get some insight what's going on here.
No, the former FUSE software doesn't change anything persistent on the amp (except doing an update of course 😄). A simple power off, power on reverts back to the state saved on the amp.
offa commentedon Jul 16, 2021
I've pushed a test branch:
test/amp_id_repro. It'll print all packets received.Additionally, building with
-DINTEGRATIONTEST=ONcreates a simple test executabletest/integration/CommITwithout UI. It connects to the amp, receives the stored preset data and closes.Odzinic commentedon Jul 16, 2021
Thanks for creating the branch. Here is the response I received when running it: plug_debug.txt.
offa commentedon Jul 16, 2021
@Odzinic lets move this problem to a new issue (#6).
offa commentedon Nov 29, 2023
I have pushed some v2 related changes (see #6), could you give them a try?