How is it possible for a core cell to not work properly with audio and event inputs.

As shown above the Inv input on the bottom works perfectly as an audio input but erratic at best as an event input. There is a panel on/off button attached to it. It toggles between 0 or 1 and yes it's set to toggle mode.

All other inputs work as expected. Being a simple button its almost like it doesn't always create an event or the value of the event isn't latched. Not sure how the compiler handles events but I assume the input itself would hold or latch the new value when it receives an event. This is either a bug or I'm need to do something to capture that value. Any ideas on a solid solution other than wasting cpu and leaving it set to audio?

Find more posts tagged with

Accepted answers

All comments

Studiowaves

I assume the serial clock is interally assigned to the lower input. It says C

But I thought only this would attach a the clock.

Anyone know? I added the SR.C connection on the bottom pic. Is it necessary?

KoaN

https://community.native-instruments.com/discussion/comment/1251#Comment_1251

That's what i was referring to in my post,those crossfade modules with Math modulation inside,for using as simple relay switches i often replaced the math modulation components with the normal ones to avoid the type of problems you had when i wanted to just use event signals.Latching is good but unless you know exactly what is going on it can bring more problems down the road...it certainly happened to me a few times.

Studiowaves

Koan I don't know how to make a direct reply to you. So I copied it, how is it done?

It's a problem using math mod and I never really understood the need until I put a knob on a standard multiplier connected to an event on one input. Every time I moved the knob a bunch of notes started playing. I was trying to scale the velocities and the standard gate was connected to the multiplier. So I switched to the math mod multiplier and attached the knob to the input that does not generate an event and it stopped that. Ah ha, now I get it. I think I read your post once it went thru and knew what you meant. Now when I post this comment what is going to happen. here goes. lol

KoaN

https://community.native-instruments.com/discussion/comment/1277#Comment_1277

Just press " Quote" under a message.

Yes a good example you gave for using a latch to block certain events.

Studiowaves

https://community.native-instruments.com/discussion/comment/1282#Comment_1282

Oh, that was easy, I thought by pressing quote it would spread across world. lol Any way, I'm starting to think event modules will not work properly if you add something event based like the button. I know audio ports work the same because the patch was saved beforehand and you have to resave the patch. However I have never had a problem with a switch not changing it value even if was not saved. In this case the input port worked fine in audio mode but not at all as an event. Then I noticed it did work with other patches, and those were new patches I made and saved with the new switch. I'm not sure yet but since I re saved all of the patches with the new switch I have not had a problem with the Invert input as an event input. It kind of makes me think event inputs are actually stored differently than audio ports as part of the patch. So basically they work fine in edit mode when you put it in. But if you change to an old patch before saving the edit it might not work. I made the changes with the switch but didn't change the patch before saving the ensemble. The next day when I went to use it I noticed the switch wasn't working. It was still the same patch that I didn't save before closing and saving the ensemble. Once that patch was saved and the ens. saved afterwards. Shutting down reaktor and starting it over everything was fine with that patch. So I re-saved all of the patches and so far so good. And no, blocking certain events was not what I intended. Amazing how we all interpret things differently. lol Take it easy, time to practice keyboards...

Studiowaves

https://community.native-instruments.com/discussion/comment/990#Comment_990

It's working fine now, I think it's from not saving the patch after adding the panel button. In edit mode the panel button was reading 0 after saving the ensemble but not the snap shot. With audio inputs they still work without the patch being saved but there will be no memory of the new button until it's saved in a patch. With an event input it would not work until the patch was saved with the new button in the ensemble. Just stayed at 0 even though the panel button changed it color from off to on, which was set 0 is off 1 is on. Crazy and i don't think a latch is necessary.

Studiowaves

https://community.native-instruments.com/discussion/comment/1272#Comment_1272

Ok, I glad you brought that up, I had to change the xfade with the Inv on the X to the other crossfade, it's called crossfade mod.

