[LOGGED] Envelope Generator Loop Function

bonemap

Envelope Generator to trigger itself

I would say from my perspective allowing the Envelope Generators to trigger themselves in a loop would be great. Particularly in the case when using multiple one/end steps in the actor. Many times the Envelope Generators needs to be reset to start again in wait for the next trigger. The most obvious indicator for this is the actors own end trigger.

When using any kind of control for levels using a looping envelope generator appears to be a good solution for moving a current level back as an input into the actor as the first parameter for the next loop of the generator. When using this method for light channels or RGB leds for example having to program an extra step to reset the Envelope Generators does add a lot of additional work and take up a lot of additional space in patch.

Many years ago the Envelope Generator was able to loop back from an end trigger. I had a whole system for running DMX fade with that. So I can understand the frustration of the extra effort that is now required.

Kind Regards

Russell

mark

@bonemap said:

Many years ago the Envelope Generator was able to loop back from an end trigger.

Whaaaaaa? Backwards you mean?

Best Wishes,
Mark

bonemap

@mark said:

Backwards you mean

HI @Mark,

Thats interesting but, I didn't mean the generator running backwards backwards. But does this patch help to explain? Beta version.channel level catcher.izz

mark

@bonemap said:

But does this patch help to explain?

Are you referring to the execution order of the inputs here? I.e., the fact that the trigger is above the values, so you need a trigger delay to the 'trigger' input to ensure the values are recognized before the envelope starts?

Best Wishes,
Mark

bonemap

@mark

I don’t know why it is hard to articulate, but let me give it a go....

Let’s think of a scenario where we want to use a an Envelope Generator as an interactive fader for a series of level changes in the range 1-255.

In this example the default two value inputs of the Envelope Generator are used : value 0 and value 1. The value 0 is initialised at 0 and the value 1 has the first level value we want to arrive at for the first fade event. At the end of each fade event the most recent end value needs to be returned as a value to the value 0 input of the Envelope generator. A new value 1 amount can then be set ready to trigger and a smooth continuity between output levels can be attained.

First fade event:

Value 0: 0

Value 1: 127

Second fade event:

Value 0: 127

Value 1: 200

Third fade event:

Value 0: 200

Value 1: 50

And so on....

Using the end trigger of the Envelope Generator to directly action the loop parsing of the most recent end value to the value 0 input to become the start value ready for the next fade event action would reduce the necessity of using other actors (like the broadcaster and listener actors demonstrated in my previous post).

Kind Regards

Russell

jfg

@bonemap

if I really understand what you want you can make it with less actors and use a macro or user actor to repeat it. But you know it.I don't understand either why we need a loop or do you mean the possibility to conect the output directly with the value 0 or value 1 ?

best

Jean-François

bonemap

@jfg said:

macro or user actor

Thanks for your advice, that’s helpful.

Best wishes

Russell

Reinhard

@bonemap

If I get this right - isn't a 'Value Delay Line' the most simple solution?

value delay fader.izz

bonemap

@reinhard said:

Value Delay Line

Ah yes, that is a good solution thanks for sharing!

Warm Regards

Russell

jtoenjes

I’m sorry I didn’t realize there were so many replies to this feature request from so long ago. But this really was a simple request to have the envelope generator reach the end of its envelope and then restart right away in a loop. I have to insert a delay between the end trigger and the start trigger otherwise it fails. It really is a “simple” request (but maybe not “easy” to program into the actor?)

DusX

@jtoenjes said:

I have to insert a delay between the end trigger and the start trigger otherwise it fails.

This is due to Isadora automatically limiting feedback loops. This feature helps with stability and performance, especially during the build process where 'bad' loops might be introduced while experimenting. A delay of 0.001 wont effect the timing of the patch running, but it will tell Isadora that the loop is being managed.

jtoenjes

@dusx thanks. I guess I'll just make a user actor then.