Forums > MaxMSP

buffer > multislider

January 15, 2007 | 2:19 am

I noticed you can turn a multislider into a buffer quite easily, (IE the examples/sequencing/2-phasor-step-sequencer.pat) but so far I cant figure out how to get a buffer back into a multislider. Anyone know how to do this?


January 15, 2007 | 2:38 am

Nicholas C. Raftis III wrote:
> cant figure out how to get a buffer back into a multislider. Anyone
> know how to do this?

peek~?


January 15, 2007 | 2:44 am

To keep track of multi-slider changes, you could start experiments with a preset object, then with a coll, etc.

Bye,
Philippe


January 15, 2007 | 2:44 am

thats the object I used to make the multislider into a buffer, I need to do the opposite.


January 15, 2007 | 2:46 am

Did you mean, an audio buffer?
In that case, forget my post!

Cheers,
Philippe


January 15, 2007 | 2:47 am

Im not sure your understanding, I simply want to have a multislider and a waveform that are linked, so that anything I change in one affects the other. This has nothing to do with pattr or presets or coll. Its a matter of getting the data from a buffer into a multislider.


January 15, 2007 | 3:20 am


January 15, 2007 | 3:29 am

here’s probably the best way to write in a buffer with a multislider…

max v2;
#N vpatcher 10 59 699 558;
#P window setfont "Sans Serif" 9.;
#P window linecount 2;
#P comment 187 446 291 196617 as soon as you modifie the multislider with your mouse , it writes it in the buffer.;
#P window linecount 1;
#P comment 296 360 188 196617 don’t forget to set the buffer size in ms;
#P button 153 122 15 0;
#P newex 193 169 27 196617 – 1;
#P newex 153 145 50 196617 uzi 1024;
#P message 208 216 48 196617 fetch $1;
#P newex 193 340 106 196617 peek~ writethebuffer;
#P user multiSlider 208 239 187 68 -1. 1. 1024 2681 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P newex 305 340 162 196617 buffer~ writethebuffer 23.224319;
#P comment 206 147 291 196617 uzi argument must be set to the size of the buffer (in samples);
#P fasten 2 0 7 0 213 320 115 320 115 109 158 109;
#P connect 7 0 5 0;
#P connect 5 2 6 0;
#P connect 6 0 3 0;
#P connect 6 0 4 0;
#P connect 4 0 2 0;
#P fasten 2 1 3 1 390 322 246 322;
#P pop;


January 15, 2007 | 3:31 am

Nicholas C. Raftis III wrote:
> thats the object I used to make the multislider into a buffer, I need to do the opposite.

One of the things I like about peek~ is its versatility – it can read by
index (…~) too. Assuming your buffer~ and multislider have the same
number of elements, all you need besides peek~ and multislider and
buffer~ is either an individual slider set message for each sample or a
method of packing all the values into one list (see multislider docs for
both). I prefer the sample-by-sample update style as it tends to be
more flexible.


January 15, 2007 | 4:20 am

crazy, I had no idea that I was that unclear that I got the opposite of what I was looking for like 5 times haha. At any rate thanks JMB, thats exactly what I needed.


January 15, 2007 | 4:27 am

heres what I was doing with it, again thanks jmb.. not sure why I didnt’ understand peak could do that:::

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 38 38 48 196617 loadbang;
#P newex 183 184 71 196617 unpack 0. 0. 0;
#P number 281 206 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 232 206 49 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 183 206 49 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 38 64 49 196617 set tamp;
#P user waveform~ 39 97 200 74 3 9;
#W mode draw;
#W mouseoutput continuous;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P button 62 329 15 0;
#P newex 102 377 27 196617 – 1;
#P newex 62 353 45 196617 Uzi 256;
#P newex 50 429 63 196617 pak set 0 0.;
#P newex 102 407 61 196617 peek~ tamp;
#P user multiSlider 50 456 234 84 -1. 1. 256 2681 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P newex 52 187 78 196617 buffer~ tamp 6;
#P fasten 5 0 3 1 107 402 81 402;
#P connect 5 0 2 0;
#P connect 13 0 8 0;
#P connect 4 2 5 0;
#P connect 6 0 4 0;
#P fasten 11 0 6 0 286 321 67 321;
#P connect 7 4 12 0;
#P hidden connect 12 0 9 0;
#P hidden connect 12 1 10 0;
#P hidden connect 12 2 11 0;
#P connect 8 0 7 0;
#P connect 3 0 1 0;
#P connect 2 0 3 2;
#P window clipboard copycount 14;


