Problem with primary initialization

I dont know where exactly is the problem, i only know that its in the macro of the screen.

The problem is that each time the ensemble initialize, the value of the multipicture reset to zero. I have several multipicture using the same structure, all of them have the same problem and i have no idea how to solve it

Help?

 

Without too much analysis, my guess is that you need an Order module for the Sel input.

The second and third outputs of the Order module don't pass the init events.

If this is correct, it is a problem I run into often as well.

 

just a guess, but it seems like the MX would initialize to 0 and then feed the snap value. normally that wouldn't effect anything but since you have it in an event loop it seems troublesome to me really.

i generally use a mouse area to control a multi picture.

 

Use an event merge module, connect a constant to which you want to initialize the output on the first port.

 

If that is the problem, then an 'initFilter' type core module between the MX out and the snap value input might fix it.

@nox:
It's really difficult for anyone to help unless you post a downloadable working example that displays the problem. The pic you posted doesn't include important stuff like preferences settings for various modules etc. Even if it did, we would have to build it from scratch ourselves to even start helping. All we can do with a pic is make guesses.
Please take the trouble to post an example ensemble.

cheers

Col
---

I think he is trying to have the snap value load on initialization, not a constant default value.
---

Does it only happen on 'power up', or does it also happen during a reset (like when you throw a primary level switch)?

 

Arachnaut, i have tried the order module solution, it dident work Tks anyway

Salamander, i have considered what youre talking about, the mx sending an event at initialization, but if i understand correctly the module shouldnt do that... am i wrong?

Lhaymehr, i have used the merge workaround in other ensembles, but in my experience it can be a problem itself when you have several modules (including the constant) sending events at init. Id prefer to solve the problem correctly this time, and learn something from it

ColB

Thats totally right, i was tired and frustrated ... ill try to upload something when i reach home... and connect it all to a eventwatcher to try to determine wich output exactly send the init event

Yeah, that was the idea. I thought the snap value would send an event at init

It happens when open the ensemble and when switch on/off the "reaktor power button" (you know, top right button near the sample rate, dont know how it calls in english). I havent try it with a normal primary switch, but i think its the same that the "power button"?

 

where does the inport come from: audio or event?, constant, fader ?
snap value properties: events thru activated or deactivated?

ciao herw

 

Just had a thought: when you say "the value of the multi-picture resets to zero" do you mean the value at the MX output?
If so then that makes sense as that's just the mouse x position, so it would naturally default until you press the mouse button somewhere in the multi-picture. It couldn't really work any other way.

Or do you mean the picture resets to the first picture?

How is it that you want this to work? what does it do?
---
After some experiments, I'm assuming that you are talking about the MX output reverting to a default zero value.

If this is the case, then all you should need to do is instead of connecting the MX out to the mult (by 3), connect the output of the snap value to the mult.
This way, snapshots will work, and an on/off cycle won't cause a default to zero.

 

I have test the ColB solution but it does strange things

I have uploaded the whole ensemble (without samples, sorry but it goes to 175 Mbs ) and a picture which ilustrate what happen when press button/load the ensemble. The multiply (by 3) is connected to the third eventwatcher input (red), the other input is connected to nothing

Btw, herw, the in port comes from an event corecell which distribute the Chan. Message module outputs, but i have disconnected it and have the same problem.
The snap Events Thru is activated.

Im really confused with this.

 

..and check the default value of Snap Value module. Also picture value ranges.

 

I tried my suggestion, and it seems to work, although it's hard to know for sure with no samples, and not knowing exactly what this machine is supposed to do .
It certainly allowed on/off without the 'wave' bar being reset.

Anyhow, fwiw, I had to strip out the event watcher as that was introducing it's own initialisation problems.

See if the attached edit works, if it doesn't, try to explain in more detail what it should be doing that it isn't, and what it shouldn't be doing that it is!

 

OK, I'm getting sounds now (didn't realise at first that it responds to midi keys ).

I went through and applied the 'fix' to the other bars, and now it seems a bit better in terms of snap save and recall.

Where do I load samples to and how are they intended to be used?

Col

 

Yeah, it have a transparent XY in top of the sampler to select the loop (copied from metaphysical ), you can load the samples clicking the sampler top bar.

The idea is to play a note/s, press sustain and tweak. Its basically a personal toy/experiment with feedback and reducing controls: it have FM, a multimode filter, delay, sample, wave and feedback, but only one control each.

The FM and the feedback affects all the other effects: FM with filter cutoff, delay time, wave freq and sample freq; FEEDBACK with the filter, delay, FM modulators and ensemble output.
So you have a comb filter, a resonator, multimode, self oscilator filter, sample and wave mixer both with FM and feedback, all with 6 controls (7 with the sample select).

Testing your solution ColB.
---

Yes! It works... i dont know what was i making wrong when i tried it the last time, but it work now!

Tks you all guys!

 

Excellent.

I did two things to all of the control bar sections
#1 use the output of the snap instead of the MX output of the multi picture
This is the fix. The MX output of the multi-picture is for the mouse position, so after an off/on cycle it doesn't make sense for it to retain a value. I don't think it sends an event on initialization, so it won't 'send' a zero value event to the snap value, but when you read from it you get zero. The snap value attached to the MX output retains the last MX value, and is maintained through reset events, so using it (in thru mode) solves the problems you were having.

#2 I switched the snap value modules to 'always active'. I'm not sure if this makes a difference in this case, but I wouldn't want to take any chances, so I switch that on unless there is a very good reason not to.

The only other things were that I disconnected the event watcher - it is a complicated beast, and for that reason, it was easier to just unplug it rather than try to isolate the problem is was causing. And I created some instrument level snapshots (I don't think that would make a difference, but can't be 100% sure).
----------

It's an interesting creation - some cool edgy sounds possible. Definitely worth developing further IMO.

cheers

Col

 

#1 Makes sense, i didnt think about reading the MX, only test if it were sending anything. Im sure it was the problem.

I agree its interesting, the lack of controls limits the sounds you can achieve, but its fun to not worry about nothing, mapping the midi controller and tweak a few controls. Will see.

Tks

 

Could you please post this again? I'm having a similar problem and would like to see the fix.
I get the following error message when I try to use the link:
"This attachment cannot be shown at this time. Please try back later."

 

something seems to have screwed up all the old attachments. that's pretty awful.
here's a tutorial i made on fixing these types of errors.

http://www.adsrsounds.com/reaktor-tutorials/global-reset-events-in-reaktor/

 

to ColB: I love the way, after you have guided the user to a solution, you come back and summarise the steps it took to get there. Over 2 1/2 years later, what you wrote here solved my similar problem. Thanks! You are my new hero.

 

To Salamanderanagram: Thanks, that was vey helpful! I have a pretty straightforward instrument that has a similar problem (that didn't respond to your suggestions), so I am going to take you up on your offer and email it to you. Thanks!

I just discovered your site and am having a lot of fun learning from it.

 

cool i'll take a look!