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?

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.

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

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.

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?

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?

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.

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

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.

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

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:

polypatch: (save as ms_to_buf.p.maxpat)

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

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.

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

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

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

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.

What are you ultimately trying to achieve?

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.