Value gets stuck in the Core Macro
i'm still gaining experience with the core level and am stuck at what is probably a fundamental point again :-/. i'm using the AHDSR envelope from the library and trying to use different settings for "max AHD" e.g. "max R". there's a controller with the values 1-4 for this. this value is multiplied by 5000 within the scale macro in the envelope, so that the times 5s, 10s, 15s and 20s are available for "max AHD" and "max R".
the problem is within the scale macro and there within the "XFade macros". the max values arrive correctly in the "scale macro", are correctly multiplied by 5000, and also enter and leave the "ms2logT" macros correctly. then the values enter the various "XFade macros" (at input 1), arrive there correctly and are subtracted by 0 from the value at the input. so far everything is fine.
now the value runs through an xa+b macro before the XFade output. and it is precisely in this macro that the value is obviously no longer processed correctly. unless reactor is switched off and on again with Cmd+R, i.e. reinitialized. what has to happen in the xa+b modules so that the value is taken into account?
thanks in advance and regards,
bernd
Best Answer
-
The issue is within the crossfade as you realised.
those mod macros are set up so that only events at the x input will generate outputs.
but your maxAHD control sends its value to the '1' input which propagates to the a input inside the crossfade. The result is that when you update that parameter, nothing happens until the parameter at the 'x' input is updated… not ideal.
I wouldn't mess with the internals of the cross fade. Main reason is that you can sometimes fix one problem and cause another… so don't bury these types of fixes deep if you can avoid it!
The easiest option is to use the maxAHD event to fire the others A H and D inputs… for this you use an event mixer to combine e.g. the maxAHD with the A, then use that to latch the A input. Now whenever there is an even at the A input OR the maxAHD input, we get an update at the crossfade… the result will look something like:
I used quick busses rather than lots of wires to make it clearer.
I have not tested this - that's up to you ;-)
you probably want to apply the same fix to the 'max R' process as well if you are using that
There is a 'Xfade (mod)' macro that is almost right, but not… in that one, events at the 0 input are the driving events. What you need is the inverse.. events at 1 and x both driving the output. You could build that simply enough, but the example here should be equally efficient so…
(It really is with taking some time to work through this though. Learning to use latches and mod macros to control which events are driving the process and which are not is a significant part of building in core. e.g. if you did build an appropriate cross fade, you would need to upgrade that multiply (with the 5000 at the input) to be a mod multiply with the 5000 constant at the lower 'a' input. otherwise when the 5000 constant initialises, it will fire an event downstream through other stuff that might not be ready yet… mod macros keep things clean and tidy and do not cost any extra cpu.)
2
Answers
-
The key here is in the xa+b macro…any change in a or b will not get through until x sends an event…you can either replace the multiply and add with normal ones "not math mod" or you leave it as it is and force the value at Max AHD to send an event at X input…i often use a combination of merge and latch to do this,you then merge it with what is on the X. Not sure if this is an elegant solution but i often do this.
2 -
The issue is within the crossfade as you realised.
those mod macros are set up so that only events at the x input will generate outputs.
but your maxAHD control sends its value to the '1' input which propagates to the a input inside the crossfade. The result is that when you update that parameter, nothing happens until the parameter at the 'x' input is updated… not ideal.
I wouldn't mess with the internals of the cross fade. Main reason is that you can sometimes fix one problem and cause another… so don't bury these types of fixes deep if you can avoid it!
The easiest option is to use the maxAHD event to fire the others A H and D inputs… for this you use an event mixer to combine e.g. the maxAHD with the A, then use that to latch the A input. Now whenever there is an even at the A input OR the maxAHD input, we get an update at the crossfade… the result will look something like:
I used quick busses rather than lots of wires to make it clearer.
I have not tested this - that's up to you ;-)
you probably want to apply the same fix to the 'max R' process as well if you are using that
There is a 'Xfade (mod)' macro that is almost right, but not… in that one, events at the 0 input are the driving events. What you need is the inverse.. events at 1 and x both driving the output. You could build that simply enough, but the example here should be equally efficient so…
(It really is with taking some time to work through this though. Learning to use latches and mod macros to control which events are driving the process and which are not is a significant part of building in core. e.g. if you did build an appropriate cross fade, you would need to upgrade that multiply (with the 5000 at the input) to be a mod multiply with the 5000 constant at the lower 'a' input. otherwise when the 5000 constant initialises, it will fire an event downstream through other stuff that might not be ready yet… mod macros keep things clean and tidy and do not cost any extra cpu.)
2 -
Oh you just taught me how to use that event merge module!
I was never using it for some reason,as in my post above yours i was always using latch + normal merge. Not that big of a difference but yours makes more sense.
0 -
I took longer to write my explanation :)
I think the main difference with the merges is code readability - using an event merge makes it explicit that the value is not used. It is possible that it helps speed up compilation too, but probably not in a significant way except in very unusual circumstances.
1 -
thank you very much for the detailed explanation. it works wonderfully, i'm delighted!
the how and why and in which order events take place in core is not so easy to understand, especially since i don't deal with it every day. i spend most of my time teaching and doing print and web design. i can manage the primary of reaktor level very well, but core is a whole different world.
thank you again for the quick help and the good explanation.
0 -
You decide yourself what the order is in core because it is simultaneous contrary to primary.I understand it can be a bit hard at first though when using already made stuff and looking through the structure,trying to understand.I am not an expert like colB but once you grasp the basic of math mod modules and memory latches it is not so bad.
1
Categories
- All Categories
- 18 Welcome
- 1.7K Hangout
- 67 NI News
- 896 Tech Talks
- 4.6K Native Access
- 17.8K Komplete
- 2.2K Komplete General
- 4.8K Komplete Kontrol
- 6.3K Kontakt
- 1.1K Reaktor
- 407 Battery 4
- 917 Guitar Rig & FX
- 466 Massive X & Synths
- 1.5K Other Software & Hardware
- 6.4K Maschine
- 8.2K Traktor
- 8.2K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators