Writing data into table (core )

gentleclockdivider

Can someone point me in the right direction
I have no trouble reading from the (read only ) table ,but writng into an array ..phew

In pure dat it's as simple as selecting the index and writing the value at that position

In core , I assume it would be something like this , the index of the table is accesed via the index knob , and then the value knob writes into that index postion , obc of index out is connected to mem write .

This should write data into it , no ?

colB

Yep. If you have a problem, it's elsewhere

gentleclockdivider

I'm still in the dark about writing into the table , for both audio and event ( meaning small size )

For reading a table it makes sense that a ramp wave is used ( multiplied by the table size ) to read the index , but for writing an audio file this doesn't really makes sense .
Are we supposed to use a ramp wave for indexing alongside the signal for recording ?

Also , how do we know if the signal is recorded properly since the array does not have a visual buffer indicator ( unlike the read buffer )

The screenshot shows audio going into the write mem .
The index is read by a ramp wave of freq 1 , amplitude 1 mulitplied by size of he array (44100 samples )

Eventually the read memory is triggered by sr.c , sure I get audio at the end but this just becasue of of the write-read connection , there is no way to determin if the audio is coming from the buffer .

colB

It's core, there are integers. So you can guarantee that you store values exactly where you want them.

I wouldn't think of it as a ramp 'wave', rather an index generator starts at zero (or some other value), adds exactly 1 every tick and can be reset to whatever value is required. Use integers for this. It is simple enough that I usually just scratch build it when required.

gentleclockdivider

partial succes by reversing the obc order of read-write (master slave )
Still some clicks though , whcih I am sure is becasue of the ramp wave indexing is not in sync with the audio in signal

colB

Don't use a wave, particularly from primary, to drive a core read or write process. You can make it work, but it's a pain to debug (conversion to integer for the index rounds, so index=1 when the wave is in the range 0.5…1.5 etc. so not ideal, you can work around this, but it's no fun. Rounding rules are not intuitive.

Here is a basic core implementation:

This writes the audio input into the array (not table, tables are read only), and wraps to the size of the buffer.

For greater efficiency, use a buffer that is a power of two in size!

here the buffer is 2^16 = 65536

if the input is not audio, then use 'in' to drive the index process instead of SR.C

It really is worth getting to grips with integer arithmetic, it's one of the many advantages of working in core.

colB

Note that an anti-aliased audio oscillator is not a pure ramp, usually at least the first and last samples (either side of the discontinuity) are altered to reduce aliasing. That makes it particularly bad as a phase accumulator.

gentleclockdivider

So there is no easy way ro record into an array and display the waveform (in core that is ) ?
Pure data makes this so easy , an array can be used to display whatever is inside the buffer (tabwrite~ for audio , tabwrite for num.data )

gentleclockdivider

https://community.native-instruments.com/discussion/comment/202332#Comment_202332

I'm well aware that antialised ramp are not suitable for accumulators

The primary ramp antialising can be turned of and is the best choice for sample accurate readouts and as a phase accumulator (that's why it's unipolar ) , perhaps you're mistaken with the primary sawtooth ?

There is almost no difference in resolution between the primary ramp and a core based accumulator .

Again , primary Ramp , NOT primary sawtooth

colB

https://community.native-instruments.com/discussion/comment/202508#Comment_202508

In core, an array is somewhat like an array in c or some other real programming language. It is a contiguous chunk of memory low level closer to 'bare metal' - memory locations on a computer don't have built in visualisation mechanisms.

A 'table' is a high level construct. That usually means flexibility and cpu efficiency are sacrificed for simplicity and ease of use.

You can create visualisation if you want to, and because you build it yourself, you get to make it look and behave the way you want, but it is more work. (The only problem is the lack of modifier keys like CTRL SHIFT etc. in the mouse area module. Those would make it easier to build seamless interfaces for exploring and editing waveforms).

Mostly often, if I want to see what's happening with an array (or any type of core code), I use a scope, and/or ACEW

colB

https://community.native-instruments.com/discussion/comment/202514#Comment_202514

I forgot that the aa can be turned off (note also that the name of the module is not visible in your original post, and the same icon is used for saw and ramp). I rarely use them. And never for this purpose, because like I said, it's not a good way to go.

I've already explained about rounding in an earlier post. After scaling your ramp, try subtracting 0.5 and clamping/clipping min to zero. That might sort you problem... or not.

If you build your ramp in core, using integers, the problem will not exist, and no workarounds will be needed :)

