V0.2.x-stable: Thank you!

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.


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!

i feel like I’m going through ER-301 withdrawal as I’m been away for a few weeks and my Walforf KB37 is too big for luggage! :frowning:


Coincidentally, I’m going through Neil Parfitt ER-301 video withdrawal.


I have a weird one: my samples sound different when auditioned vs. when they are loaded into the Sample Player. The auditioned samples sound a lot crispier and brighter, while the Sample Player sounds like it has a low-pass filter thrown on it by comparison.

I’m using the 48kHz firmware. The sample itself is 44.1kHz.

EDIT: Stereo sample. Stereo track. Channels 1+2.

I’ll take a look of course but that’s very surprising because the auditioning uses the same resampling algorithm as the Sample Player. Do you have a particular sample where the difference is very obvious?

Thanks! Just PM’d you a sample that I’m working on.


It turned out that @trickyflemming did catch an error in the resampling code! Sorry about that everyone. It looks like when I refactored the resampling code (around the time I introduced the file auditioning) I introduced an error that caused the resampling kernel to be reversed in some cases. Your samples should have more presence in the upper ranges now.

v0.2.7 CHANGES

  • FIXED: Error in resampling code causing some high frequency content to be attenuated. Sample Player, Manual Grains, and Pitch-shifting Delay should sound slightly brighter now.

I have random freezes when auditioning certain files : when I am scrolling an auditioning and I play a certain file, the ER-301 freezes to see what I mean download this samplepack : http://radek-rudnicki.net/immortal-waves/

I just got it frozen with the wav file : MG12.wav

Also got the audition crash on 0.2.7.

Auditioned looped single cycle sample, press stop and then 301 freezes, also crashes when moving between samples and auditioning (e.g. without pressing stop first)

The card IO light is flashing very fast, could it be that it is to do with very small samples. Seems to behave much better with one shot drum samples etc.

Audition crash here too on 0.2.7.

Auditioned some highhat samples, while looping two sample players with drum sounds. After auditioning around 10 to 15 hh samples the 301 froze…