Cherry Audio Forums

Topic subject, pretty much. Making the Randomized event fire before the controls are moved would allow things like saving the values of certain controls and setting a timer to reset them to the saved values to make it so some controls are exempt from randomisation, negating the need for custom "Randomize steps" buttons or menu items for sequencers, etc.

Alternatively, controls could get a new "Excempt from randomization" property, but I would think the former is a much more trivial change. Granted changing when the notification fires could break code depending on controls being randomised already when the event is handled, but I couldn't think of any scenario where that would be relevant, if anyone has something like that in their modules or can think of one, please do share!

I'd second this. More opportunities for us to intervene is always good.

I'd also like the randomize function to work correctly with slide switches. I have modules with two-way and three-way slide switches where the randomize function does not affect the two way switches at all and on the three way switches the randomize just selects one of the first two positions, never the third one. Maybe it's by design but it feels more like a bug.

Rather than changing the existing notification case, why not make it pre- and post- notifications, as several of the other notification types already do?

Reid

Hi, not to continue off-topic of the initial post, but I just wanted to mention that I submitted an official bug report on the switch randomization issue. I can't believe I didn't even notice this before, but it greatly affects a module I'm currently working on. And actually, it's worse for 2-state switches than "does nothing" -- it actually just sets the switch to its first state every time, no matter what! Anyway, thanks for mentioning that Aarnville!

Also, to be more on topic: I love the idea of pre and post notifications for Randomized and Reset!

JK