Reaktor core osc sync , bundle out

gentleclockdivider
gentleclockdivider Member Posts: 79 Sine

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


«1

Comments

  • Paule
    Paule BerlinMember Posts: 738 Saw

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

  • gentleclockdivider
    gentleclockdivider Member Posts: 79 Sine

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


  • Paule
    Paule BerlinMember Posts: 738 Saw
    edited November 2022

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


  • Laureano Lopez
    Laureano Lopez Cordoba, ArgentinaMember Posts: 90 Tri

    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: 79 Sine

    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 )


  • gentleclockdivider
    gentleclockdivider Member Posts: 79 Sine
    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


  • gentleclockdivider
    gentleclockdivider Member Posts: 79 Sine
    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



  • Paule
    Paule BerlinMember Posts: 738 Saw

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

  • Laureano Lopez
    Laureano Lopez Cordoba, ArgentinaMember Posts: 90 Tri

    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 😕


  • Laureano Lopez
    Laureano Lopez Cordoba, ArgentinaMember Posts: 90 Tri

    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

  • gentleclockdivider
    gentleclockdivider Member Posts: 79 Sine
    edited November 2022

    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
    gentleclockdivider Member Posts: 79 Sine

    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
    Laureano Lopez Cordoba, ArgentinaMember Posts: 90 Tri
    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: 355 Saw

    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 Cordoba, ArgentinaMember Posts: 90 Tri

    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.

Back To Top