lefauxdjaber

I looked but couldn't find anything about this:

You can only have up to 20 functioning snapshot~s in a m4l patch. Once you get past 20 the earliest one is deactivated and the newest one is activated. That pattern continues so on.

The below works fine in a new patcher and in standalone but behaves as described above when put into an m4l patch.

EDIT: I found that increasing the reporting interval allows for more snapshot~s to work. Why is this?

EDIT2: Just found that increasing poll throttle in preferences allows for more. Can one of you enlighten me? Why would that be an issue in m4l but not in standalone?

EDIT: I found that increasing the reporting interval allows for more snapshot~s to work. Why is this?
EDIT2: Just found that increasing poll throttle in preferences allows for more. Can one of you enlighten me? Why would that be an issue in m4l but not in standalone?


limitation-on-quantity-of-snapshot

I'm concluding that snapshot~ is just jacked up.

Somehow it starting working in one m4l patch, but doesn't work in others.

The way it started to work in the original patch I was having issues with appears to be just random.

I had tried to reboot max, live, and the computer with no results. So I open chrome and start researching and reading about what could I do to fix this.

Hours later I go back to Live, which was still open from the last time it didn't work and to my complete astonishment, it worked! All 32 snapshot~s worked. Weird, whatever. I do a reboot of my computer to see what happens and then it didn't work anymore. So then what I try is to close Live, reopen Live and load a new m4l audio patcher in a track. I open editing mode and then close the patcher window and but keep max open. I then load the project I was working on that has the 32 snapshot~s and boom it works. It's been working since. Now though, on other tracks I'm building other patches that need to use snapshot~ and they don't work for other tracks but it works for the original patch.

I'm thinking I may just need to re-install max?

It works now, but not really.
Somehow it starting working in one m4l patch, but doesn't work in others.
The way it started to work in the original patch I was having issues with appears to be just random.
I had tried to reboot max, live, and the computer with no results. So I open chrome and start researching and reading about what could I do to fix this.
Hours later I go back to Live, which was still open from the last time it didn't work and to my complete astonishment, it worked! All 32 snapshot~s worked. Weird, whatever. I do a reboot of my computer to see what happens and then it didn't work anymore. So then what I try is to close Live, reopen Live and load a new m4l audio patcher in a track. I open editing mode and then close the patcher window and but keep max open. I then load the project I was working on that has the 32 snapshot~s and boom it works. It's been working since. Now though, on other tracks I'm building other patches that need to use snapshot~ and they don't work for other tracks but it works for the original patch.

I'm thinking I may just need to re-install max?


Just re-installed it and it reverted back to only having 20 snapshot~s respond. Someone please help me before I hurl my computer from my window.

got the other m4l patch to work by opening edit mode, then open from clipboard the patch from above, then copy and pasting it to an m4l patch. Didn't save. Then re-opened the other project and the 32 snapshot~s work now, but no other ones from any other patch will.

Yeah I can confirm some weirdness. Upping the reporting interval to 20, I was able to make 64, but had massive framerate drop/general slowness

But my question is why do you need all those snapshots operating at 1 ms, controlling a ton of gui elements?

I was thinking about increasing the amount btw. I have some other ones going to volume faders and 10ms seems to work well. I started low and was going to increase to find the best ms amount. Would you happen to know the highest value I could go that’ll still make the movements of parameters and faders appear seamless? I’m just worried that when I go into the subpatches that I’ve previously setup with the 1ms snapshot that they will stop working again if I modify them (which is what already happened).

Why am I using so many to control just gui elements?

Am I using so many because I'm trying to control a ton of gui elements?

Also, what's your question
Why am I using so many to control just gui elements?
or
Am I using so many because I'm trying to control a ton of gui elements?

to the first
because I'm not sure of another way

Do the knobs do anything or is this just to visualize audio data? I am wondering what your goal is other than to have a ton of snapshots and ui elements just for the fun of it.

I doubt you'll need to have your snapshots any lower than 20.

You could use a ui object that is designed to work with audio signals.

Do the knobs do anything or is this just to visualize audio data? I am wondering what your goal is other than to have a ton of snapshots and ui elements just for the fun of it.
I doubt you'll need to have your snapshots any lower than 20.
You could use a ui object that is designed to work with audio signals.


