Boolean table readout of list in console is totally off

[gentleclockdivider]

The boolean readout in the console does not represent the graphical representation when it's triggered from the distribution list
I know I should use the metro to trigger , but it's not always clear whether the module in question is suited to trigger a gives a reliable outcome( is his case it's not)

[colin@loomer]

That is weird. It sometimes seems correct, and other times wrong; and it seems succeeding reads are correct. Anyway, I have witnessed the issue here, though, so it should be an easy fix.

[gentleclockdivider]

I did some more testing and addded a logic AND module going into a third boolean (both triggered from metro ) , first 2 booleans triggered from list
The red dots light up (third boolean ) when both inputs are true , when comparing to the gui it's not , when comparing to the console view it's correct


Suggestion ( if possible ) , since the output of the distr.list is not accurate for triggering ( in this case ) , why not add a alternative output that routes the input ( in this case metro ) directly to the alt.output

[colin@loomer]

Hang on, no, I know what this is.

When you send an array to the read inlet, it treats the array as an array of indices and assumes you want to read those. So if you send an array of, say, [1, 3, 7] to read, it will output an array with the 1st, 3rd, and 7th elements only. If you want to read all the elements, just send it a signal. (Or you can send a single number to read just a single element.) What happening here is you're sending an array of 0s and 1s to the table read, and then the output is an array of the 0th and 1st elements.

So put a [signal] module (without a setup event) between the list output and the table read inlet to convert the array to a `signal` object. You'll also need an order module to make sure you do the write before the read.

[gentleclockdivider]

So you say it's because I send an array to the read inlet of the boolean table ?
If so , then I would have the exact same result when triggering it from metro , no ?

[gentleclockdivider]

So it's better to trigger fro metro instead of all the added wiring ,
Pff , things are getting pretty complicated for basic stuff

[colin@loomer]

You mean like this?



Yeah, that'd work. The essential point is that table read can accept:
a signal, which means read all the elements as an array
a number n, which means read the nth element
an array of numbers, which means reads the elements in the array.

So using the same (array) event to both write to a table and read at the same won't work.

[gentleclockdivider]

All right , so the read input is not just for triggering , that would be calling ( colour code read and call )
Could you give some more examples , modules where the read input does further processing on the input ?
Why not gieve the table also a call input , so it doesn't matter where it receives from ( or is that wishfull thinking ? ) , iow just ttiggering

[colin@loomer]

(Just to clarify, it's not where the event is received from, it's the type of the event that matters. As metronome outputs `signal` events, it reads the entire table.)

The only other module I can think of where you can read either the entire data, or just a subset, is the [grid] module. Here, you can either send a signal (which outputs the entire grid as a 1d array), or a tuple (x-cell, y-cell) to read a single cell, or an array of such tuples to read any number of cells.

[gentleclockdivider]

Sending lists , the gui is correct but the console is not

[gentleclockdivider]

(Just to clarify, it's not where the event is received from, it's the type of the event that matters. As metronome outputs `signal` events, it reads the entire table.)

The only other module I can think of where you can read either the entire data, or just a subset, is the [grid] module.

And the graph. table

[colin@loomer]

In the screenshot you just posted, take the left-most list. This will first go to the [boolean table] write inlet, and write the values [0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1] to the table.

Then, this same array will go to the read inlet, and will be interpreted at [read the 0th element, read the 0th element, read the 0th element, read the 1st element, read the 0th element, read the 0th element, read the 0th element, read the 1st element, etc], so will output an array of all 0s, as both the 0th and 1st elements are (since the previous write) now 0.

Which I assume is what you are seeing?

[gentleclockdivider]

O.K all clear now
I learned something new today , thanks for guiding

[colin@loomer]

No problem at all!