core sample table into multidisplay

gentleclockdivider

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

gentleclockdivider

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

gentleclockdivider

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

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

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

KoaN

https://community.native-instruments.com/discussion/comment/232222#Comment_232222

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

https://community.native-instruments.com/discussion/comment/232282#Comment_232282

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

https://community.native-instruments.com/discussion/comment/232293#Comment_232293

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

https://community.native-instruments.com/discussion/comment/232222#Comment_232222

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

https://community.native-instruments.com/discussion/comment/232313#Comment_232313

You're right

gentleclockdivider

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

colB

https://community.native-instruments.com/discussion/comment/232340#Comment_232340

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.