I agree with Evan. Just keep you audio signal in the audio world (ex: number~ doesn't need to be preceded by snapshot~, it already embeds it own snapshot~).

Use a snapshot~ just for viz, why not, but keep the refresh rate just enough for the UI to look fluid to the eyes.

I agree with Evan. Just keep you audio signal in the audio world (ex: number~ doesn't need to be preceded by snapshot~, it already embeds it own snapshot~).
Use a snapshot~ just for viz, why not, but keep the refresh rate just enough for the UI to look fluid to the eyes.


I may be missing something but I'm using msp objects to create ramps that then go to knobs that are midi mapped that then go to locations that are modifiable via a set of menus that are accessed via keyboard shortcuts. At some point or another I'll have to use snapshot~ to control the knobs that I physically use (right?). I'm not using number~, the ramps being generated go to snapshot~s then to the knobs I'll physically use (plus I found that when I try to put number~ followed by snapshot~ it doesn't work. Not sure if that's normal). Side note, I tried using objects such as the line object but it ended up causing huge spikes in cpu load (like 35-45%). So I'm going with snapshot~s. So far with everything said and done I'm only getting bumps of a few % (if that. I am at a constant 4-5% though which is ok as I'm using two computers simultaneously so I can afford it). If I increase the interval of the snapshot~s (to 20ish as you've suggested) then I should be able to get even better results, I just haven't had the chance yet (or the balls) to crack open those subpatches to access the snapshot~s because last time I did that, it made them not work.

Given this though, is there a better way to do this? (I'm not an max/msp expert, only going on 1.5 yrs experience so I'm all ears to ideas)

I may be missing something but I'm using msp objects to create ramps that then go to knobs that are midi mapped that then go to locations that are modifiable via a set of menus that are accessed via keyboard shortcuts. At some point or another I'll have to use snapshot~ to control the knobs that I physically use (right?). I'm not using number~, the ramps being generated go to snapshot~s then to the knobs I'll physically use (plus I found that when I try to put number~ followed by snapshot~ it doesn't work. Not sure if that's normal). Side note, I tried using objects such as the line object but it ended up causing huge spikes in cpu load (like 35-45%). So I'm going with snapshot~s. So far with everything said and done I'm only getting bumps of a few % (if that. I am at a constant 4-5% though which is ok as I'm using two computers simultaneously so I can afford it). If I increase the interval of the snapshot~s (to 20ish as you've suggested) then I should be able to get even better results, I just haven't had the chance yet (or the balls) to crack open those subpatches to access the snapshot~s because last time I did that, it made them not work. 

Given this though, is there a better way to do this? (I'm not an max/msp expert, only going on 1.5 yrs experience so I'm all ears to ideas)


it is amazing how many 20 years old objects still dont work properly.

but in this special case of snapshot i would recommend to find another solution anyway. snapshot is very expensive both for the signal processing power it takes as well as in a scheduler context.

what are you doing? would it be possible to stay in the signal domain mb?

I think that Roman is squarely on the money here, and it bears repeating: "snapshot~ is very expensive both for the signal processing power it takes as well as in the context of the scheduler." Audio rate everything and minimal updates for the UI rule.

At some point or another I’ll have to use snapshot~ to control the knobs that I physically use (right?)

One thing remains: What exactly are you trying to do? Why do you need to control knobs with audio rate signals in the first place?

You're MIDI mapping TO the knobs, or FROM the knobs? I'm just sure there's a better way to do this.

Also, you could make one of those knob constructions into an abstraction and use them in bpatchers, that way updating one snapshot value will update them all. Save you a ton of time.

At some point or another I’ll have to use snapshot~ to control the knobs that I physically use (right?)


No? Why would that be the case?
One thing remains: What exactly are you trying to do? Why do you need to control knobs with audio rate signals in the first place?
You're MIDI mapping TO the knobs, or FROM the knobs? I'm just sure there's a better way to do this.
Also, you could make one of those knob constructions into an abstraction and use them in bpatchers, that way updating one snapshot value will update them all. Save you a ton of time.


well, reading back, if he wants to control GUI elements or external hardware he of course needs to come from signal to messages at one point.

but as a first step to get it to technically work better i would try to

- dont use exactly 40.0 ms for all instances of the object but set slighty different values

- put a [defer] behind all of them (no idea if it makes a difference, just guessing here)

 - go up to 40 ms, not 20
 - dont use exactly 40.0 ms for all instances of the object but set slighty different values
 - put a [defer] behind all of them (no idea if it makes a difference, just guessing here)


Ah, so he wants the knobs to control external synths, but also be able to modulated by an audio source?

Sorry, wasn't clear to me initially ;) what Roman said.

Ah, so he wants the knobs to control external synths, but also be able to modulated by an audio source?
Sorry, wasn't clear to me initially ;) what Roman said.


oh wow i now looked at his patch, he is using 1 millisecond snapshots! :)

in this case the dial object might be half the reason for the issue, yet it remains true that snapshot or zerox are problematic as well.

oh wow i now looked at his patch, he is using 1 millisecond snapshots! :) 

in this case the dial object might be half the reason for the issue, yet it remains true that snapshot or  zerox are problematic as well.


i´d remove the snapshot object at all, and add a parallel branch with a non-msp [line] to control the knob.

