Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
MRCC won't boot, please help!!
#1
Hi,

My MRCC won't boot, it doesn't get past step 7 led, and it shows just the initial screen (v1.1.0.20)
I did try the new beta (v1.1.024) su uploading does work still, but same result.

What can I do next?

J*

UPDATE a 'hard' reset (using stand-by button and switch MRCC on) did the trick.
I lost all my presets though  Cry
Reply
#2
(07-11-2021, 11:45 AM)Joris Röling Wrote: Hi,

My MRCC won't boot, it doesn't get past step 7 led, and it shows just the initial screen (v1.1.0.20)
I did try the new beta (v1.1.024) su uploading does work still, but same result.

What can I do next?

J*

UPDATE a 'hard' reset (using stand-by button and switch MRCC on) did the trick.
I lost all my presets though  Cry

Sorry about that, for now that will be required for updates, fortunately it's pretty quick to set things up again. Wouldn't hurt to write down setup notes before updates.
Reply
#3
(07-11-2021, 05:39 PM)Jesse Johannesen Wrote:
(07-11-2021, 11:45 AM)Joris Röling Wrote: Hi,

My MRCC won't boot, it doesn't get past step 7 led, and it shows just the initial screen (v1.1.0.20)
I did try the new beta (v1.1.024) su uploading does work still, but same result.

What can I do next?

J*

UPDATE a 'hard' reset (using stand-by button and switch MRCC on) did the trick.
I lost all my presets though  Cry

Sorry about that, for now that will be required for updates, fortunately it's pretty quick to set things up again. Wouldn't hurt to write down setup notes before updates.

It took me more than an hour to get it back in shape.
As a setup can be pretty complex and can be build up progressively.
If 'saving' it regularly is not enough (as it seems), the option to backup a setup wouldn't hurt either.
Reply
#4
The idea I think is that at some point is will not be necessary, but I haven't got a clue what that means as far as how long until we get there or what it will require. I'll ask Steve to clarify that for me and report back.
Jesse
Reply
#5
(07-12-2021, 09:31 PM)Jesse Johannesen Wrote: The idea I think is that at some point is will not be necessary, but I haven't got a clue what that means as far as how long until we get there or what it will require. I'll ask Steve to clarify that for me and report back.
Jesse

I would think that once they stop changing the internal structures used to save data (due to adding features/capabilities/options that were not originally planned) then newer updates won't require a full memory wipe.  The alternative is to have the new OS read and reformat the saved data structures after an upgrade, but that can get complicated.

So it's simple - if the users keep asking for new capabilities, the configuration will keep getting cleared out each upgrade.  Users stop asking for stuff, the config stays stable.
You get kind of a negative feedback learning response taking place.

lol


probably the more realistic reason is that space is quite limited and there's simply not room to keep the old and new structures around while the OS does a conversion after an upgrade.
Reply
#6
Thanks for chiming in and give your honest opinion that it's the users continuous asking for stuff (like bug fixes) that causes al this!

Sure, changes in features will bring changes in internal structures. But that should be less of a concern to the general user IMHO.

It was my own 'fault' to use the beta firmware, which I wanted, as it solved a bug I suffered (Exclusive Channel Map did filter the clock).

Still think a way of backing up / migrating to new 'structures' would be nice. May be in software?
Reply
#7
(07-13-2021, 05:37 AM)Joris Röling Wrote: Thanks for chiming in and give your honest opinion that it's the users continuous asking for stuff (like bug fixes) that causes al this!

Sure, changes in features will bring changes in internal structures. But that should be less of a concern to the general user IMHO.

It was my own 'fault' to use the beta firmware, which I wanted, as it solved a bug I suffered (Exclusive Channel Map did filter the clock).

Still think a way of backing up / migrating to new 'structures' would be nice. May be in software?

Yes for sure.  I have been asking for either a remote editor or a sysex dump/restore feature since the beginning.  Be thankful you weren't in the early betas that also erased all your port names every update.    Angry

As a tradeoff - some of the new features added (like the new filtering/routing options) are wonderful and I'm willing to take the hit and re-do my setup to add those options.
Reply
#8
I totally understand the frustration at this, but to explain a little bit why this occurs, the issue stems from the fact that for every new feature there are a new set of bits that are added to the Save Slots, so in the case that an older version of a save is attempting to load, one of the bits may not be in the correct place, or missing altogether causing it to behave erratically in the best case, or refusing to boot in the worst case, requiring a memory re-flash. It may be possible to solve this issue, and I believe that is one of the goals I've heard mentioned, but I am still a little unclear on the method and timeline. Next time me and Steve talk I'll be sure to ask. In the mean time, another totally viable option is just use it as is and don't update until something comes around that is worth the extra bit of work it takes to get your setup back how you like it. (edit: I just re-read the post and realized this last suggestion doesn't apply here as in this case it solved the exclusive issue, sorry if that came off as tone-deaf.)
Jesse
Reply
#9
Gents, thanks for all your replies. I think I'll have to live with it for now, and on a positive note: I consider it a good way to develop some muscle-memory ?
Reply
#10
I do software development for a living and we often joke that it would be a lot easier to make stuff if we didn't have to worry about the customers.   Big Grin

The goal of forums like this and the discussions on them is to take an incredibly useful product (like the MRCC) and hopefully make it even better with some real-world feedback.
Sometimes you get really good suggestions that are easy to incorporate, sometimes you get dinged for areas you know are lacking and it's up to the development team to prioritize and address them.

For me, the MRCC has been a gamechanger in that I now can connect a lot of gear that previously sat unconnected or required cable swaps or additional adapters and such.
The filtering and rechanneling means that I have less on-the-fly configuration issues because the routings automatically take care of a lot of the hassles.  The addition of a clock and multiple arpeggiators is a great bonus.

The downside is that all of these things take some initial time to set up correctly.  My feeling is that folks looking to buy an MRCC have a need to explore/use these extended capabilities and are doing a lot more than simply setting up a set of 'route port X to port Y' connections.  Therefore, having to re-do a complex setup after an upgrade can really be a time sink, especially if you didn't write down all the tweaks you did to note ranges, channel numbers, order of MODs/Filters, etc. for every port/route in the MRCC.

Having the ability to dump and reload (via sysex) or even to have it dump in some human readable format (CSV, text, or (even though I despise it) JSON) would save users a lot of time and make updating much less painful.  If you were clever about the dump/load you could embed the current OS version in the dump and then the reload could check that, parse out what it needs, fill in the new bits with defaults and a user could be up and running quickly.
Reply


Forum Jump:


Users browsing this thread:
2 Guest(s)