Hard time understanding quantizing on the Erae II

Erae Touch & Erae 2
1

I can’t get a handle on how quantizing operates on the Erae II. I got a response from Embodme saying that it actually quantizes your gestures while you record. But it doesn’t seem to do that and it doesn’t seem to affect it on playback. In the online manual, it says:

" Looper
The Looper’s Quantize setting controls the timing grid applied to recorded note-on and note-off events. Available values are:
Off, 1/4, 1/8, 1/16, or 1/32
Quantization is applied non-destructively during playback, so the original performance timing is preserved. For example, recording with Quantize Off keeps natural timing; selecting 1/16 afterward tightens playback to sixteenth notes without rerecording."

I tried recording with it off and then applying it after and it had zero affect.
And I also tried the way Embodme says to do it and it didn’t work as I would expect during record either.

Which implies to me that you record your raw gestures, then can quantize however you want afterward. This is the behavior I’m most used to.

Would love if someone could clarify how this works. Thank you!

2

I’m pretty sure when I last used this, (looper) quantise was indeed non-destructive,
i.e. it did it on playback (only) , so you could switch it on/off.

I can’t say Ive tried recently - you mentioned it was broken before? and now (potentially) fixed in beta?

i.e. would I need to load the beta to try? (can I roll back to release after?)
(I dont really want to get too deep into another dev/testing project ;))

1 Like
3

Yeh, I can understand that! Not sure if you can roll back. I was wondering the same thing. I’m pretty sure its either broken or they have changed how it works and not updated the manual. Though in my mind, I can’t reason how it would make sense to have the recordings be destructively quantized. IMO you have the best of both worlds having it act at the output. Can’t wait til they get all this sorted out!

BTW, I couldn’t get it to work as expected in Arp mode either. Not sure what version you are using, but I think it’s been broken for awhile, maybe since the last “stable” release.

4

ok, so I decided to test again on released firmware.
(to refresh my memory)

Arp works as expected.
Loop was not quantising - either for recorded or playback

I also tried with loop just being a ‘bit off time’, thinking perhaps there may be some ‘maximum quantisation’ going on e,g a max of 1/4 note (or 1/16).
(i.e. a more realistic use-case that trying to be a full 1/4th out)
no change :wink:

yeah, not much reason to destructively quantise these days… its really just a cpu saving technique, also arguably slightly less complex as there are ‘edge cases’ when quantising esp if you have overdub.

note: in other scenarios, not this one, you can also reduce storage (ram etc) if you are able to coalesce events - but that’d be really uncommon in a musical looper.

again, im pretty sure it was quantised on playback when it was working, as I would have compared functionality to documentation and this has not been ‘updated’. also, Id have asked same question - why?
perhaps they are confusing arp and looper?! or just support were wrong.

less likely, they found a bug due to above edge cases mentioned, and the quick fix was quantise on record…

anyway, as it doesnt work (release build) its just speculation, as neither work, we’d need to see a working version :slight_smile:

1 Like
5

ok, curiosity killed the … I couldn’t help myself, installed beta.

quantise behaviour is identical, arp works, loop does not.

I also reviewed change log for beta (vs release), there’s no mention of quantisation being fixed (or really looper being touched)

id suspect if you were told it was fixed, someone has got confused… happens between support and dev quite often :wink:

2 Likes
6

Is it possible to mention these results on the Discord server? I feel like embodme was discounting my experience and it would help to have a couple voices :slight_smile:
Thanks for testing it there!

7

Better is to report thru ERAE Lab :wink:

1 Like
8

Done…

note:
I think you are ‘confusing’ matters talking about recording arps (id remove that)…
simply because arp quantisation is different from looper quantisation.

for sure Looper + Arp is an ‘interesting combination’ , but frankly, Id have two separate reports (but wait for looper to be functional first.
so…

a) Arp
b) Looper
c) Arp + Looper

frankly if designed properly c , should not be a special case… a and b should cover it.

@keymanpal - from what I remember @gkillmaster has already reported this months ago, both in Erae Lab and forum. I also said on forum I could reproduce… so they are aware :wink:

given theres no mention of it in beta change log, Id say, it just an existing bug thats not been handled… (regardless of what support said ;))

1 Like
9

Ok, I think I understand what you are saying about the arp, But arp quantization should be applied to the arp function even when you are not recording gestures, right?

10

yes… in theory, (there is a but… :wink: ) what should happen is…
loop records the base chord, then the arp is post fx.

you’d then expect the loop to sync the chord (first), then the arp is naturally sync’d,
then in theory, the arp would also sync… but you’d only notice this if the arp quant was coarser than the loop quantisation.
e.g. the loop quantisation is 1/16, then the arp quant is 1/4.
(the other way around, then loop would ‘correctly’ take priority)

(reminder, obvious i know, you only quant the start on arp, as ‘rate’ is a perfect offset for other notes)

BUT…
that said, it would be ‘reasonable’ for dev/design to say,
having two quantisations being used like this is ‘confusing’ for users… so lets just use the loop, and not bother quantising arp start, just work off the loop quant.
sometimes, you often trade flexibility for simplicity. (also reduces cpu a tiny bit)

Id say this is the likely case…

ofc, it could also be…
either their design doesn’t allow for it, its not a sequencer with lots of fx chains (like say squarp hapax), so may be a simple design.
that said
a) some of them come from Squarp so are aware of the design
b) i think they way they do this is likely surface -(input) > loop/sequencer (processor) → arp (fx) → output … so simple but covers what they need.

but again, all speculation
but hopefully, its just the fact the loop quantisation is broken, and the arp doesn’t generally quantise from loop for ‘simplicity’, so fix the loop and all is good :wink:

1 Like
11

I did that as well….

2 Likes
12

Your reasoning is so reasonable!

1 Like
13

New support reply from Embodme:

"You are completely right, and thank you for catching that. The manual does document non-destructive playback quantization, and our previous reply was wrong to contradict it.

In firmware 2.0.83, the looper currently only quantizes gesture starts at record time instead of adjusting playback timing as documented. There is also an issue in this version where the quantize grid reverts to 1/4 upon reboot or project reload, which likely explains why recording with a grid did not behave as expected.

We have escalated this discrepancy directly to the development team to align the firmware with the manual. Does setting the grid right before recording help keep the notes in line for now, or are they still falling off the grid?"

3 Likes
14

Just got another one :slight_smile:

“Hi,
Working on it, new firmware coming up this week.
Best,
Edgar”

3 Likes
15

cool - great to seem them following up on this… and also other items on the discord,
definitely a positive sign…

hmm, Im not sure the explanation really covers what Im seeing for a couple of reasons
a) quantisting at record time or playback ,
would still mean the end result is a quantised result.
b) quantize grid reverts to 1/4
you’d still see quantisation, but it’d be on an incorrect boundary !

that said, if they are actively working on it. then it’ll at least get dev testing, so they will notice discrepancies then AND if they make changes and release as beta, we can report its still not working and ‘expect’ a fix before release :crossed_fingers:

1 Like