V0.2.x-stable: Thank you!

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…

Definitely noticed that previewing samples sounds grainy AF compared to normal playback. Not a subtle difference.

Okay! I finally reproduced and found the auditioning bug (knock on wood). :tada: Apologies for the delay, it was a hairy one. Many thanks to everyone who stepped up and provided detailed bug reports!

v0.2.8 CHANGES

FIXED: Occasional crash during WAV file auditioning (due to race condition).


Weird thing: 2.7 was giving me a bitcrushing effect on samples that were pitched lower. Seems resolved in 2.8, but I thought I’d mention it anyhow.

many thanks on the updates Brian, I’m glad I could contribute to your amazing work somehow!

Thanks for the fix Brian !