V0.2.x-stable: Thank you!

It was a 5 second buffer.

Just managed to crash it clearing a chain, it was a looper placed before manual grains sharing the same buffer, 6 seconds i think it was.

I’m back and I will be looking at all of the recent reports in detail. Thank you everyone for these bug reports!

The timestamps on the 6-track recorder are not being created properly. Everything has “12/31/2013 11:00 PM” as the date created when loading the MicroSD card into my Windows 10 computer.

I also want to bring up a bug/feature request from 0.1.6: V0.1.6pre: volunteers needed:

Takes would be appreciated. More importantly, there shouldn’t be a “file saved!” message if nothing is saved/overwritten.

Unfortunately, there is no battery-backed clock on the ER-301 to generate accurate timestamps. Maybe on a future CPU board replacement!

Thank you for reminding me about this one!

1 Like

14 posts were split to a new topic: Sixnon’s Mysterious Crashes

I’m getting pretty consistent freezes with 2.5 when I switch from one saved Chain to another. They aren’t super-complicated chains. Just various a sampler, VCA, aDSR, etc…

I have a stereo chain setup on 1-2, that is just playing back a sample, and it always happens when I go to switch the chain on channel 3. I used to be able to swap chains on other channels while a sample played on the others…

Do you mean it freezes when you are loading a chain preset?

Yes. Also, it freezes when I just try to clear a chain preset. Displays message “Removing Units”…

1 Like

Yep, same here. It freezes up “removing units” when I try load a new quick save.

Hmm. It seems we have a bit of complicated problem here. I can’t seem to reproduce the problems that @bc3 and @dudadius have reported:

So far we have crashes when:

  • clearing or loading a chain
  • loading a quicksave (after renaming it?)

Does it happen all the time or just some times?
Does it depend on the preset or quicksave?

I just need to reproduce one crash here and then I can pounce on it like there is no tomorrow. So if you can describe the exact steps that reproduce it every time, that would help a lot. (That is assuming it is reproducible on demand.)

@cfunk, may I assume that “.wav library” means the Sample Pool? Also, does it happen every time in a reproducible manner? How many samples did you have loaded?

This one I was able to reproduce. :tada: I wonder if it is related to the other crashes…

This release definitely fixes @Chickenbone’s bug and it MIGHT also fix the @bc3 and @dudadius “Removing Units” bug.

v0.2.6 CHANGES

FIXED: Freeze when removing a triggering Manual Grain unit with an assigned buffer or sample that is short(ish).
ENHANCED: 6-track recorder will now append an auto-generated take number when saving to a folder that already contains previously saved audio tracks.
ENHANCED: 6-track recorder will use “save to file” semantics when there is one track to save, and, use “save to folder” semantics when there is more than one track to save.
NEW SETTING: Configure 6-track recorder save semantics for single tracks (default is file).

1 Like

2.6 Fixed the problem for me! Thanks!

Just to revisit: I could only get it to freeze when I would clear or delete a rather large saved chain. It would happen every time. I messaged you an example.

But again, I’m all good with 2.6!

Ok, 2.6 seems to have fixed the freeze up when switching between quick saves. Most all of my quick saves were using manual grain units, looper units, and sample players. Thanks Brian!

I have some general questions about the large amount of CPU usage I’m experiencing when using only a sample player and manual grains unit. I’m running the 96k firmware and the CPU is at 89%. Is this normal? I understand that the longer you set the duration in the manual grains player the higher the CPU usage will be but will this always be the case with these granular type units on the 301? Would running the 48K firmware help cut down on the CPU usage when using grain units? At this point in the firmware how many manual grain units are possible to have running before you start to hear the crackling from the CPU being over worked?

Yes! :sunglasses:

see edited post

If by normal, you mean it is not a bug then yes it is normal.

Hard to say because I will endeavor to continually improve things. For example, adding a parameter that lets you set the maximum grain polyphony (which is currently hard-coded to 16). Another example, is creating a more automated granular unit that can take advantage of extra information to optimize the grain synthesis. Manual grain synthesis will be the most expensive per grain because each grain is essentially a full sampler voice.

Yes.

Hard to say because this will depend on how many grains are overlapping (i.e. polyphony count).

1 Like

Understood and thanks for the further explanation about the manual grain units, makes more sense to me now about the CPU usage. I loaded the 48K firmware and will stay there moving forward I think.

Can’t wait to see where you take the granular unit as it has really opened up exploring “micro sound” on the 301. Thanks as always for all of your hard work!