faster signal to float?

    Feb 15 2011 | 7:48 pm
    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

    • Feb 15 2011 | 9:26 pm
      Yes, check out the [Snapshot~] object.
    • Feb 15 2011 | 10:15 pm
      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?
    • Feb 15 2011 | 10:23 pm
      number~ has a minnimum update interval of 20ms, snapshot~ goes down to 1ms (maybe even less with the samples arg?)
    • Feb 15 2011 | 10:37 pm
      Yes, I noticed that. But like I said, even with the update interval set the same in both objects, there's hardly any difference.
    • Feb 15 2011 | 11:29 pm
      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.
    • Feb 16 2011 | 2:22 am
      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...
    • Feb 16 2011 | 12:43 pm
      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...
    • Feb 16 2011 | 8:36 pm
      Yeah, I was checking CPI in the task manager. Thanks for the heads up about the vector size thing though.
    • Apr 30 2017 | 4:42 pm
      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.
    • Apr 30 2017 | 4:53 pm
      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.
    • May 02 2017 | 1:05 am
      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.
    • May 02 2017 | 9:53 am
      maybe snapshot is more hungry in overdrive
    • May 04 2017 | 1:28 pm
      Sounds like whatever you want to do in JS you should just do it in Max, with plain signal objects.