gentleclockdivider

https://community.native-instruments.com/discussion/comment/202576#Comment_202576

The point is that I rarely scale the ramp because you want to use it as is , from0 to 1 , an not from -0.5 to 0.5 , that would defeat the purpose of a ramp/accumulator .

Edit : you can clearly distinguish the ramp because it only has a Freq input , but we're getting off topic here

colB

https://community.native-instruments.com/discussion/comment/202607#Comment_202607

The point is that I rarely scale the ramp because you want to use it as is , from0 to 1 , an not from -0.5 to 0.5 , that would defeat the purpose of a ramp/accumulator .

The point is that you always scale the ramp or it wont work, here is the ramp scaling code from your pic:

That's the scaling part, but it hides some nasties that I have mentioned already, but will try to explain in more detail.

The problem is rounding:

As an example lets assume the array is 48000 entries in size (for a nice 1 second at 48KHz :-))

When you multiply by 48000, you get a ramp that goes from 0 to 48000.

… but what you need is 48000 steps, starting at zero, so you want 0 to 47999.

The index input of the array indexing module has an integer input. If you attach a float to that port, it will be rounded to the nearest integer.

so, after rounding, from 0 to 0.5, of your scaled ramp, you get a 0 to access the first element in your table, so only for 1/96000th of the ramp's range oops! then from 0.5 to 1.5 (1/48000th of total range) you get a 1 to access the second element, then all the way up to 47999.5 each rounded step covers 1/48000th, which is ok, but the for 47999.5 to 48000 - again 1/96000 of the range - you get 48000, which is out of bounds, a 48000 entry array's last element is at 47999.

What I suggested (and maybe you ignored?) was to subtract 0.5, and clip minimum to zero (might not be necessary, might need to clip max to 47999, not 100% sure without double checking the rounding rule. I think it's ties round to even (I checked, it is 'ties round to even'). Simplest would be to minmax clip to the range 0…47999

Anyway, subtracting 0.5 means that you start at -0.5… so for the first 1/48000th of the ramp you get -0.5 to 0.5, this rounds to 0, so that's much better, and gives you the first element for the right proportion of the ramp… then the rest are good up to 47999.49 which rounds down. Unfortunately, 48000 - 0.5 = 47999.5 which is a tie, so rounds to the nearest even number which is 48000, and out of bounds.

So I was initially wrong. You don't need to clip the low end, you might need to clip the max to N-1, in this case 47999. It might not matter, it would depend on the context.

something like this:

Those arrows are highlighting the two different port types, float to integer, this means implicit rounding occurs. There is no way around this, the index module has an integer input. This is a good thing, integers are exact, floats are not.

Alternatively, you could just build a very simple integer phase accumulator, and it will work great with no problems or complexity… if you consider clip max macro internals, that adjustment code to 'fix' the ramp is similar size to the complete integer phase accumulator.

gentleclockdivider

I meant ofsetting instead of scaling ,

Studiowaves

Once you get it going you can import text files into them. I used excel to draw out some curves then exported the numbers into a text file. Then it's super easy to import them. I think there might be other things you can import but they do have a maximum size. I think it 2^20 or something. Maybe setting it to 64 bit will give more memory, not sure.

colB

https://community.native-instruments.com/discussion/comment/203363#Comment_203363

Read the thread, it's about arrays not tables!