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.
- 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). Apologies for the delay, it was a hairy one. Many thanks to everyone who stepped up and provided detailed bug reports!
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 !
Screenshots are working now! This will help speed up documentation writing immensely. Might even help with bug reports?
- ENHANCED: Take a screenshot anytime using SHIFT+CANCEL. Images are saved to the ER-301/sc/screenshots folder.
JK. Pretty sweet, though.
v2.9 @ 48K
Different thread, but someone was asking about chorus so I thought I’d try building a weird variation by slowly modulating the start time of 2 Grains units.
Basically a shared buffer situation with one writing to it, others (grains) reading from it.
Either a live feed from an input to a Looper or Sample player feeding a looper with a 200ms buf1 file.
Chain feeding out1:
- Grains unit assigned to buf1. Trigger: [SIN @ 25Hz] Start [.5 bias 1.0 gain - 1Hz SIN unit] Duration: 100ms
- Grains unit assigned to buf1. Trigger: [SIN @ 25Hz] Start [.5 bias 1.0 gain - .295Hz SIN unit] Duration: 100ms
I’m hearing sporadic audio glitches - almost like a resampling / bitcrushy sorta sound. CPU usage is hovering around 25%.
Tests that didn’t appear to make a difference:
-numerous looper fade settings
-grain trigger speeds
-tried larger buffer lengths (i.e.: 1 second) Glitches less but it’s still there
-makes no difference if these mixers are within a custom unit or sitting on a primary track/chain
If I punch the looper out of record so it’s only looping the audio in the buffer, the glitches stop. So it would appear to have to do with writing to the buffer while others are reading from the same file simultaneously. I’ve previously used this shared method to manipulate incoming audio and it’s been pretty solid. Has something changed? The Last OS I had on the 301 before getting back from vacation was v0.2.5
I have a short little video of the sound if that helps?
Unrelated Custom Unit Bug:
It would appear Bypass still doesn’t work for units sitting on the main chain level of a custom unit, but works for units sitting within a mixer within the same custom unit.
I found a funny bug last night. Reassigning the same sample multiple times seems to lower its amplitude in the Manual Grains unit. I haven’t investigated the other samplers.
-Create a Manual Grains unit.
-Add only one sample to the pool. (You can add more, but this is easier for testing)
-Assign the sample to the MG unit.
-At this point, I had a 16-20 Hz clock triggering the MG unit.
-Open the Assign Sample screen, and select the sample that is already being triggered.
-Repeat multiple times. The perceived amplitude of the audio should decrease each time.
Thank you, @trickyflemming. Bug confirmed. It appears that when one reassigns a sample to Manual Grains not all of the active grains are properly retired and recycled into the pool of free grains. This tricks the Manual Grains unit into thinking that more grains are active than there are in actuality thus causing gain compensation to under-compensate. Anyway, this will be fixed in the next release.
Thank you @NeilParfitt. I’m looking into this one but don’t expect a quick fix because it is likely to be quite a complicated fix. The glitches that you are hearing is almost certainly the granularization of the discontinuity caused by the Looper’s record head in the audio buffer. Each unit process its audio sequentially and in blocks, which would imply that in certain scenarios a play head and a record head pointing to the same buffer but controlled by different units might end up playing leapfrog.
Gnarly!!! God luck with that one