V0.3.x Firmware Workout: Better late than never

[Drony]

Hi!
I love the new version, great work!

I don’t know if this has been suggested, but i love to have some kind of visual feedback to know if the state of the proyect (quicksave i mean) is saved or not, like a dot or a * somewhere in the screen. Maybe something like the eventide H9 or the beatstep pro. If you make a change, the screen shows a indication, when you save the new state the indication dissapear.

Sorry for my English, I hope it makes sense.
Greetings.

[NeilParfitt]

Hi Brian!

I’m frequently messing myself up with the button release triggering the unit’s menu item on the same key…

- YouTube

Then again… maybe its…

The fingers you have used to dial are too fat

[korb]

I can confirm this issue

[sixnon]

And i am experiencing it also.

[odevices]

@trickyflemming

Another really nice One Shot option would be velocity. It would only read the velocity upon a trigger and keep the sample at that amplitude until the next trigger. This would save a lot of patching and would lead to easy articulations without worrying about amplitude-jump discontinuities when S+Hing the output VCA.

How about a unit that measures the amplitude of a trigger so you can use it to control whatever you want? Pulse to Height? It would wait for a trigger, observe the maximum voltage peak during the trigger and then hold that value until the next trigger.

[anon83620728]

Very late to the party, but also much appreciation and gratitude from me - this is a fantastic update

[trickyflemming]

@odevices

How about a unit that measures the amplitude of a trigger so you can use it to control whatever you want? Pulse to Height? It would wait for a trigger, observe the maximum voltage peak during the trigger and then hold that value until the next trigger.

I might be wrong but–from what I can tell–I think that will make things more complicated for sample amplitude articulation.

By introducing a Pulse to Height unit, there are a few complications:

1. Most clock/gate/trigger sources output uniform timing signals, so you would need to use an additional VCA to add amplitude variation to that stream. This is more complicated than the current strategy
2. A bottom threshold would need to be established. This is the voltage where the Pulse to Height unit would still detect a trigger, but it would be represented as 0 V. This makes setting up the Velocity CV more finicky.
3. This Pulse to Height would still be used to then modulate a VCA after the sampler. This can cause clicks on simpler samples if the timing isn’t correct. If the sampler has reset interpolation (i.e. a crossfade to prevent retrigger clicks), the trigger and the velocity signal shouldn’t necessarily be sent at the same time. One workaround is to add yet another unit before the VCA: a slew limiter.

Here’s what I mean:

[cosmicsoundexplorer]

Ive got the same issue

[korb]

@odevices

wait for a trigger, observe the maximum voltage peak during the trigger and then hold

I think the time is ready for a window comparator unit

[Julian_Edwardes]

I’ve noticed that when grain stretch and Looper are sharing the same buffer, Grain Stretch doesn’t visually update it’s window. Though you can hear the changes which means it’s indeed following along nicely, visual feedback in Grain Stretch shows a waveform that is a momentary grab of the buffer.
I have used slice on grid in the Grain Stretch unit, so perhaps it has something to do with this ?

[bc3]

Yes, I have noticed this behavior as well when sharing the same buffer across both units. If you “slice on onset” and are feeding the buffer with new material does the 301 keep scanning the incoming audio and readjust slices in realtime? Not sure if this is possible but would be really cool if it could

[phonk]

Preamps! Thank you Brian!

[tomk]

@Julian_Edwardes

I’ve noticed that when grain stretch and Looper are sharing the same buffer, Grain Stretch doesn’t visually update it’s window.

This is a known issue that has been the case with shared audio buffers across multiple sample players: ER-301/Tracker - O|D Wiki - would be great to see this fix implemented at Brian’s earliest convenience

[sixnon]

I did find this and, probably inappropriately, opened another thread ER-301 Buffer render bug? - #5 by sixnon , but I must concur with @Julian_Edwardes that it’s specifically noticeable with Grain Stretch, as I’d never come across it in V0.2.x. It did raise questions for me about slicing akin to those of @bc3. Where do the slices reside? Are they fixed at initial slice in the window of the buffer/sample size, or dynamic?

[sixnon]

Excellent, no?

[phonk]

Yess! Totally awesome.

[miminashi]

Finally got around to updating and I have to say, I am liking the changes.

However, I’m experiencing an issue where the inputs become unresponsive and a power cycle is required to bring them back to life. It happened most recently with a gate input triggering a sample player, but it may have also happened with the audio inputs, as well.

If I can come up with a solid reproducer I’ll post it, but I was just mucking around so I wasn’t in debug mode. This was with 0.3.02 96kHz, by the way.