Axiom-Crux

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?

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?


buffer-multislider

> cant figure out how to get a buffer back into a multislider. Anyone

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

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

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

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

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.

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.


here's probably the best way to write in a buffer with a multislider...

> 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 

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.

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.

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.


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

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:::

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.

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

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.

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.

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? 
----------------------------------------------------

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.

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

> heres what I was doing with it, again thanks jmb.. not sure why I didnt'

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.

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
www.timara.oberlin.edu/GaryLeeNelson

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 ;-)

> 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 ;-)

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

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
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson

> 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...):

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...):

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


> 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)

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)

buffer > multislider