Switching mod sources in core , filter becomes dull

gentleclockdivider · 2022-11-08T17:43:20+00:00

There was an error rendering this rich post.

I am recreating the sem with some additional features as found in gforce sem .

It sounds stellar , but there re some issues I am encounteting .

The filter (SVF) can be modulated by either env 2 ,vco3 or lfo (so audio rate ) see screenshot 1

The issue is when I am switching between audio rate ( thus osc3 as source ) and envelope the filter sometimes becomes dull .

Screenshot 2 shows the filter mod sources , the sources are slected by a switch then summed but only one is let through depending on state of slider )

Then it's multiplied by the mod amount(screenshot 2), utilising a latch which uses the sr.c that sends out the stored value in memory ...so why does the filter sometimes becomes dull ?

Just switch the filter mod between 1 and 2 ( alternating between envelope modulation and Osc mod )

Help appreciated .

Here's the ens.

Sem.ens

Find more posts tagged with

Comments

bolabo

Try changing the 2 'sum' modules to 'merge' modules instead, and swapping the inputs of the 'multiply' module, so the audio stream from the modulation sources is going into the upper port, like this:

gentleclockdivider

Yep , the merge module did it ..

Why did the add module prevent it from working correctly ?

Edit it's still an issue , but now when selecting the osc 3 waveform switch , the filter again becomes dull

bolabo

Why did the add module prevent it from working correctly ?

