faster signal to float?

TFF's icon

I've been using the right outlet of the number~ object to convert signal values to floats. But I assume that the UI aspects of that object slow down calculations some. Is there an object that can do this conversion without any UI stuff involved?

Best,
-Zach

MuShoo's icon

Yes, check out the [Snapshot~] object.

TFF's icon

Ah, thanks for the tip. I've been testing and it doesn't appear to be any more efficient though, even with the same update interval. Is this normal?

Mike S's icon

number~ has a minnimum update interval of 20ms, snapshot~ goes down to 1ms (maybe even less with the samples arg?)

TFF's icon

Yes, I noticed that. But like I said, even with the update interval set the same in both objects, there's hardly any difference.

Mike S's icon

Zach, you have your object?!

32 numbers~ with 20 ms update = 24 % CPU

32 snapshots~ with 20ms update = 11.2 % CPU

On my machine, I don't suppose yours is much different.As I've been learning lately, quick graphics updates can be very taxing on CPU.

TFF's icon

Hmm, yeah. I just ran tests again and the snapshot~ gave much better performance. about 17% CPU with 32 number~s and 4% CPU with snapshots instead. My computer must be screwy or something...

mudang's icon

Beware, that CPU utilization percentage in the DSP window will only show the time spend in audio routines (msp). With a message interval of 20 ms or so you will put a heavy load on the scheduler (max), which won't be reflected in DSP's % CPU.

Also keep in mind, that snapshot can only get one sample of the audio signal per vector size...

TFF's icon

Yeah, I was checking CPI in the task manager. Thanks for the heads up about the vector size thing though.

Roman Thilenius's icon

snapshot~ is working for me to convert signal to float at the sampling rate

are you sure about that?

would be interesting to see the scheduler settings for that setup :)

but I want to convert floats back to signal at the same rate. I don't think sig~ can work fast enough.

all signal objects procuce signals at signal rate. that is kind of their definition.

but from what i know, most signal objects will only update the signal with the beginning of the next vector when they are controlled by messages.

Jean-Francois Charles's icon

I'm not sure snapshot~ or number~ would give you several results inside of a given audio vector. My understanding is same as Mudang, you get maximum one value per vector.

I also agree with Roman: [sig~] is "fast", but the value generated by [sig~] is updated only "in between" vectors.

Not sure what you want to achieve, but it sounds like there should be other ways, staying in the signal domain.

Joey Hook's icon

Thank you both for your responses.

I was making an assumption about putting '1 samples' into the right inlet of [snapshot~]. I think I am beginning to understand what everyone is talking about now. I would only be getting every sample if I set my signal vector size to 1, which isn't a reasonable option, and doesn't seem to actually work anyway.

My goal is to send something through a [js] in order to do some matrix operations. I'm even less experienced with JavaScript than I am with Max, so I'm obviously struggling. My original thought was to convert a signal to float, send that through the [js], then convert it back to signal... mostly because working with a single float value in and out of the [js] seemed less complicated at first. Now it seems I'll need to send a signal through, or at least entire vectors, but I don't yet know how to do either on the Java end of things.

Roman Thilenius's icon

maybe snapshot is more hungry in overdrive

Jean-Francois Charles's icon

Sounds like whatever you want to do in JS you should just do it in Max, with plain signal objects.