I recently wrote about having problems with my modules connected together, where the single ones worked. Unfortunately, this forum seems to be rather inactive and nobody answered until today. I thought I had somehow written bad scripts and that is why I included those in the posts. However, since then I have done a much simpler setup and the problems persist - well, they actually come and go and I am afraid I have to say as things are right now, the grid controllers with the current software are not reliable to me and start frustrating me (although I am quite willing to learn complicated stuff). If I do not find a solution to this, I will have to look for another controller.
The problems is always the same: when I connect one module, it works fine, but as soon as I connect two modules together it is really hit or miss! During programming everything works fine, I then save a backup and suddenly I get missing elements on the second controller (the one connected magnetically). At first, I thought it might be a power problem, as the problem sometimes disappeared when I connected the devices over a powered USB hub. However, whenever that powered hub was connected to the Mac first, all of a sudden the problems came back (missing elements).
I really need this to get working, as the two modules were supposed to replace my broken old fader and button controller. Until now, they rather take use up my time and I cannot have that right now. I am not at all against complicated setups in order to get a flexible device. But I cannot have unreliable equipment - especially, if it works one day and not the second.
1.2.31 firmware unfortunately introduced instability in multi-module setups. Can you canofirm that you are running this version of the firmware? In the Grid Editor the firmware version is displayed on the module’s UI!
I am working on a patch that fixes this issue, If everything works out this will be released on Friday.
Thanks for the quick reply! Yes, the firmware is 1.2.31. I am looking forward for the update and wish for the best.
In case it helps: I found out that the second module (the one not connected via cable) does not load all elements. In my case, only the first 5 buttons loaded correctly. I could press them and they reacted. When I press any of the other buttons, the second module kinds of crashes and I have to detach and reattach it. There is one way to get it to work: when I switch pages the as the first thing to do, the second module works fully. I guess you already know this, but thought it wouldn’t hurt to mention it.
We successfully identified and fixed two major bugs, both caused by classic memory safety issues. The one in the co-processor caused connection dropouts, the one in the main processor cause the unresponsiveness to config changes and the seemingly stuck pages due to an unhanded race-condition.
Today we release the new firmware version for ESP32 based modules and the accompanying Editor version. Please update both and let us know if you experience any other issues!
So far, so good. Just did a 1 hour improv practice with an EF44 and EN16. No hiccups whatsoever. Before, the EN16, which was second in the chain, was being screwy/disconnecting.
Unfortunately, I now have found another problem: with the previous firmware, grid connected to my iConnectivity midi Interface (which has USB ports for generic midi devices). Now, it is no longer recognized. Could you get that functionality back with another update?
@suku Can you reproduce that the new firmware causes problems with the grid device being recognised as a generic midi device? My midi interface never had problems to accept any generic midi device. There are various synths and controllers attached to it via USB and all of them are recognised. So, I have no other explanation for this behaviour other than the grid firmware changing.
It must be related. I updated the firmware and exactly since then the grid midi usb interface could not connect to the iconnectivity mioXL. All other devices still continue to work. So, the only explanation could be that the new firmware prevents the connection.
@suku I tried loading the older firmware back to the device to verify with 100% that the firmware is the reason, but it seems that downloading older versions of the editor does not revert the the firmware back to the old version. So, I found this page:
However, the when I follow those steps (the bootloader is already 0.0.2 on my device, so I skipped that step) and copy the new firmware to the device, the module automatically ejects itself (from macOS) and macOS reports it is no longer available. How can I make that work?
Apart from that, have you found any clues why the firmware could cause problems being recognized as a generic midi device?
Ok, I found out a little more! There were actually two problems at once, which made it even harder to find the causes …
I managed to upload the older firmware to one of the grid Modul. The macOS error report is probably not right and I now have the last firmware installed.
WIth that firmware I get a connection to another connectivity interface I have.
Without me noticing, there recently was an update of the mioXL firmware, and to that updated interface I can also not connect with the older firmware on the grid controller.
iconnectivity does not provide legacy firmwares on their website, so I have to ask them and will also report a problem to them.
However, my testing proves that the last firmware updated to 1.2.32 did introduce a problem! With that firmware, the grid controller does not show up and send midi to it. With 1.2.31 it does. So, I hope an update to address that as soon as possible.
Also, I would like to see an easier way of using and older version of grid editor and firmware. As it is now, the editor will automatically updated. But that is not what I want when there are problems with a new version! And since the last two version each had a problem of their own, I would like to be able to stay with an older version and still do changes to my settings. Can you add an option to switch the auto update off?
The last thing I would want is to connect my Grids to make a simple tweak before a show (even a week before) and have them auto-update to a firmware that breaks everything.
After a bit more experimentation with the different firmwares of grid and also the mioXL interface I found out this:
The firmware of mioXL actually does not matter. There is no difference regarding that. So, the problem is 100% only due to grid firmware.
With the previous firmware of grid I obviously get back the problem of a second module magnetically connected not being properly loaded with all functions unless I switch the page before using it. But apart from that, one module alone and both together work as supposed to.
With the latest firmware nothing goes. Not a single module connects, neither do both connect.
BUT:
When I reboot the interface with both or either modules connected, it works! As long as the main module stays connected, I can even detach one unit. Just when I unplug the cable, it stops working again. This is not the case with any other USB controller or synth connected to mioXL via USB. So, it must be something that makes it not work as other generic midi devices. All of these do connect to mioXL - either during boot up of the unit or plag and play!
I think I have pretty much nailed it down to something that must give a good clue to what the actual reason is. Please tell me, when you have an idea what it could be and feel free to ask in case you need any more details.
These reproduction steps will narrow in what the issue might be. I have to fix some unrelated stability issues on the older SAMD51 based firmware and then I will take a look and try to fix this USB problem.
It seems like the new version of Grid fixed my issue with connecting to my iconnectivity interface. I just wanted to let you know it worked. Thank you!
Now, the only thing I miss is an easy way to revert to an older version of the Grid software and firmware. Currently, that does not seem to be possible without much hassle. I really don’t like that, because it means, anytime that I want to change something on the devices, I will be afraid to do it! When a new version causes a problem, I will have to wait for a fixed version and that means I cannot change anything about my setup during a project without being in danger to screw up my setup. The midi controller is just a part of the template that is to important to allow the possibility of loosing it temporarily. I MUST work. Can you follow my reasoning?
I really don’t understand why you want to prevent users from using an older version … or actually I do! You must fear for them calling for help, just because they forgot to update to the latest version. I get that! But I think the way you do it is a bit prohibitive and hence counterproductive. Couldn’t you just implement an option to revert to the last version (or any version the used needs)? That would be great! And I would feel much safer to change my setup!
So we had couple intense back and forth about handling the updates to Intech Studio products.
Currently the Editor has no way of “allowing” users to revert to previous firmware OR Editor version. Editor only has a firmware version check which checks if the connected module’s firmware is at least on the required version, but it doesn’t check if that firmware is 4 versions ahead to Editor and might have some sort of incompatibility. Each Editor version has this firmware check flag burned in during build.
We decided to name Editor as the hub of updates. Some of the steps we plan to make these steps:
Unforce Editor’s auto-update
Allow the customer to stay on a Editor version combined with suggested firmware version which is perceived as stable
Set the suggested firmware versions remotely for different Editor versions and not burned in during build
Emphasise more that the modules should be on the same version (whatever the version is)
Add info popup on new software available - but again stop enforcement
Introduce alpha channel builds for users who are open to participate in auto-updates and experimental features
Why we enforce(d) updates:
Since the change to ESP-32 MCU and announcing last year Q4 that we want to expand the character limit of Grid modules (better low level memory management) and want to get to the bottom of the midi rx stability issues (improved Grid networking), we uncovered quite some technical dept in the firmware codebase. Before we were able to progress meaningfully with any of the impactful topics - which essentially the users want -, those technical concerns had to be solved.
Solving them did not happen overnight and it occurred more than once that some issues became obvious after we could gather reproducible user reports on them. You can be only certain if something does or doesn’t work when you release it. Some problems were apparent with specific module combinations, some with x+ number of units and so on. Throughout this development phase we relied on the user base heavily.
This approach to development although quickened the release cycle, became burning as well with the growing user base and the totally valid assumptions that an instrument at this price range should be a reliable tool for work.
We were way too “statuppy” in attitude towards customers. I don’t regret it, because the product became better for the long run, but day-to-day I understand this could have been an annoying experience.
Anyways, this is an outline what we’ve been thinking of and how we approached software development lately. More to come during and after superbooth24!
You must fear for them calling for help, just because they forgot to update to the latest version. I get that! But I think the way you do it is a bit prohibitive and hence counterproductive. Couldn’t you just implement an option to revert to the last version (or any version the used needs)? That would be great! And I would feel much safer to change my setup!