stoo

Wow - that looks awesome!

I hadn't assumed my list was exhaustive, but I think what I put was accurate - wasn't it? Had definitely forgotten about the EX ones though...

There was - except they called it an SB14 and discontinued it again after a while.... presumably after getting fed up of having to explain what it was You sure? The early OLP "Stingray"s were passive but they were named MM2 / MM3, not SUB The EBMM SUBs came as both active and passive (I've got an active one from 2003 and a 2004 one that was originally passive) but were made in USA Then OLP came out with the active HH models in 2007.... named MM22 / MM32, not SUB I think the Sterling by Musicman SUBs were always active, weren't they? I had one of the early ones not long after they came out and don't remember there being a passive option at the time? Was a while ago though - might be misremembering

Sorry - I was sure I'd already replied to this... must have closed the window before the post got submitted. The nextion/mega version has an expression pedal input, but the oled/nano original version didn't. If you wanted to add an expression pedak to the oled/nano version, you'd need to add the extra bits in yourself depending on how you want yours to work. My implementation was a bit odd because my "expression pedal" was actually a converted wah pedal - so it had a audio taper pot instead of linear, and a latching footswitch instead of momentary. If you have a linear pot expression pedal and a momentary switch (or no switch at all) then you could probably simplify things a lot

Nice - it looks like Heiko has made some decent progress on cracking the USB comms between his Stomp and HX Edit... In his project he uses Python scripts on his computer to get the info from the Stomp - https://line6.com/support/topic/60839-another-lockdown-project-talk-to-your-hx-stomp-over-usb/ https://github.com/kempline/helix_usb I'd planned to see if I could get something similar working on Arduino with a USB host adaptor.... life keeps getting in the way though!

That would require some extra code to be written to support it.... As mentioned above, I had originally intended to, but found I didn't need it.... And so that part never got finished. Feel free to have a go though!

Ah ok I see... The extra pages in the Nextion file were just a placeholder for future functionality that I intended to implement. I had initially planned to make everything re-programmable from the touchscreen without needing the computer...... But once I got the first prototype built and working, I found I didn't need to reconfigure the pages and so didn't do any more work on that functionality.

Nice one! Frustrating that you don't know exactly what the issue was - hopefully just a loose connection that needed to be reseated. What's the issue with the other pages? Sorry - I don't understand your question.....

I don't understand why you are so confident that you've got everything correct with the midi output.... If that was the case, then the simple midi output test sketch I posted should change presets on your HX..... Been a while since I used serial monitor, and i only used it on the default serial port.... Arduino Mega has several, so you may need to change the monitor to the one used for the midi output... Not sure if that's possible - not in front of a computer to check

Aaaah - just found a link to someone who has had some success decoding the usb communications between stomp and hx-edit. I think I saw them mention it before on Facebook but never saw any further details. There's a link to some stuff on GitHub and their demo with an FBV3 - https://line6.com/support/topic/60839-another-lockdown-project-talk-to-your-hx-stomp-over-usb/ Guess I might have to start work on a v3 controller with scribble strips and RGB footswitch LEDs....

Ignore the nextion for now. You've already shown that you have that part working and communicating with the Arduino. If you don't have the midi output part working correctly, any further testing with the nextion is impossible as you have no way of knowing if its doing anything. On my switcher, I can press the FS1,FS2,FS3 etc buttons on either the screen or the actual footswitches..... And if the midi cable is not correctly connected, nothing will happen. There is no visual indication on the screen to confirm the button press.

Yep - look at the looper fwd/rev button part as an example

I don't think that'll be it.... It's a warning that I've sent a "string" type value as an argument to a function that has a "char*" type value as its parameter. This is something that used to be allowed - it didn't throw up any errors for me when I built my one 3 years ago. They've since changed the rules.... but I think this is still just a warning that can be ignored. Not totally certain - but I can't easily test with mine at the moment to confirm.... What you could do to test your MIDI output is to use some simpler code that tests only the MIDI output part... I think something like this should work... If it does, it will just change back and forth between 2 presets every second #include <MIDI.h> MIDI_CREATE_INSTANCE(HardwareSerial, Serial2, MIDI); void setup() { MIDI.begin(MIDI_CHANNEL_OMNI); // Launch MIDI and listen to all incoming messages } void loop() { if (MIDI.read()) // If we have received a message { MIDI.sendProgramChange(1, 1); // Send a PC1 on channel 1 delay(1000); // Wait for a second MIDI.sendProgramChange(2, 1); // Send a PC2 on channel 1 delay(1000); // Wait for a second } }

the "recvRetCommandFinished" messages look to be something that the Nextion library generates... (see line 187 here - https://github.com/itead/ITEADLIB_Arduino_Nextion/blob/master/NexHardware.cpp) - looks like it's probably a message from the Nextion back to the Arduino to say that it's recieved a command and confirm it's completed it OK. I'm not sure why the 3rd one reports an error - it doesn't give much information to go on - but the first two report as "ok"... so I would think the basic communication between your Arduino and Nextion is probably OK. If your footswitches can change the page on the Nextion - then you've definitely got communication between the footswitches and the Arduino, as well as between the Arduino and Nextion..... so you're most of the way there now! Next thing to investigate is the MIDI connection to the HX...

I'm not sure I understand what you're attempting here..... if you only have the footswitches connected, but not the screen or the MIDI output...... then not much is going to happen! If you're using the code from my project, then the switches will need to be connected to the 0-7 switches as shown in your picture.... the Analog pins at the bottom can be used for inputs, but you'd need to change the code to listen on different pins..... In the video you posted above, it shows you pressing the >> button, and then the screen changing the menu page.... That shows that you had the connection between the Arduino and the Nextion working OK. (The Nextion sends a notification to the Arduino that you've pressed the button on the screen, and then the Arduino updates the menu page and then sends an instruction back to the Nextion to change the display to match) Once you have the Nextion working, it's easier to test the MIDI next. Hook up the MIDI socket and your HX device and then press the FS1 button on the Nextion screen..... something should happen on the HX (as long as you're in a patch that has an action assigned to FS1!) Once you know that's working, then try the switch inputs on the Arduino. If you're not 100% confident in your footswitches, leave those disconnected and just use a test wire - Connect one end of it to a spare GND pin on the arduino, and then try touching it on any of the 0-7 pins (NOT the ANALOGIN A0-A7 pins!) and see if that does anything. If that works, then you know you need to investigate the wiring for your footswitches Good luck!

Do you have your switches connected to A0-A7 ? Doesn't look like anything is connected to pins 0-7 on the Arduino at all.... that's where I had my switches connected....

I think I know what you mean..... If you have, for example, - switch 0 set to toggle FS1, - switch 1 set to toggle FS2, and - switch 1+2 set to scroll to next page, then when you press switches 1 and 2 it might trigger FS1 or FS2 before eventually also triggering the next page. If so, then that's a limitation of the way it was written. When the Arduino scans the buttons, as soon as it detects a button press it does the action assigned to that button straight away. Then it continues to scan the button states, and if it detects another button is pressed down before the first button was released then it checks if there's an action assigned to that combination of buttons. Another way of doing it would be to wait for either the first button to be released, or a second button to be pressed, before triggering the action. This would allow you to prevent accidental triggers of the single switch function when you only wanted the combo function..... but it would have a really bad side effect. If you just wanted to trigger FS1, and so stepped on switch 0.... nothing would happen until you lift your foot off the switch again. This delay might not be too noticable if you instinctively tap and release each switch very quickly all the time..... but I definitely don't do that. If you have buttons configured for looper controls instead of just effects on/off toggles then the problem gets even worse. Hope that makes sense

So.... if you press the buttons on the Nextion screen, the MIDI commands get sent to the stomp as you would expect? that bit works OK? Do the other switches work as you would expect on pins 2 thru 7 ? Pin 0 and Pin 1 on a Mega can be used as either regular digital pin inputs, or as a Serial channel as RX0/TX0 - I'm not entirely sure if it would be expected to see TX/RX lights illuminated when using Pins 0 and 1 as digital inputs.... I never noticed it happening on mine when I was building/testing it, but I wasn't particularly looking out for it at the time. I can't easily get to mine to check it at the moment. I think if you have somehow got the nextion or the midi trying to talk on Serial0 then strange things might happen, but if you're using a Mega and your code is the same is mine, then I can't see how that'd happen....?

Bit more info on why I thought that might not always be the case: https://emalliab.wordpress.com/2021/12/15/getting-to-know-the-arduino-nano-every/ Might be worrying about nothing for most use cases, but suspect it'll just depend on which libraries you end up using...

Dunno - I haven't used the Nano Every, but it looks like it's the same form factor as an original Nano, but with a different processor. I would guess they've tried to make it backwards compatible with code written for the original Nano, but there's always the risk that a library has tried to refer to specific parts of the hardware directly to maximise speed or efficiency.

Sure - just look for this bit: void changePageUp() { currentPage++; if (currentPage >= pageCount) { // we have gone past the last page currentPage = 0; // reset to first page } } void changePageDown() { currentPage--; if (currentPage > pageCount) { // we have scrolled back past the first page currentPage = (pageCount -1); // reset to last page } } And change it to something like : void changePageUp() { // function adapted to send MIDI CC instead of controller Page Up const byte controlNumber = 49; // MIDI CC# number to send - CC49 is FS1 const byte controlValue = 0; // MIDI Value to send - can be any 0-127 for CC49 -> FS1 const byte midiSendChannel = 1; // MIDI channel to send this message on MIDI.sendControlChange(controlNumber,controlValue,midiSendChannel); } void changePageDown() { // function adapted to send MIDI CC instead of controller Page Down const byte controlNumber = 68; // MIDI CC# number to send - CC68 is tuner on/off const byte controlValue = 0; // MIDI Value to send - can be any 0-127 for CC68 -> tuner on/off const byte midiSendChannel = 1; // MIDI channel to send this message on MIDI.sendControlChange(controlNumber,controlValue,midiSendChannel); } Ideally you'd also also go through and change all the PageUp and PageDown functions, variable names and comments elsewhere to make things easier to follow / troubleshoot when you next come to look at the code. I'll leave that up to you to decide whether to bother though...

The arduino definitely won't care if you have less buttons..... it can't tell the difference between a button you aren't pressing and a button that doesn't exist. I think you'd probably be fine with no OLED, but you'd have to test it and try.... I know the display startup sequence will flash an error LED if it doesn't correctly detect the OLED, but can't remember if it just flashes and moves on, or keeps blinking until you fix the problem. Either way, would only need to remove the display related bits of the code for it to work again.

Fair enough - but the two different versions I've made and posted the details for use completely different codebases - so if you're asking questions about the code, we'd need to work out which one you're starting from as the answers will probably be different depending on which you've chosen. Ah in that case - both of the ones I wrote send on channel 1 by default. And the HX stomp listens on channel 1 by default as well....

I think they're probably using the https://github.com/stoonoon/hxsMidiSwitcher version which wouldn't have that bit in it though.....

If you're using the Nano/OLED version, I didn't really consider changing the MIDI channel at the time.... No reason why it can't be changed, but it'll take a bit more effort than just changing one value, unfortunately.... In the mega/touchscreen version I fixed this by declaring the "midiSendChannel" constant using the line that tauzero mentioned before: const int midiSendChannel = 1; // MIDI channel for outbound messages and then whenever I called the MIDI library to send a message, it references that constant to decide which channel to send on. MIDI.sendControlChange(controlNumber,controlValue,midiSendChannel); MIDI.sendProgramChange(programNumber,midiSendChannel); On the earlier version though, the channel number is just hard coded into each MIDI send call's parameters, like these: MIDI.sendProgramChange(0,1); MIDI.sendControlChange(68,68,1); //tuner You could go through and replace each of those with your new channel number, but I'd be tempted to do a find and replace for ,1) to ,midiSendChannel) and then add the const int midiSendChannel = 1; // MIDI channel for outbound messages somewhere near the top... then you could just change that 1 to whatever channel you wanted to use, and if you decided to change again in the future it'd be that much easier to do.