core sample table into multidisplay

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
Comments
-
Apparently I have to trigger the mem read with the iterator and NOT the cr.c
0 -
So stocked using the iterator and the mutlisdisplay set to antialised line
Supersmooth graphics and updated my chebby shaperThere 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 variablePure data to the win , a single unpack object with 32 float arguments
0 -
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.
0 -
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 !0 -
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.
0 -
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.
1 -
You're right
0 -
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 latchI guess the last R/W order module is not really needed when the read is not connected to another one
Both work0 -
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.
0
Categories
- All Categories
- 18 Welcome
- 1.7K Hangout
- 67 NI News
- 890 Tech Talks
- 4.6K Native Access
- 17.7K Komplete
- 2.2K Komplete General
- 4.8K Komplete Kontrol
- 6.3K Kontakt
- 1.1K Reaktor
- 407 Battery 4
- 917 Guitar Rig & FX
- 465 Massive X & Synths
- 1.5K Other Software & Hardware
- 6.4K Maschine
- 8.1K Traktor
- 8.1K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators