Comments (42)
Mostly yes, with "0x03" in the init packet being "0xc1" instead!
Other corresponding outgoing packets seem consistent.
I will see if matching that one byte works.
Interesting, thank you!
It would be really annoying if a single byte causes this trouble ๐
Contributions are always welcome ๐
from plug.
Another approach I have thought about: Some kind of test suite, which runs a communication sequence step by step and asserts the result. So we'll see where in the sequence it fails and can dig deeper without running a gui etc.
from plug.
Fixing the byte, I could indeed wake my Mustang I V2.
Loaded packets
Another observation: when loading, Mustang I V2 returns 6 unidentified packets after the last 12th effect knob preset.
(Firmware version: 2.2)
That makes received_data.size()
to be 147, invalidating the smallAmps
vs. bigAmps
condition in the ternary.
Line 164 in cb55af5
I'm not sure why the number is set as 143, so I get cautious updating it.
What can I do to ensure I don't break other devices?
Blame does show 143 (c422e8f) itself is already a firmware update from 142 (4bd030b).
What would the 6 additional packets mean?
I guess we have no choice but to just ignore?
from plug.
@dalareo Would you take a look at my fork?
The upstream codebase might have changed since then, but I remember I had this version tested in Ubuntu 22.04.
from plug.
Just changing init1 value at Packet.cpp and const std::size_t max_to_receive = (recieved_data.size() > 147 ? 200 : 48); // 147 is the number of packets for Mustang I v2.21
at Mustang.cpp did the trick!
from plug.
I have tested the 0xc1
init1 byte on a v1 device and it seems to work too ๐ค.
from plug.
Can you give this experimental branch a try experimental/240-v2_support
?
It contains the init1 0xc1 byte and doesn't calculate the packet number where possible, but uses a fixed number (100 Presets to Mustang III+ v2 and 24 for Mustang I/II v2)
from plug.
It works like a charm with my Mustang I V2 in a mini Mac with M2
from plug.
Merged.
from plug.
@Odzinic did you record the data with the full plug executable or the test one?
from plug.
That was run using the full executable since I ran it on my system that has a display.
from plug.
Can you build and test with the minimal executable (#3 (comment))? It just connects to the amp and loads the stored data.
I'm not sure if it's really necessary, but better flush the output by changing these two lines:
test/integration/Main.cpp (40):
std::cout << "---\n\n";
to
std::cout << "---\n" << std::endl;
std::cout << "\n--------------------\n";
to
std::cout << "\n--------------------" << std::endl;
from plug.
Definitely. I changed those two lines and ran the test executable and got the following log: plug_debug.txt. Looks like we got a new amp id
in the error this time.
from plug.
Thanks, that's interesting. Do you get the same id on each run or does it change?
from plug.
Yes. I just tested it about 10 times with unplugging the usb and restarting the amp and I received ERROR: Invalid amp id: 32
every time. Even changing the selected amp setting didn't change the id.
from plug.
That's interesting, especially since the plug executable receives 0 id's instead.
from plug.
I have updated the branch for a more readable formatting and preset data only. There should be 7 packets, 64 Bytes each. The 2nd packet contains the amp info, where the first byte of line 3 is the amp id.
from plug.
Sorry for the long delay. I was away from my amp for a few weeks.
I updated the branch and ran CommIT
but didn't get much useful data out of it. Seems like the 4th packet is the only one that isn't completely 0s.
plug_debug.txt
from plug.
Oh โฆ it seems the amp id is one of the smaller problems here โฆ
Sorry if I have asked before, but udev rules and plugdev group are setup correctly?
from plug.
As far as I know, I'm pretty sure it's setup properly.
I have a group named plugdev
and the udev rule 50-mustang.rules
. 50-mustang.rules
contains:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="1ed8", ATTRS{idProduct}=="0014", GROUP="plugdev"
which matches the vendor/product id of my amp:
Bus 001 Device 025: ID 1ed8:0014 FENDER MUSICAL INSTRUMENTS CORPORATION Mustang I (V.2)
.
Now that I think about it though, I have tried deleting the rule and redoing it several times but have never tried deleting and remaking the group. I'll give that a shot.
from plug.
Looks ok.
from plug.
I've also tried to run plug as root to "skip" the plugdev
permissions and still get the same Invalid amp id: 0
error followed by Error: Resource busy
when trying to connect a second time. I'll try to setup the testing branch of plug
on my RPi and run CommIT
on there to see if it could be an issue with my PC setup.
from plug.
I finally setup plug on my RPi and ran it but got even less favorable results.. Seems like everything is 0s. Running a diff
between the log from my PC and the log from my RPi only showed one line on difference in the fourth received packet:
d1 5e 00 00 00 00 00 00
00 00 00 00 00 00 00 00
Double checked all my udev permissions stuff on the RPi and it all looks like it should. Here is the RPi log: plug_commIT.log
from plug.
Thanks, at least we can eliminate another possible cause.
In case I haven't asked yet: Is there any version of plug (earlier release, original version) that works?
from plug.
I'm similarly seeing "Invalid amp id: 159" on a Mustang I v2
from plug.
Stays the value same? I've not seen it before.
from plug.
Oh, I don't think the value stayed the same after I tried again on a reboot
from plug.
But the error still occurs, with different values though?
from plug.
Correct
from plug.
I don't have a v2 device around, but at first glance I'd expect the communication getting out of sync. v2 still uses the same protocol โ at last as far as I know.
Does re-plugging, restarting or changing amps on the device make any difference?
from plug.
Hi, I have the same device and issue: "Invalid amp id: 0" every time. None of the above helps (didn't try factory reset of the Mustang though).
I also tried version 1.3.0 of plug. That connected successfully but with some strange behavior. I was unable to change the amp, changing anything just muted the mustang.
Let me know if I can help somehow. :)
from plug.
I also tried version 1.3.0 of plug. That connected successfully but with some strange behavior. I was unable to change the amp, changing anything just muted the mustang.
Earlier version have ignored any package errors, so everything read afterwards may just be garbage.
โ
An amp id of 0 indicates a broken amp data transmission, you can see all available values here.
Since the issue occurs on different devices (all still v2 though), it's unlikely to be caused by a sync issue. Now, what we can do here is either a.) try to gather information about the v2 protocol used and/or b.) capture the initial transmission of a v2 device and compare with v1.
The later can be done by tools like Wireshark or a kind of self written dumper. Maybe some kind of "test version", with lots of logging could work here too โ at least we could compare each transmission step with the expected data.
from plug.
Can this be related to the fact that V2 has additional amp models, which are not implemented here yet?
https://www.middle8reviews.com/comparison-fender-mustang-amp-v1-vs-v2/
from plug.
If they are just additional amp models, but the transmitted uses the same format it should fail with some non-0 id.
Has someone some spare time to take a look at the communications?
from plug.
Now I have installed Windows VM with Fuse & USBPcap.
I saved a dump file which should contain the transmissions from Fuse initialization and subsequently switching to every amp model and stompbox.
I gave a brief look in it with Wireshark, but not very sure how to proceed.
from plug.
Do you see initialization steps as listed the docs (ยง 2)?
You can compare the amp packets too; when switching amp there should be a transmission of format described in ยง3.
from plug.
Mostly yes, with "0x03" in the init packet being "0xc1" instead!
Other corresponding outgoing packets seem consistent.
I will see if matching that one byte works.
Additionally, would it be good if I work a little bit on documenting the V2 features and maybe implementing them?
from plug.
Oh, these are good news ๐. So v2 still uses the same protocol, but with some extras.
Are there any additional features v2 has over v1 that would need additional data transmitted?
The lines after the marked do two thins: a) receive a list of all preset names on the device and b) receive the selected presets data.
from plug.
Can you please provide a fix to make Mustang I V2 recognized? I've read that "fixing the byte" did the trick, but not really sure where/what is that byte!
I am using 1.1 with Ubuntu 22.04 whithout problems but not able to run Plug in MacOS.
from plug.
Using the number of transmitted packets for calculation of presets isn't that stable โ as shown for other devices. It might be better to replace the calculation with known values (where possible).
Is it safe to use 24 Presets (= 48 related packets) for Mustang I v2?
from plug.
Thanks for testing. GH Actions have some issues at the moment; I'll merge the branch once the CI build works again.
from plug.
Released as v1.4.4.
from plug.
Related Issues (18)
- Invalid amp id: 0 HOT 19
- 'cmake ..' Fails on Antergos (kernel 5.4.6) HOT 4
- Mustang V v2 amp not recognized. HOT 26
- Could NOT find GTest HOT 8
- Compiling fails in Manjaro HOT 3
- Fender Rumble LT 25 support? HOT 23
- Fender Mustang 2 - Core Dumped HOT 6
- MacOS compilation HOT 16
- Loading effects from amp or file does not preserve the position HOT 23
- Cmake fails due to Gtest dependency on Ubuntu Studio 22.04 HOT 8
- Fedora 36 FTBFS due to warnings as error - Allow? HOT 3
- FTBFS GCC 13 HOT 2
- Fender G-DEC 30 Compatiblity HOT 1
- Fender Bronco 40 support? HOT 42
- udev rules installed incorrectly under /usr/lib64/udev HOT 3
- Super Champ XD HOT 3
- Mustang GT 40: No device found HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from plug.