Roman: you got it, the knobs are midi mapped and the ramps go into those knobs and then those knobs go to various places that I can select in realtime. can you expand on the not using all at 40ms. am I understanding that doing them at different intervals will help spread the load to scheduler (roughly)?

I tried [line] and it was bumping my cpu 35-45% (where snapshot has it constantly at 4-5% with a 1% bump when I run shit). I dont know if that's normal or not, but it's what I got. I initially thought using the line object would be better than using signal rate, but it wasn't the case.

I dont think defer is necessary, right now with 1ms snaps I'm having no problems other than constantly running at 4-5%. so following your advice for spreading it out then I think i'll be golden, thanks!

Evan: I've been putting off learning about creating my own abstractions, thanks for the reminder, on it! thanks

Roman: you got it, the knobs are midi mapped and the ramps go into those knobs and then those knobs go to various places that I can select in realtime. can you expand on the not using all at 40ms. am I understanding that doing them at different intervals will help spread the load to scheduler (roughly)?
I tried [line] and it was bumping my cpu 35-45% (where snapshot has it constantly at 4-5% with a 1% bump when I run shit). I dont know if that's normal or not, but it's what I got. I initially thought using the line object would be better than using signal rate, but it wasn't the case.
I dont think defer is necessary, right now with 1ms snaps I'm having no problems other than constantly running at 4-5%. so following your advice for spreading it out then I think i'll be golden, thanks!

Evan: I've been putting off learning about creating my own abstractions, thanks for the reminder, on it! thanks


"I tried [line] and it was bumping my cpu 35-45%"

i can use hundreds of line object on my computers, of which some are 32 bit processors with 500 Mhz.

the main point on thinning data out here is that when your aim is a physical midi out, the bandwith of the midi connection is much lower than what you were doing with these 1 ms generators.

midi is a serial protocol and it will never send 16 controller/value pairs within the same 1 ms anyway, so there is no need to generate this much data.

another problem with your original design was that all 16 signal chains around snapshot were running all the time, i.e. also when not needed. this is one more reason why i would try to avoid using messages AND signal to generate the ramps.

yes, i meant use 40.0, 40.1, and 40.17, so that they dont have to process all within the same millisecond and/or audio vector. you wont notice the difference later in your hardware synth or whatever it is.

the main point on thinning data out here is that when your aim is a physical midi out, the bandwith of the midi connection is much lower than what you were doing with these 1 ms generators.
midi is a serial protocol and it will never send 16 controller/value pairs within the same 1 ms anyway, so there is no need to generate this much data.

yes, i meant use 40.0, 40.1, and 40.17, so that they dont have to process all within the same millisecond and/or audio vector. you wont notice the difference later in your hardware synth or whatever it is.


I started working on other patches so I haven't had a chance to rework some of these things, but the version I completed before moving on works, it may be a little expensive but it works without much of a problem. I did just quickly check the lines object and made a test patch with hundreds and it didn't cause any problems. Wonder why in my original patch it was causing issues. Ideas?

I wasn't aware that the snapshot~ object could accept values smaller than 1 ms. Is that because it's a msp object?

I'm not sending anything to a physical midi output. If it's not staying in Live it's exiting via udp.

I'm appreciating the help though, thanks a ton

I'm not sending anything to a physical midi output. If it's not staying in Live it's exiting via udp. 

I'm appreciating the help though, thanks a ton


well, coremidi and ethernet are also serial and slow.

you were sending 16 messages every 1 ms in your patch. normally a modern computer should be able to accept this, but then youre in live, where everything in overdrive (the snapshot output is too). and this is not the only thing you are doing because you might use 90% of your CPU for plug-ins already.

plus, what is the worst, this causes the 16 dials to be updated also every 1 ms.

try 40 like i suggested and see what happens. if that does _not make difference, then there is a bug/limitation in the object.

you were sending 16 messages every 1 ms in your patch. normally a modern computer should be able to accept this, but then youre in live, where everything in overdrive (the snapshot output is too). and this is not the only thing you are doing because you might use 90% of your CPU for plug-ins already. 

try 40 like i suggested and see what happens. if that does _not make difference, then there is a bug/limitation in the object.


Maybe you misunderstood, I understand why line~ + snapshot~ is intensive. The one that was jumping 35-45% was the [line] object (no ~). That's what I initially thought was super weird before moving onto line~. Or are you saying the the line object (no ~) updates output every 1 ms? (I didn't think that was the case)

You can define how often the [line] object updates. useful for handling issues exactly like the one you are having. You don't need to be updating tons of UI elements every 1 ms. It's just not a practical use of resources.

You can define how often the [line] object updates. useful for handling issues exactly like the one you are having. You don't need to be updating tons of  UI elements every 1 ms. It's just not a practical use of resources.


Limitation on quantity of snapshot~