input values into multislider smoothly

Feb 8, 2014 at 7:36am

input values into multislider smoothly

Hi,

Ive got the following patch which uses phasor and a dial to input values into a multislider. The problem im having is to get the “pak” object to continuously put values in. Is there some kind of threshold in multislider that I should be aware of?

<code>

– Pasted Max Patch, click to expand. –

</code>

#280409
Feb 8, 2014 at 7:57am

From looking into this a bit more it seems a problem actually with the Phasor object, in that it has quite a low resolution. If I try to scale it up to 5000, the phasor will not hit every single number on the way up to 5000.

Just wondering if there is a way to get phasor to output every number from 0 to 5000 when using the scale object?

#280413
Feb 8, 2014 at 12:37pm

I don’t know much about MSP at all but I don’t think the phasor~ object is the problem.

It looks like you got the range/size setting mixed up on the multi slider. You have the size set to 128 with a 1-5000 input – and the range set to 5000 with 0-127 input. So that’s probably all it is.

But that dial object… man.. I hate that thing. If I want continuous values, even just in the range of 0-127, I have to make it 2 or 3 times larger than I would ever want it in a UI. It’s like finding one of my little brother’s jumbo lego blocks in my box of legos.

Try live.dial or a single multislider for smoother output.

– Pasted Max Patch, click to expand. –
#280427
Feb 8, 2014 at 1:26pm

See what you mean, but I tried live.dial and its only marginal improvement. The problem seems to stem from the fact that Phasor is not setting every slider out of the 5000.

So if I have phasor is scaled like so

[scale 0. 1. 0 5000]

Then when the multislider is being set there are values missed. Some of the sliders are set above 0 and some are not. If I read the multislider with a phasor much slower, the dial jumps back to 0 every other slider or so.

Is there any workaround for this I wonder???

#280431
Feb 8, 2014 at 3:51pm

The problem seems to stem from the fact that Phasor is not setting every slider out of the 5000.

The phasor object outputs discrete values. These might not always be consistently the same values per cycle (depending on frequency). You might have referred to that fact with “low resolution” in fact it doesn’t have what I would consider a low resolution. It has 44.1 Khz (or more) time resolution and don’t shoot me if I’m wrong, 64 bits?
You are essentially resampling it with the snapshot object. down to a sampling rate of 1000 Hz.

Why not stick to max objects? why do it with a phasor?
The version below tries it with max only. Scheduler intervall minimum of 1 ms limits us to 1000 values a second, therefore it doesn’t quite work.

Or, better question: why not do it in MSP completely? [poke~], [buffer~], [plot] for GUI.

#280437
Feb 8, 2014 at 3:52pm

<code>

– Pasted Max Patch, click to expand. –

</code>

#280438
Feb 9, 2014 at 5:09am

Hi WOYTEG,

Thanks for the suggestions. The reason Im using phasor is because I have it synced to transport. Im wondering is there any way to get metro to put out 1000 times more bangs in time with transport when synced?

#280470
Feb 10, 2014 at 5:08am

Im really struggling with this now. Basically I need to be able to count from 1-5000 in sync time with Phasor, but I havent found a way to do it yet. I cant use scale, because it will only scale the numbers that phasor gives it, rather than all the numbers from 1-5000.

Anyone know how to do this?

#280588
Feb 10, 2014 at 3:27pm

Like I said, I don’t know much about MSP, but I’m learning so I took a closer look at this. You can bang a counter every time snapshot~ outputs a value from phasor~. That will count in sync with phasor~.

The rate at which values are output from snapshot~ depends on the length of the signal vector (the list of values that makes up the signal data in a given frame of time). The smaller the vector length, the faster snapshot~ can output values. iow, to count to 5000 based on the value output of phasor~/snapshot~, you may want to lower the signal vector so that it doesn’t take too long. With a signal vector of 512, it will take about a minute to get 5000 values… but only about 2 seconds with a signal vector of 16.