Because the router modules are switching the audio streams from the modulators on and off, and when the router is switched off ('select' doesn't equal the value) the last value that got through that router will still be added to the other 2 values by the 'sum' modules, the last passed value is still used by the sum module. You need to use 'merge' modules instead, so just the modulation audio streams are passed directly through, and not added together.

Edit it's still an issue , but now when selecting the osc 3 waveform switch , the filter again becomes dull

You need to do the same thing with this part too, replace the summing with a merge

gentleclockdivider

Noppes , i tried it , the merging does not solve it , I replaced the adders ( whenever possible ) .

There is an issue with the filter modulation amount when switching between filter fm and env.fm .

The filter amount knob is bipolar , but when switching the source from Osc 3 to env 2 , the positive range of the amount somehow dulls the filter , somehow the last value from the filter fm is stuck in the filter and therefore dulls therange .

Which is weird becasue I used sr.c in latches whenever possible to update the modulation .

Here's the ensemble , and a few words of explonation .

Osc 3 wave-noise knob , alternates between osc 3 being a wave set by Osc 3 waveform or noise , the knob is an attenuator and does NOT influences the filter fm

The filter mod slider , position 1=env 2 , pos 2 =filter fm by osc 3 , post 3 =lfo .

Important , " the env1, nil, env 2 slider " located under osc 3 waveform slider defines if the amplitude of osc 3 output as filter fm source is scaled by env 1 ( position 1 ) , not scaled (position 2, ) , or scaled by env 2 (position 3)

Just flick the osc 3 fm multiplier switch fm multiplier (so it's fm mod output is either scaled by env 1 , none or env 2 ) and hear the oddities , merge moduels are also used there .

These features are also found on gforce sem

Sem.ens

This particular setting is caussing th issues , filter fm switch to middle position so osc3 output is just multiplied by 1 , changing the switch back to postion 2 makes it's obvious

gentleclockdivider

I am at loss

Here the adder module works fine for crossfading between waveforms , the small residue that is left over from the router module is just added .

But when using the merge module , this small value prevents the other value from going through the merge value since merge gives priority to the lower input .

All multiply modules are using SR.C to trigger the memory

Damn.ens

bolabo

These chapters of the reaktor 6 building in core might help:

5.6.2 Latches and Modulation Macros

5.6.3 Routing and Merging

https://www.native-instruments.com/fileadmin/ni_media/downloads/manuals/REAKTOR_6_Building_in_Core_English_2015_11.pdf

The problem you are running into in your screenshot is that the sawtooth and pulse macros are both outputting a continuous stream of audio events, these 2 streams are then fed into the multiply modules and then both streams continue on to the merge module. As both ports of the merge module are receiving a continuous stream of events the lower port is favoured and this stream is sent to the output.

You need some way of stopping the one of the 2 streams before the merge module depending on the result of the compare module. You can do this by using a sample clock "SR.C" routed to 2 different latch modules, the router module will send the SR.C audio clock stream either to the upper or lower port, but never both, and then go on to trigger one of 2 latch blocks thereby controlling which stream is sent to the merge module, like this:

The lower port of the latch module (circled in the pic above) is the 'clock' port. The latch module will send out the value at its upper input port only when a clock signal or event is received at its lower input port.

You can get the sample-rate clock distribution bus by right clicking on the input to the router, like this:

bolabo

Also the middle input to the merge module in your example is coming from a 'quick constant' ("1") whereas the the ones on either side of it ("e1" & "e2") are both audio streams.

The quick constant will generate an event that is only sent once, when the core cell is initialised. So you will need a latch module triggered by the 'SR.C' sample clock to make it become an audio stream that can then routed by the router. I think this is why you are having issues with this part of the structure, so you could try this -->

gentleclockdivider

I know about the sr.c and right clicking

But I also need the select value to control the amplitude of the osc's and again this brings up the problem as showcased in my first post

gentleclockdivider

OK .this did it

Putting the mul before it

BUt now I am even more confused why it's working .

quote

You need some way of stopping the one of the 2 streams before the merge module depending on the result of the compare module. You can do this by using a sample clock "sr.c" routed to 2 different latch modules

unquote

It alternates nicely between saw (left ) and square , but you clearly ysee that the merge is still receiving two input values (value shown of square at bottom ), yet saw is let through (value is not shown on screenshot)

Could it be that the debugging is not really showing the correct values ?

bolabo

Could it be that the debugging is not really showing the correct values ?

The wire debugging will show the last value that was present on that wire, even if the stream has been stopped.

bolabo

It's not easy to see which wires in core have audio streams currently flowing in them and which ones don't, which is kind of a shame.

I sometimes connect up the 'Event-Watcher small' macro from the 'debug' menu to a spare output port of the core cell, and then connect things in the core cell up to this port to see if I get a stream of events or not (make sure to enable "Allow Audio Events" for the port)

Note, you will find if you keep the event-watcher running from an audio enabled port it will eventually overflow and stop working so you need to hit the 'Run' and 'Rst' buttons occasionally when doing this.

gentleclockdivider

PLease explain why the first example -screenshot is working , while the second is not ?

In the not working example, the router is outputting it's value received from primary and constant 1 ( depending on true state ) and goes into a latch which is triggered by S.R.C ,

In the working example the router is outputting S.R.C ( depending on true state ) and this is used to trigger the mem latch which holds the value received from primary

There shouldn' tbe anny differences no ??

Edit , Ok ;; ofcourse the second example s not working because it's continously sending out values at SR.C. into all inputs of merge .

Glad I got it working , thanks toybox

bolabo

In the second example you have all 3 streams, triggered by the SR.C clock entering the merge module, so only lowest port will be passed through.

From the manual:

"The Merge Module simply lets all incoming events go through to the output. If the events arrive simultaneously at both inputs, the lower input has priority."

In the first example only one of the 3 inputs will will be latched by the SR.C clock because the compare modules will switch the three SR.C streams on and off

bolabo

Also note that the router module itself won't trigger or generate any events, it simply passes or doesn't pass events to its upper or lower ports depending on the result of condition module.

So even if the value of "///" changes, the constant "1" connect to the router module won't be resent from the router as the constant only sends its value once during initialisation.

bolabo

Edit , Ok ;; ofcourse the second example s not working because it's continously sending out values at SR.C. into all inputs of merge .

Glad I got it working , thanks toybox

Ah just saw this, brilliant! :)

Quick links

Unanswered questions