January 15, 2007 | 8:39 am

On 15 janv. 07, at 05:27, Nicholas C. Raftis III wrote:

> heres what I was doing with it, again thanks jmb.. not sure why I
> didnt’ understand peak could do that:::

Hi,

By the way, I would not recommend using pak in the cae, pack is
better. With the pack solution, you send out the list when the index
is received, with pak every time something arrives (the value of
peek~/expr, the index) the list will be sent with whatever the index/
value was. Look at the printed info in the Max window.

Best,
ej

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 347 244 32 196617 print;
#P newex 43 241 32 196617 print;
#P newex 383 172 62 196617 prepend set;
#P newex 383 151 51 196617 pack 0 0.;
#P button 349 29 15 0;
#P newex 349 64 45 196617 Uzi 256;
#P newex 424 123 160 196617 expr random(-100\,101) * 0.01;
#P user multiSlider 383 199 234 84 -1. 1. 256 2681 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P button 74 29 15 0;
#P newex 74 64 45 196617 Uzi 256;
#P newex 82 172 63 196617 pak set 0 0.;
#P newex 134 122 160 196617 expr random(-100\,101) * 0.01;
#P user multiSlider 82 199 234 84 -1. 1. 256 2681 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P connect 10 0 12 0;
#P connect 10 0 5 0;
#P connect 7 2 9 0;
#P connect 7 2 6 0;
#P connect 3 2 2 1;
#P connect 3 2 1 0;
#P connect 2 0 11 0;
#P connect 2 0 0 0;
#P connect 1 0 2 2;
#P connect 4 0 3 0;
#P connect 8 0 7 0;
#P connect 9 0 10 0;
#P connect 6 0 9 1;
#P window clipboard copycount 13;


January 15, 2007 | 9:36 am

Quote: Axiom-Crux wrote on Mon, 15 January 2007 03:19
—————————————————-
> I noticed you can turn a multislider into a buffer quite easily, (IE the examples/sequencing/2-phasor-step-sequencer.pat) but so far I cant figure out how to get a buffer back into a multislider. Anyone know how to do this?
—————————————————-

In one way, the waveform~ object in drawing mode could be seen as a multislider with unlimited size.

_
johan


January 15, 2007 | 12:39 pm

Your patch along with Dominic’s opposite make a very nice pair of conversion
utilities. Thanks to both of you. I made a modification in your use of pak
to construct a message. You pak sends two messages for each bang of uzi.
One when the result of peek~ arrives and one when the index arrives from
uzi. The first message is wrong because it uses the index from the previous
uzi output. It’s a programming style issue. The result is correct but there
is a small inefficiency. If you are doing lots of these with big buffers
and large multiliders this inefficiency can mount up.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 51 396 27 196617 t b i;
#P newex 38 38 48 196617 loadbang;
#P newex 183 184 71 196617 unpack 0. 0. 0;
#P number 281 206 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 232 206 49 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 183 206 49 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 38 64 49 196617 set tamp;
#P user waveform~ 39 97 200 74 3 9;
#W mode draw;
#W mouseoutput continuous;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P button 62 329 15 0;
#P newex 108 374 27 196617 – 1;
#P newex 62 353 45 196617 Uzi 256;
#P newex 50 429 68 196617 pack set 0 0.;
#P newex 108 404 61 196617 peek~ tamp;
#P user multiSlider 50 456 234 84 -1. 1. 256 2681 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P newex 52 187 78 196617 buffer~ tamp 6;
#P connect 14 1 3 1;
#P connect 14 0 3 0;
#P connect 5 0 14 0;
#P connect 5 0 2 0;
#P connect 3 0 1 0;
#P connect 2 0 3 2;
#P connect 8 0 7 0;
#P hidden connect 12 2 11 0;
#P hidden connect 12 1 10 0;
#P hidden connect 12 0 9 0;
#P connect 7 4 12 0;
#P fasten 11 0 6 0 286 321 67 321;
#P connect 6 0 4 0;
#P connect 4 2 5 0;
#P connect 13 0 8 0;
#P window clipboard copycount 15;

