Reaktor core osc sync , bundle out

gentleclockdivider
gentleclockdivider Member Posts: 208 Helper
edited October 22 in Reaktor

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

1.jpg

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

2.jpg


«1

Comments

  • Paule
    Paule Member Posts: 1,314 Expert

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

  • gentleclockdivider
    gentleclockdivider Member Posts: 208 Helper
    https://community.native-instruments.com/discussion/comment/38533#Comment_38533

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

    3.jpg


  • Paule
    Paule Member Posts: 1,314 Expert
    edited November 2022

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

    grafik.png
    grafik.png
    grafik.png


  • Laureano Lopez
    Laureano Lopez Member Posts: 102 Advisor
    snc.png

    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
    gentleclockdivider Member Posts: 208 Helper

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

    1.jpg
    2.jpg
    3.jpg


    Here's the ensemble ( beginning of a sem )

    Sem.ens


  • gentleclockdivider
    gentleclockdivider Member Posts: 208 Helper
    edited November 2022

    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
    gentleclockdivider Member Posts: 208 Helper
    edited November 2022

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

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

    simplified.ens


    3.jpg
    Sync slave.jpg


  • Paule
    Paule Member Posts: 1,314 Expert

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

  • Laureano Lopez
    Laureano Lopez Member Posts: 102 Advisor
    https://community.native-instruments.com/discussion/comment/38554#Comment_38554

    Yeah, it's this thing

    agh.png

    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
    Laureano Lopez Member Posts: 102 Advisor

    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
    gentleclockdivider Member Posts: 208 Helper
    edited November 2022

    In the end I put them all in core .

    SEM.jpg


    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
    gentleclockdivider Member Posts: 208 Helper
    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

    2.jpg

    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 .

    4.jpg


  • Laureano Lopez
    Laureano Lopez Member Posts: 102 Advisor
    edited November 2022

    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
    colB Member Posts: 987 Guru

    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
    Laureano Lopez Member Posts: 102 Advisor

    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.

This discussion has been closed.
Back To Top

Categories