1. IMPORTANT:
    We launched a new online community and this space is now closed. This community will be available as a read-only resources until further notice.
    JOIN US HERE

Core Router and Compare Question

Discussion in 'REAKTOR' started by BrandonR, Nov 14, 2015.

  1. BrandonR

    BrandonR New Member

    Messages:
    16
    Having some issues with the core router and compare modules. I'm trying to create a simple event routing module controlled by a button or switch, but the router doesn't seem to react to a change in an input value from a button or knob. The attached picture shows the structure. The only thing not shown is that the button is connected straight to the core cell input, and the numeric display is directly connected to the output.

    The button has a value of 0 when off and 1 when on. When it's off the final output should be 0, and when it's on the final output should be 1000. Toggling the button has no effect on the output unless I disconnect and then reconnect any wire after hitting it.

    Does anyone know what I'm doing wrong here? Screen Shot 2015-11-13 at 8.21.33 PM.png
     
  2. salamanderanagram

    salamanderanagram NI Product Owner

    Messages:
    3,454
    just multiply the button value by 1000?

    also you are using routers all wrong. you need to send an event to the router for anything to happen. so you could remake it using one compare, one router, 2 latches and a merge. when a new button comes in you compare, send the button event to the router, then use the router output to trigger one of the latches.

    but agin, in this instance you should just multiply the button by 1000. or edit the button in properties so that it's value is 1000 whenever it's on.
     
  3. BrandonR

    BrandonR New Member

    Messages:
    16
    The above is taken out of context and simplified for an example of the mechanism I'm trying to create. Just changing the button output value or multiplying it won't work for my actual need. My assumption was that the button sending a new value to the compare counted as an event which would trigger the process. Though I'm obviously wrong since it does't work. I don't yet understand what else is needed to count as an event trigger for the router, why the latches are needed, and where they fit into the signal path.
     
  4. herw

    herw NI Product Owner

    Messages:
    6,421
    everything in core runs only when there are events which starts this, maybe audioclock inside core or any event from outside core.
    A router changes only its status but nothing more. the constant does send its value only at intializatio, so if you want its value you have to trigger it by a latch module and the button's event. that' the paradigm of core.
    Ciao herw
     
  5. BrandonR

    BrandonR New Member

    Messages:
    16
    Ah, okay. So in my pic above I just have to put a latch in between the constant and the router input, and also hook up the button to the clock input of the latch. That works! Thanks guys.
     
  6. salamanderanagram

    salamanderanagram NI Product Owner

    Messages:
    3,454
    generally speaking you want to process as few router modules as possible.

    example.png
     
  7. BrandonR

    BrandonR New Member

    Messages:
    16
    I'm basically building something similar to the selector/scanner primary module, in core. I've used the structure in my example successfully before when other event or audio signals were being fed to the router inputs. I was getting thrown when it didn't work with constants fed to the router inputs. The latches were the missing key.
     
  8. colB

    colB NI Product Owner

    Messages:
    3,969
    OT
    Not really.
    It depends on the context. If the code is in an 'inner loop' situation causing heavy cpu usage, you should really do some comparative testing. Don't try to second guess the core compiler or the cpu branch prediction system.
    /OT
     
  9. salamanderanagram

    salamanderanagram NI Product Owner

    Messages:
    3,454
    obviously my statement was in response to a picture with an unnecessary router. i'm not making a blanket statement to avoid them all the time, just pointing out that when using them one should be on the lookout to keep things efficient.

    the picture at the top of this thread is a very inefficient method, especially if it's going to be expanded into a selector/scanner, in which case it will grow linearly with size as opposed to logarithmically if the router was well designed using a tree method.

    anyway it looks like this work is being done at event rate so it's a completely moot point.