Valery_Kondakoff

I created an easy [phasor~] based sequencer, which works quite predictable. Now I'm planning to drive some MIDI devices and want to convert signal values to numbers. To do so I'm sending [bang] every quarter note to the [snapshot~]. Surprisingly, the converted numbers are one sequencer step behind the signal values ('banging' to early?). I was trying to play with [snapshot~] offset and toggling the Audio status 'Scheduler in overdrive' and 'Audio Interrupt' options. Unfortunately this does not solves the issue.

Снимок экрана 2022-11-23 в 13.20.50.png

What is going there? Am I doing something wrong? Should I delay [bangs] anyhow? Or should I use, say, [snapshot~ 10] and later parse the numbers stream for change? Your ideas? Thank you!

sig-to-event.maxpat

Hello!
I created an easy [phasor~] based sequencer, which works quite predictable. 

help-converting-signal-values-to-numbers-in-a-phasor~-based-sequencer

you don't see the obvious - rightmost outlet of subdiv.

> you don't see the obvious - rightmost outlet of subdiv.

Can you, please, expand your answer a little? 🙏

I'm using [subdiv~] rightmost outlet (step number) to get signal values from [table~], and (obvious) to demonstrate the... hmm... current step number...

> you don't see the obvious - rightmost outlet of subdiv.

Can you, please, expand your answer a little? 🙏
I'm using [subdiv~] rightmost outlet (step number) to get signal values from [table~], and (obvious) to demonstrate the... hmm... current step number...

you are converting converted to unconverted ...

What I mean, either use numeric output of itable,

which you use anyway to set table~ values.

You don't need any of that stuff, except rightmost

image.png

you are converting converted to unconverted ...
What I mean, either use numeric output of itable,
which you use anyway to set table~ values.
You don't need any of that stuff, except rightmost
subdiv~ outlet and itable.

Ah, yes, thank you!.. This patch was created to illustrate the conversion issue, so it was not designed carefully: there is no need to convert sig to num here! Thanks!

And your example gave me enough ideas to narrow the issue. Here is what I got: if you are getting values out of [table~] using numbers (not signals) - the conversion will be always wrong. If you are using signals to get values out of [table~] the conversion results will depend on Audio status 'Audio Interrupt' option and the [snapshot~] offset. Here is the summary.

Снимок экрана 2022-11-23 в 16.18.41.png

1. We are getting values from the [table~] using numbers, so the conversion will be always wrong.

2-3. We are getting values from the [table~] using signals, and when 'Audio interrupt' is set to 'OFF' the conversion will be always right, independently of the [snapshot~] offset, which does not works if 'Audio interrupt' is set to 'OFF'.

Снимок экрана 2022-11-23 в 16.23.29.png

2. We are getting values from the [table~] using signals, and when 'Audio interrupt' is set to 'ON' the conversion will be right if we set [snapshot~] offset to the Signal vector size -1.

3. We are getting values from the [table~] using signals. 'Audio interrupt' is set to 'ON' and the [snapshot~] offset is not set to the Signal vector size -1, so the conversion will be wrong.

1. We are getting values from the [table~] using numbers, so the conversion will be always wrong.
2-3. We are getting values from the [table~] using signals, and when 'Audio interrupt' is set to 'OFF' the conversion will be always right, independently of the [snapshot~] offset, which does not works if 'Audio interrupt' is set to 'OFF'.

1. We are getting values from the [table~] using numbers, so the conversion will be always wrong.
2. We are getting values from the [table~] using signals, and when 'Audio interrupt' is set to 'ON' the conversion will be right if we set [snapshot~] offset to the Signal vector size -1.
3. We are getting values from the [table~] using signals. 'Audio interrupt' is set to 'ON' and the [snapshot~] offset is not set to the Signal vector size -1, so the conversion will be wrong.

As you discovered, audio Interrupt status plays important role

when it comes to jumping between signal and non signal 

I mostly keep it deactivated, as it also adds to CPU usage,

But best practice is to stay as much as possible in one or another

in your case, you have both values available at same time, and so there is no need for conversion.

If you needed to convert table~ output in addition to signal out, I would again rather create numeric list of it's values, and scroll through the list

using same progress as one used to drive table~ .

As you discovered, audio Interrupt status plays important role
when it comes to jumping between signal and non signal 
world.
I mostly keep it deactivated, as it also adds to CPU usage,
not only timing issues.

But best practice is to stay as much as possible in one or another
world.
in your case, you have both values available at same time, and so there is no need for conversion.

If you needed to convert table~ output in addition to signal out, I would again rather create numeric list of it's values, and scroll through the list
using same progress as one used to drive table~ .








Help: converting signal values to numbers in a [phasor~] based sequencer