Forums > MaxMSP

efficient way to generate step sequence from phasor

January 28, 2009 | 11:38 pm

Hi all,

what’s the most efficient way to get from a signal in the msp domain to discrete steps ?

My approach:

signal (0..1) –> [snapshot~ 1] –> [* 16] –> [change], but I would think taking such frequent snapshots isn’t efficient.

thx


January 29, 2009 | 12:26 am

Perhaps something like this?

– Pasted Max Patch, click to expand. –

January 29, 2009 | 1:24 am

Quote: monohusche wrote on Wed, 28 January 2009 15:38
—————————————————-
> Hi all,
>
> what’s the most efficient way to get from a signal in the msp domain to discrete steps ?
>
> My approach:
>
> signal (0..1) –> [snapshot~ 1] –> [* 16] –> [change], but I would think taking such frequent snapshots isn’t efficient.
>
> thx
—————————————————-

I’d be happier with a bunch of >~’s and edge~, too, as per X37V.

I wrote a thing called Stepmetro that’s a modular implementations of this approach. It’s in the CNMAT MMJ Depot:

http://cnmat.berkeley.edu/downloads/

cheers,

mz


January 29, 2009 | 3:40 am

Not sure what you have planned for the triggers, but if you wish to stay entirely in the signal world, you might enjoy the MSP externals I posted on my share page:

http://www.cycling74.com/twiki/bin/view/Share/AndrewBenson

Best,
Andrew B.


January 29, 2009 | 12:40 pm

If you need audio-accurate sampling times, you may sample the signal on an audio clock with sah~, using the accumulated clock pulse as an index to poke~ a buffer. Then dump the buffer as Max events with uzi/peek~. Using a stereo buffer and a flip-flop logic, you can dump channel 1 while channel 2 is written.

If event sampling rate equals audio sampling rate/2**n, you may also use poke~/peek~ inside a downsampled poly~ and dump every sample.

Hope this helps.


January 29, 2009 | 4:21 pm

hi j.y.bernie,
this sound very interesting. I haven’t seen this way before. Can you post an example, please?


January 29, 2009 | 7:55 pm

you couls also use a seq~ with the folLowing cue in it:

0, id sixteenths;
1, 0. 1;
2, 0.0625 2;
3, 0.125 3;
4, 0.1875 4;
5, 0.25 5;
6, 0.3125 6;
7, 0.375 7;
8, 0.4375 8;
9, 0.5 9;
10, 0.5625 10;
11, 0.625 11;
12, 0.6875 12;
13, 0.75 13;
14, 0.8125 14;
15, 0.875 15;
16, 0.9375 16;

M

On Jan 28, 2009, at 18:38, Nick Laqua wrote:

>
> Hi all,
>
> what’s the most efficient way to get from a signal in the msp domain
> to discrete steps ?
>
> My approach:
>
> signal (0..1) –> [snapshot~ 1] –> [* 16] –> [change], but I would
> think taking such frequent snapshots isn’t efficient.
>
> thx


January 29, 2009 | 11:39 pm

This solution requires cambio~ from cnmat (http://www.cnmat.berkeley.edu/MAX).

_
johan

– Pasted Max Patch, click to expand. –

January 30, 2009 | 2:37 pm

Quote: i.te wrote on Thu, 29 January 2009 09:21
—————————————————-
> I haven’t seen this way before. Can you post an example, please?
—————————————————-

I know no simple way to pass from the signal domain to the events domain with enough time-accuracy, since both schedulers are distinct. Sampling with a Max clock (snapshot~) will not produce evenly spaced audio samples, unless Max Scheduler in Overdrive is on AND Scheduler in Audio Interrupt is on AND Signal Vector Size is low enough.

You may try this: sample a LFO with snapshot~ 1. Use the output to FM modulate a cycle in the audible range. The tone "copies" the LFO only when above DSP conditions are met.

cambio~ does not depend on Overdrive/Interrupt. From what i can see (and hear), it outputs 3 evenly spaced audio samples per signal vector. So, you are required to set Signal Vector Size = 3*(Sampling Frequency)/(events/sec you want).

It all depends on your application, how much events/sec you want, and how much time accuracy relatively to the audio clock you need.

There are two steps involved: downsampling and converting audio samples to events. As I needed both high timing accuracy and precise event rates down to millisecond to convert digital modulations to bits, I’ve tried using poke~/peek~ for the second step. Downsampling may be accomplished with sah~ (arbitrary sampling rate) or with poly~ (audio sampling rate / 2**n).

None is really satisfying since we need, at some point, to call Max’s scheduler (edge~). Again, there is a dependency on vector size, Overdrive and/or Interrupt. However, that was enough for me to get proper bit stream decoding (ever tried to program an UART in audio?). Here is the poly~ example. Wrap in a poly~ and send the message ‘down N’:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#N in~ 1;
#X comment (Signal) Input;
#P newobj 30 53 33 196617 in~ 1;
#P newex 254 153 32 196617 sel 1;
#P window linecount 2;
#P message 254 176 111 196617 ERROR downsample: signal vector too small;
#P window linecount 1;
#P newex 254 208 32 196617 print;
#P newex 254 131 27 196617 < 2;
#N out 2;
#X comment Sampling Rate;
#P newobj 379 275 33 196617 out 2;
#P newex 30 275 112 196617 buffer~ $0-DECIM 10;
#B color 5;
#P comment 221 71 61 196617 vector size;
#P number 216 86 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 169 204 57 196617 uzi 1 0;
#P newex 215 255 107 196617 peek~ $0-DECIM;
#B color 5;
#N out 1;
#X comment (Float) Downsampled signal;
#P newobj 215 275 33 196617 out 1;
#P newex 169 172 36 196617 edge~;
#P newex 30 255 112 196617 poke~ $0-DECIM;
#B color 5;
#P newex 81 127 82 196617 count~ 0 16 1 1;
#P flonum 379 86 57 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 188 39 54 196617 dspstate~;
#P comment 385 71 60 196617 samplerate;
#P connect 17 0 4 0;
#P connect 3 0 4 1;
#P fasten 9 0 3 1 221 118 158 118;
#P lcolor 15;
#P fasten 3 0 5 0 86 153 174 153;
#P connect 5 0 8 0;
#P connect 8 2 7 0;
#P connect 7 0 6 0;
#P connect 1 2 9 0;
#P connect 9 0 8 1;
#P lcolor 15;
#P fasten 9 0 13 0 221 118 259 118;
#P lcolor 15;
#P connect 13 0 16 0;
#P connect 16 0 15 0;
#P connect 15 0 14 0;
#P fasten 1 1 2 0 207 62 384 62;
#P connect 2 0 12 0;
#P window clipboard copycount 18;


Viewing 9 posts - 1 through 9 (of 9 total)