core sample table into multidisplay

gentleclockdivider
gentleclockdivider Member Posts: 315 Advisor
edited June 26 in Reaktor

I'm having some issues getting the sample data into a mutlitidisplay
The data is correctly pushed into a core .

The iterator ( length provided by [?] module ) first triggers the index , then x1 , then y1 ( x2,y2 are not needed since I am using the line object ) .

For Y1 , the third outlet goes ito the core cell and this is how it looks , iterating the index then into a memory read with cr.c

I tried pushing the mem.read with the iterator istead of cr.c but still no luck

For some reason it doesn't work

The iterator and core cell are set up correctly ( I think ) since connectin the mem read sr.c to out produces audio .
But I need events

image.png image.png

Comments

  • gentleclockdivider
    gentleclockdivider Member Posts: 315 Advisor

    Apparently I have to trigger the mem read with the iterator and NOT the cr.c

    image.png
  • gentleclockdivider
    gentleclockdivider Member Posts: 315 Advisor
    edited June 27

    So stocked using the iterator and the mutlisdisplay set to antialised line
    Supersmooth graphics and updated my chebby shaper

    sweep.gif

    There is one thing that is so frustrating, in this case I am only using 12 sliders ( one mousearea for sweeping ) , so unpacking it is easy either in primary or core
    When there are dozens of sliders we have to duplicate router modules ( primary ) or core because the nr. of outputs are not variable

    image.png

    Pure data to the win , a single unpack object with 32 float arguments

    Pure.gif
  • KoaN
    KoaN Member Posts: 157 Advisor
    edited June 27

    If i understand correctly,you could make routers with more outputs in primary or core and then save them as macro,corecells,so you can reload them later.Can be quicker this way.

  • gentleclockdivider
    gentleclockdivider Member Posts: 315 Advisor

    Sure I know that , and that's how I do but it's far less convenient versus dynamic arguments like in max-pd
    Imagine 128 sliders and you need the value of each indivual one , it's annoying and time consuming !

  • KoaN
    KoaN Member Posts: 157 Advisor

    Yah,i never understood why they capped the router outputs at 16 in primary and in core you only have the binary router,low,high output…would sure be nice to just type in the number of outputs you need with no limitations.These are important basic elements.

  • colB
    colB Member Posts: 1,094 Guru

    When there are dozens of sliders we have to duplicate router modules ( primary ) or core because the nr. of outputs are not variable

    You could just send the value and index pair directly into the core cell, then store the value in a core array at that index… then fire in the iterator to read out from that same array… no need for all the 1 → M router type of thing.

    I can't remember ever needing that type of router mechanism to drive any core structure.

    I can't be 100% sure without the code to look at, this might be the first time a 1 to many was required for core processing.

  • gentleclockdivider
    gentleclockdivider Member Posts: 315 Advisor

    Im getting the grasp of writing in core arrays now
    My biggest issue is that I always started from the lowest level modules and not the [write] [read] macro's .
    I never got the order working because it has to be set to array instead of latch

    I guess the last R/W order module is not really needed when the read is not connected to another one
    Both work

    1.jpg 2.jpg
  • colB
    colB Member Posts: 1,094 Guru

    You only need ordering for OBC if the operation are driven by the same event(s).

    If writes are coming from gui events, and reads are from an iterator, then they are guaranteed to be asynchronous, so explicit ordering is unnecessary.

Back To Top