At least that’s what seems to be the case.

Hope that helps.

– Pasted Max Patch, click to expand. –
#280649
Feb 11, 2014 at 2:18am

hmmn, interesting way of doing it thanks metamax :)

I had thought it might be possible to match the samples/vectors coming out of phasor, but wasnt sure how. Your example shows how to do this quite well. However, it turns out I cannot use [snapshot 1] because it’s far too expensive on CPU, so Im back to the drawing board again. It also seems that snapshot vector size is not small enough to deliver 0-5000 in the time it takes phasor to go from 0.-1.

As it stands now, I have had to dump phasor and use metro->transport in it’s place. I would love to find a way to use phasor, but it just seems impossible :/

#280690
Feb 11, 2014 at 3:09am

Yeah. It seems that Max and MSP are very different beasts.

Have you looked at count~, mstosamps~ and sampstoms~ ? You might be able to get something going with one or more ofthose.

#280693
Feb 11, 2014 at 3:22am

HI, didn’t read everything here(sorry, bad habit) but this helps I hope.

#280697
Feb 11, 2014 at 3:24am

lol, we can’t upload maxproject snapshots for securuty reasons..
btw. I hope there is a more intelligent way of doing this than upsampling, but I couldn’t think of any.

host patch:

<code>

– Pasted Max Patch, click to expand. –

</code>

polypatch: (save as ms_to_buf.p.maxpat)
<code>

– Pasted Max Patch, click to expand. –

</code>

#280698
Feb 11, 2014 at 3:35am

[EDIT] – Ahh i see I have to save the patch for the poly to work. This is incredibly smooth curve . Im gonna have to spend some time getting to know these objects, because im not quite sure how to get the values from buffer (the curve values and also the timeline) in order for it to drive a dial.

[IGNORE]
hmmn thanks woyteg, unfortunately though I couldnt get the patch to work.
Is the transport object supposed to be connected to something?

#280700
Feb 11, 2014 at 4:16am

You want to drive a dial from that? hm, my solution works, but is abit overkill I think.
At the moment I’m thinking about all that a bit more. I got the impression that given samplerate, aplitude, increment(1) and frequency we kind of seem to have a problem without bruteforce, but I’m not sure.

#280704
Feb 11, 2014 at 4:18am

Ultimately, I think you should head for a smaller samplerate of your buffer(the multislider, give it less sliders) and interpolate on query.

#280706
Feb 11, 2014 at 4:23am

newtfish, save the polypatch as ms_to_buf.p.maxpat in your search path.

Add an ezdac~ to the other patch and turn it on. Then move the slider. It’s pretty sweet. Definitely better than anything else offered…

#280707
Feb 11, 2014 at 5:06am

To quote myself:

I got the impression that given samplerate, aplitude, increment(1) and frequency we kind of seem to have a problem without bruteforce

That’s baloney. Still thinking about it..

#280712
Feb 11, 2014 at 5:21am

now this makes most sense to me. variable resolution, maximum resoltuin within the max domain, synced etc. for 120 bpm it makes a resolution of 1920 values. not enough? you’ll hav to go MSP. But you won’t be able to make a dial move faster/higher res than that I think.

<code>

– Pasted Max Patch, click to expand. –

</code>

#280714
Feb 11, 2014 at 5:23am

What are you ultimately trying to achieve?

#280715
Feb 11, 2014 at 6:08am

Sorry for spaming this thread a bit. I’m very interested ins scheduler, sampling rate blabla at the moment. here is a patch that calculates how many events max can take per bar for a given scheduler rate. for 120bpm, a scheduler rate of 1, it’s 2000 events. so the above example is pretty close to what max can do. It only has 1920 events because it’s based on clock ticks rather. And that’s because it makes syncing things more simple.

<code>

– Pasted Max Patch, click to expand. –

</code>

#280717

You must be logged in to reply to this topic.