Home | ER-101 | ER-102 | ER-301 | Wiki | Contact

Internal triggers, etc


#1

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:


#2

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.


#3

thanks @kel!

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


#4

Picking up on this again. Even in @kel 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:


#5

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:


#6

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:


#7

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.


#8

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


#9

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!


#10

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


#11

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%…


#12

yes! your version gives definitely more control :slight_smile:


#13

I’ll try both tonight!

:slight_smile:


#14

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


#15

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


#16

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!


#17

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


#18

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.


#19

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

thanks! :slight_smile:


#20

yes, it works! thanks!! :slight_smile: