Wishlist: Initialize event

A module that fires one trigger type event when an ensemble is loaded would be very helpful. This would let us set up the equivalent of a contructor method in OOP techniques.

At present I work around this problem using the Start/Stop module, but this is clunky and requires the user press the Play button in Reaktor to reinitalize the ensemble.

 

This can be done today if you're clever about it.

Contant[value=1].out -> SingleDelay.In
Constant[value=250].out -> SingleDalay.Dly
SingleDelay.Out -> Seperator.In
Seperator.Hi -> EventMerge -> Seperator.Thld
(that makes a feedback loop)
Seperator.Hi -> MacroOutput

...so basically you have 1 seperator module in there with the hi output both setting it's own threshold, and being the source for your initialization event.

On startup, the SingleDelay will fire a value of "1" 250ms after the ensemble starts (to give the whole thing time to settle down). At that time, the "Thld" input hasn't been initialized, so it has a value of zero. The "1" event coming from the EventDelay goes out the Hi output. This loops around and sets the Thld to "1", so future events that come out of the delay - something that will happen every time any switch on the pnael is pressed - will come out the "lo" output of the seperator.

Ah, I tested it so I might as well just post a picture (see below)

Note that while I think it's constructive to be offering ideas for new features, the Reaktor team obvious has lots of bug-fixing to do on the existing product. (A product that's already so complex and feature-rich that many people don't even know how to scratch the surface). That being the case, dont be disappointed if you don't see these suggestions appearing in the product any time soon.

- CList

 

I was thinking about this a bit more and thought I should mention that you could replace the 2 constants and the EventDelay with just any single positive-valued constant, and you'd have the same result (the event would fire on start-up, and come out the Hi side of the seperator, but then after that it would always get "blocked" because it would be sent out the "lo" side).

The problem with doing this is that you don't know *when* your constant will fire relative to all the other constants, and knobs, and eventdelays and things that will fire their variables. If you use the event delay, you can be sure the system has settled int it's proper state before you do the initialize event. Trade off is that it uses more CPU.

- CL

 

CList,
Thanks. I hadn't thought of this approach at all. I figured out a way to get around the need for an initialize in this particular case. In the course of it though, I toyed with your idea, and got something like it to work with event modules, namely two event hold modules and a separator. At least I think it worked--pretty hard to test something that only works on startup.

In any case, it would be nice to still have an initialize event, and your message about timing suggests it would be good to have a built in delay, say, so that all these modules could fire at a given time--although that sounds like it would be disruptive of the basic event loop code.

Rameau