Reaktor core osc sync , bundle out

gentleclockdivider

The core osc sync inputs takes bundles .

The issue I am having is that the master osc is in another core cell and I can't get the sync bundle out of the core cell

Pack unpacking bundles is probably not the right way to do it

Paule

Why do you needs a bundle to sync the osc's?

gentleclockdivider

https://community.native-instruments.com/discussion/comment/38533#Comment_38533

Because the sync input is a bundle input and only accepts bundle outputs

Paule

But you can extract the sync from the bundle inside the macro.

Laureano Lopez

The bundle fibers need to have the right name, which in both cases is "snc". The source cell's output needs to be event with "allow audio events" enabled. The target cell's input is just event.

You can't use audio ports for this because primary audio signals are continuous streams of events at the sample rate, and the snc signal only happens at cycle transitions. You can't use "normal" event outs either, because they block events originated in an audio signal, and snc comes from SR.C. "Allow audio events" exists precisely for these cases. It's likely that having everything in a single cell would be more performant -streaming from/to primary is not free.

gentleclockdivider

Still don't got it working despite naming the outs , and input sync port to event or audio , remains red

Here's the ensemble ( beginning of a sem )

Sem.ens

gentleclockdivider

Here I changed the bundle name name to snc instead of sync .

The red error dissapeared , input set to event but still doesn't sound like osc sync (osc 2 is slave )

Off topic , the core svf with saturation sounds absolutely stellar , I am comparing it to gforce SEM and t's near identical

Sem 2.ens

gentleclockdivider

O;K ; so I completely simplified it , still not working

So if anyone can make this example work I'd be delighted

simplified.ens

Paule

Why do you need a bundle in to sync? Isn't it enough with an In Port?

Laureano Lopez

https://community.native-instruments.com/discussion/comment/38554#Comment_38554

Yeah, it's this thing

which means those "audio" events are probably realigned to the control rate, so even taking this out makes the sync happen at the wrong places 😤 #ihateprimary

Here is a brute force approach: mixing snc with a "flag" of 2 (snc goes 0..1), then filtering the flag out. I was trying to avoid this because of the obvious performance penalty 😕

the ugly way.ens

Laureano Lopez

It's not the control rate either, just checked. Primary event voodoo magic -.-

Anyway, this probably works too and seems to be slightly more performant: I keep the event connection but reclock to SR.C. I say probably because given the mysterious reclocking I can't be sure there's no delay or jitter involved... just can't visually spot an error

the kind of less ugly way.ens

gentleclockdivider

In the end I put them all in core .

Reason why I used primary was for crossafading between osc , on the sem it fades between -1 to 0 for saw,thuss attenuating , zero to +1 for square .Zero being silent

So saw-square combined =1 osc .

I do need to add some mem latches .

So we can assume that taking bundles out of core is not a good idea

gentleclockdivider

https://community.native-instruments.com/discussion/comment/38562#Comment_38562

I appreciate your interest but have you actually read what i wrote ?

The sync input of an osc takes a BUNDLE ONLY , if master and slave osc are in the same core cell you just route the bundle out of the master osc into the bundle in of the slave osc ,like this

Easy

Now , if the Slave osc is another core cell , the bundle out needs to get into the primary domain and that's where the troubles happens .

Laureano Lopez

So we can assume that taking bundles out of core is not a good idea

The bundle is not the problematic part, it's being an audio rate signal that's been event filtered, so it's not a continuous stream. There's no such a thing in primary, so it forces you to filter it again somehow.

It's always good to minimize core->primary->core situations involving audio signals. There are exceptions, like mono/poly divides or heavily branched structures that get too slow to compile in one piece, but generally going out and back into core is not cheap.

colB

Could probably use an audio stream through Primary layer, and use a dup filter in the next core cell to only respond to changes.

Would maybe only be a problem if the master frequency is at some integer division of the sample rate... which could be hacked around if it worked otherwise.

Best to keep it all in core though

Laureano Lopez

Could probably use an audio stream through Primary layer, and use a dup filter in the next core cell to only respond to changes.

Would maybe only be a problem if the master frequency is at some integer division of the sample rate... which could be hacked around if it worked otherwise.

Yep, that's why I mixed with a value that's known to be out of range, then you can filter out just that value. It works in this case because we know each event is isolated.