On 1/14/07 11:27 PM, "Nicholas C. Raftis III"
wrote:

>
> heres what I was doing with it, again thanks jmb.. not sure why I didnt’
> understand peak could do that:::
>
Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


January 15, 2007 | 4:02 pm


January 15, 2007 | 4:24 pm

On 15 janv. 07, at 17:02, jose manuel berenguer wrote:

> I absolutely agree with you and Emmanuel Jourdan on the disfunction
> of pak. Programing style matters are also important for me. When I
> answered It was really late in the night, here. In my message,
> there is another mistake. I standed that multislider only accepted
> 2^12 (4096) sliders. Actually, it only accepts 1000 (in max 4.6.2)

in fact, it’s a mistake from the inspector, it should clip at 4095
instead of 4096. Sorry to argue again ;-)

Cheers,
ej

#P window setfont "Sans Serif" 9.;
#P number 121 269 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 121 224 78 196617 mxj list.Length;
#P user multiSlider 121 53 258 102 -1. 1. 4095 2681 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P connect 1 0 2 0;
#P connect 0 0 1 0;
#P window clipboard copycount 3;


January 15, 2007 | 5:11 pm


January 15, 2007 | 5:18 pm


On 1/15/07 11:24 AM, "Emmanuel Jourdan" wrote:

> On 15 janv. 07, at 17:02, jose manuel berenguer wrote:
>
>> I absolutely agree with you and Emmanuel Jourdan on the disfunction
>> of pak. Programing style matters are also important for me. When I
>> answered It was really late in the night, here. In my message,
>> there is another mistake. I standed that multislider only accepted
>> 2^12 (4096) sliders. Actually, it only accepts 1000 (in max 4.6.2)
>
> in fact, it’s a mistake from the inspector, it should clip at 4095
> instead of 4096. Sorry to argue again ;-)

In 4.6 mine does clip at 4095. The first multislider is numbered 1 not 0 so
perhaps it should go to 4096.

>
> Cheers,
> ej

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


January 15, 2007 | 7:46 pm

Thanks all! Good work! :D


January 15, 2007 | 8:56 pm

Dominic Thibault wrote:
> here’s probably the best way to write in a buffer with a multislider…

This seemed to be the method to read, from the multislider. To write to
the multislider could be this (includes both ways…):

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 134 348 50 196617 listfunnel;
#P newex 134 370 61 196617 peek~ foo;
#P newex 134 236 60 196617 prepend set;
#P newex 134 214 50 196617 pack 0 0.;
#P number 152 130 35 9 0 4095 2 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 40 39 30 196617 read;
#P newex 174 170 27 196617 – 1;
#P newex 152 149 32 196617 uzi;
#P newex 174 192 61 196617 peek~ foo;
#P user multiSlider 134 259 234 84 -1. 1. 4095 2681 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P newex 96 109 66 196617 mstosamps~;
#P newex 75 86 87 196617 info~ foo;
#P newex 40 62 122 196617 buffer~ foo 92.879997;
#P comment 192 130 222 196617 < - max 4095 as the multislider has its
limits…;
#P connect 13 0 12 0;
#P connect 5 0 10 1;
#P connect 7 0 10 0;
#P connect 7 0 5 0;
#P fasten 2 6 3 0 146 106 101 106;
#P fasten 1 1 2 0 157 82 80 82;
#P connect 8 0 1 0;
#P connect 4 0 13 0;
#P connect 6 2 7 0;
#P connect 9 0 6 0;
#P connect 3 1 9 0;
#P connect 11 0 4 0;
#P connect 10 0 11 0;
#P window clipboard copycount 14;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


January 16, 2007 | 11:16 am

jose manuel berenguer wrote:
> I absolutely agree with you and Emmanuel Jourdan on the disfunction of
> pak. Programing style matters are also important for me. When I answered
> It was really late in the night, here. In my message, there is another
> mistake. I standed that multislider only accepted 2^12 (4096) sliders.
> Actually, it only accepts 1000 (in max 4.6.2)

No, it accepts 4095, if its set to 1000 and you want to change it to
4096 it will complain and rest on 1000, but with 4095 its happy (and as
it counts from 0 its size is actually 4096)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


January 17, 2007 | 6:59 pm


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