I actually had 2 problems, after re saving the patches it fixed the button so it changed from 0 to 1. Then I exited edit mode and it wasn't working again, so I toggled the button of then on again and it started working. That's when I took your advice and swapped it. Now it all works fine. These modulation macros are a pain, but what i've noticed is the input with constantly changing events work fine, but for some reason the edit mode seems to mess with the logic which forces you to re toggle a switch, mainly because it's static and will not create an event to trigger the modulation macro. However this module is different and the buttons value affected the x input like an ordinary non modulation macro. The O and 1 input are constantly bombarded with events when the keys are played so it's basically the same thing as toggling the panel button. So it works.

bolabo

If you replace all the 'XFade (tap)' modules in the structure of your original post, these ones:

with 'XFade (Math) modules:

then it I recon it will handle your issues. As Colin and KoaN mentioned those 'XFade (tap)' modules are the cause of your problem, as there are 'latches' within them. These latches mean that changes from some of the parts of the structure (for example from your button) wont be registered by the xfade module until events from another part of the structure cause the latching inputs of the 'XFade (tap)' module to update the non-latching inputs.

The 'XFade (Math)' module doesn't contain any latches:

and therefore you wont have these issues.

You can think of a latch a bit like a 'sample and hold' in an analog synth, the value at the upper input port will only be sent when an event (either as part of an audio stream or just a single event coming in) is received at the lower input port ("C"):

Latches can be used to maintain control of events at different points in your core structure, but as KoaN mentioned, if you are not careful they can mess you up. Sometimes it's best to avoid them, so try using 'XFade (Maths)' rather than the other 2 latched varieties of the XFade module ('mod' and 'tap') and see if that helps.

bolabo

Try replacing all the 'Xfade (tap)' modules:

with 'XFade (math)' modules:

That will fix your problems I think.

The 'XFade (math)' module doesn't contain any latches:

The (tap) and (mod) versions of the XFade module contain latches that will mess things up in your structure, as the value from your button won't be registered until events from other parts of the structure trigger the latching inputs of the 'XFade (tap)' module.

Latches are a bit like 'sample and hold' on an analog synth, the value of the upper input will only be sent when an event or audio stream triggers the lower ("C") input.

As Colin and Koan mentioned, using latches can mess you up if you are not careful, so best to stick with the not-latching (maths) version of XFade rather than the latched (mod) or (tap) versions.

Studiowaves

https://community.native-instruments.com/discussion/comment/1498#Comment_1498

Yeh, I agree, they are foolproof. I studied the logic of the modulation macros and discovered the tap was wrong but the mod works correctly. The problem of using regular modules with events when you actually need a modulation macro is turning a knob and it sends out a series of events. If the input is a gate it will continue to repeat the gate when the knob is turned. I tried to multiply the gate and that's what happened. By using the Mod Math Multiplier, I could turn the knob without sending a series of note on gate commands. So it's worth the study sometimes. However the problem I posted had to do with the List module not even sending and event with a number to latch. It turned out to be a problem because I put it in the ensemble after the patch was made. Once I saved the patch with the new list module it worked fine. Then a second problem came up and it's exactly what your talking about, the tap module was actually working but the edit function messed things up and I had to re press the button twice for it to register the new value, I tried the mod xfade and it maintains the value when I use the edit mode, I suspect it has a latch on the x input that holds the number when edit mode is used. Tricky, because I didn't know the edit mode affected event inputs, but it certainly can. Talk later and thanks. Are you a keyboard player by chance?

Studiowaves

https://community.native-instruments.com/discussion/comment/1282#Comment_1282

Hi Koan, thought I'd let you know Fm12 is really rockin'. It's pretty exciting when all these little velocity sensitive things start to add up when playing. I even got the thing to stretch tune on faster velocities. It may not have great sounds like good samplers but it sure is expressive and fun to play. Maybe you can test it out when I get more patches, another friend I have played music with for 50 years loves it. Talk later...

Quick links

Unanswered questions