Help: converting signal values to numbers in a [phasor~] based sequencer
Hello!
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.
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!
Here is the demo-patch in question:
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 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.
'Audio interrupt' is set to 'OFF':
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'.
'Audio interrupt' is set to 'ON':
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
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~ .
Got it! Thanks!
I'm having a similar issue with a M4L sequencer I'm making. Since I'm using a [what~] based approach to generate percussive flourishes at arbitrary intervals, I don't have convenient access to the step numbers from [subdiv~]. My approach is that I'm feeding the pulses from what~ into an accumulator [+=~] to generate velocity values. However at some point I'll have to convert these signals to actual numbers so they can be received by a [makenote] and there I run into the problem Valery describes, where the values are out of sync with the notes.
I have both scheduler overdrive and audio interrupt enabled, still the issue persists. Does anyone have a solution here or is this where I pay for the upgrade to full Max so I can rebuild this in gen?
gen~ will also not help you because the conversion from audio signals to midi will happen outside of gen~ with the respective vectorsize.
i know that it is tempting to make sequencers based on plugphasor~ in live, but creating timed events using both signals and messages will always be bumpy, so just don´t do it.
if you like to think in "phase" you can also do that using [metro] and [line]