Internal triggers, etc

Hi everyone,

I wonder if these two things (or similar workarounds) are currently possibe with the available units:

  1. generating a internal trigger when a cv change is detected. This is a common feature on quantizer modules and it would be very useful to trigger events elsewhere in the system.

  2. generating random gates/triggers. in modules like AD Octocontroller this can also be quantized to a clock.

thanks! :slight_smile:

1 Like

I got something like this working with this custom unit:

It’s a bit twitchy, but it’s possible to get it set up right and working.

There may well a better way to achieve this now, I am unsure at the moment.

thanks @anon83620728!

it would be cool to have some dedicated unit for this. hope Brian thinks the same. :slight_smile:

Picking up on this again. Even in @anon83620728 suggestion is valuable it’s still a workaround for something is clearly useful. So, @odevices I wonder if it would it be possible to add the following units to a future firmware revision:

  • trigger generator when a cv change is detected. This is a common feature on quantizer modules and it would be very useful to trigger events elsewhere in the system. Especially useful for generative patches.

  • random gates/triggers generator. in modules like AD Octocontroller this can also be quantized to a clock. Also very useful for generative patches.

Sorry for bugging! :slight_smile:

I think you can already do the random gates/triggers thing. Try velvet noise->skewed sin->limiter.

  • Set the rate on velvet noise.
  • If you want to sync to some other clock then use pulse to hz unit to convert in your clock input in velvet noise’s rate subchain
  • Use threshold on the skewed sin to adjust the probability.
  • Use time on the skewed sine envelope to set trigger/gate width.
  • Crank the pre-gain on the limiter way up to square the output signal off.

+1 on the CV change detector. That would be really useful. I could see it working nicely in conjunction with this idea:

1 Like

Great @Joe. I’ll try that! :slight_smile: Still maybe a dedicated unit could save us from using 3 units (4 with the pulse to hz) and save some CPU along the way.

And thanks for the +1. Hopefully @odevices is into it! :smiley:

1 Like

Seems like the clocked random gate unit would make a good first middle layer project for someone who wants to learn it since the needed c++ components already seem to be there, and there aren’t too many objects to patch up in Lua to make it work.

I have absolutely no understanding of c++ or any kind of programming, otherwise I’d gladly do it!

1 Like

Oh, sure, I totally understand that not everyone with an ER-301 is going to have a coding background. I may try to build this unit if no one else does - it does sound pretty useful. Just thought I’d plant the seed for anyone who’s reading and feeling adventurous. It’s feeling a little lonely in the land of the middle layer. Any takers out there? :slight_smile:

I guess I’m also thinking that @odevices has given us the tools to build some things like this so that he doesn’t have to build all the units that will ever be. I know I’m looking forward to him getting the time to build some of his blue sky creations at some point!

1 Like

clocked random triggers:
i think you can do it a bit more easily with just velvet noise (low frequency) followed by quantize to clock fed with a steady clock from outside or an internal clock generator.
edit: just tried it, it seems to work flawlessly

1 Like

That’s great, @hyena! Hadn’t thought of that and I dig the simplicity of it! So what you’d lose out on as compared to the other solution is control over probability and the gate length, right?

Actually I wasn’t in front of my 301 yesterday. The chain I posted above doesn’t quite work. So change that to:

White Noise -> S&H -> Skewed Sin Env -> Limiter
Internal or external clock into S&H input.

Skewed Sin threshold at 0 gives (I think) 50% probability, and increasing it lowers the probability. Skewed sin duration is the (modulatable) gate length control. Wonder if there would be a way to get the probability above 50%…

3 Likes

yes! your version gives definitely more control :slight_smile:

1 Like

I’ll try both tonight!

:slight_smile:

I added yours to the wiki under patch recipes. Would be nice to try to keep this up to date.

http://wiki.orthogonaldevices.com/index.php/ER-301/Patch_Recipes#CV_patches

1 Like

maybe you should add yours as well so we can have a version with more control. :wink:

1 Like

thanks @Joe and i agree with @eremitalf , both versions will also show how one can reach the same goal with different approaches on the er-301!

Hi @Joe, does your motion detector unit solve this?

I was hoping you’d tell me. :slight_smile: I’ve tested it very minimally at this point. Maybe try it out for whatever you had in mind. I’m willing to try to tweak and improve it if you find a use case where it doesn’t work.

1 Like

I will! Holidays from tomorrow onwards. I’ll report!

thanks! :slight_smile:

yes, it works! thanks!! :slight_smile:

1 Like