Is there a maximum number of automateable parameters in m4l?

[misal]

I'm building a stepsequencer which consists of 16 steps x 8 tracks and other parameters (in total 162 parameters). All parameters are set to 'automate and store'. When i load more than two instances of this stepsequencer, some of the toggles don't react anymore.

Has anyone encountered this problem as well?

Live 8.2.6, Max 6.0.2, iMac OSX 10.6.8

[Machinate]

so you're automating each individual step value in Live? Mind if I ask... why? What I typically do is automate the state of the entire sequence, not each step. Typically that'd be like a live.something connected to pattrstorage.

Just trying to grok the patch a bit.

[misal]

What I typically do is automate the state of the entire sequence, not each step. Typically that'd be like a live.something connected to pattrstorage.

So how would you do that? I can collect the state of all toggles as a list. But then? I mean, the pattrstorage has only "stored only" as visibility-option.

[Machinate]

What I typically do is automate the state of the entire sequence, not each step. Typically that'd be like a live.something connected to pattrstorage.

So how would you do that? I can collect the state of all toggles as a list. But then?

I'd advise you to delve into the world of the pattr - you'll find that there is no need to collect the state of these toggles into a list; that is what the "storage" part of pattrstorage handles.

I mean, the pattrstorage has only "stored only" as visibility-option.

Yes, I am suggesting "opening up" a live.dial or similar to automation from Live, and using that dial to load - or indeed, interpolate between! - presets stored with the pattrstorage/autopattr combination of objects

[misal]

Thanks for your replies!

The problem is, that i am constantly controlling the steps with the lemur on ipad. What i want, is to capture all these changes so they can be automated and adjusted later on. These would mean, if i understand you correctly, that i would have to store all changes in a new preset in pattrstorage. These would result in possibly hundreds of presets, which would be recalled at the corresponding play-position in the liveset.
Is this what you suggest? Is this no problem for live, to handle so many presets?

[Machinate]

ah, see I didn't know that

Well, if you want the complete performance played back like that and then manipulated later on, you're - in my mind, of course - generating too much data; it'd be a mess rooting through it.

I'd either:

a) Make your patch midi-capable, and record the midi from it into live, and then later edit the midi notes generated.
So your patch generates a midi sequence, and that's your raw material moving forwards.

b) Set up a recording system inside your patch; something that'll record to your hearts desire - I'm thinking [mtr] or similar, I know there are osc message recording systems for max as well, and then use [transport] - which you're presumably already using - to derive your playback position along the way.

This is an interesting problem though - I'm certain there are some truly elegant solutions to this. I'd lean towards simply - *simply* getting the midi data, and then using that as it is.

Whatever you come up with, I'd love to try it out on the lemur.

[broc]

You can reduce the number of parameters by representing each column as an 8-bit value, ie. number 0-255.
Then you need only 16 parameters (number boxes) to automate the 128 sequencer toggles.
Here is a patch that I've used in a similar situation.

<pre><code>
----------begin_max5_patcher----------
1292.3oc6bFsaihCEF95jmBTzr2roSWrM1.6c69.rWt2DUUQBNsdFhcD3zsy
NZd2WvFRIcfTGBwvJgpDzZ6.+9ii+OFGnee9rEqEuRyV376NqblM66ymMSUT
QAyJ+6YK1E85ljnLUyVrQraGkKWbmtNI8Uop7fOulIc96njCzp51J3xL1+RK
pG3duaYw6ijadlwe5wT5Fo9TiBg4U6.CHE6Hpsff6ccdn7yvOriwSnRkF.kE
xhUmYw5u7Yj6h2Zo3frpot0jBOZmRJK9iTVThyeJRhWTT6OlOuXycWI.9qC6
VSScbu+dHF2EDn50HEHBfWLAfAVi.b5+jeF+I.rOktmxicxnGgiVGxusmp6j
KVbr+XNY.XeEYBQpfC+KFM.PynAXMz7KNvVQBKOVp6TAhcKCavmiJvFBXHCM
U9sa.UBU3.5E1Up3O7wJd8NU7wJp.76JU7F9XkdmJPv0RE7vGqDz6Tw0Uav1
Yp.G9Xk9mJn.MUHckJngOVAP5cr.UCgpxPiNep4lvh6vGrbCvBQSBbmiVFAy
XA06Imgd5AQPuNFs.BF9nka.VBA0wxkGs.BG9nER+md1WEfnuyvtDr3O7AK8
OUPfvZToCwJjQPdHXumeF4pu4P8PnvKOXAOBxCcCvBFVCKcXLj8l2eB6E584
mkhVUdzeIJ83AuV0q.Oz95KbmyhsIhnZzpcrfzXQuZS3KYAENNYt8Qo4JTRS
ejxiVmPq+ANEYUzMK5EZ7iQRYJa8AI8seKqDNkzon6mbfJ1VUbU40OoIB9Sm
GQmz7ch37NlZUgphZN8vw3es3vUegi9oCfHl1V0L9VgRJMcxOvYZRzXshzXZ
ZaG2X511qLaOkFmv1oPeicqLIcu9Z.lzP0zW2K3EqnWqG.F+EVFq7xqaa8M4
2ZuAQbtPFIYB9iGud03Un7wDZkhaTI6N60upABfF6CLY93yZwoMhpmEoxlhn
ZKbRKW.L+F.zMPMruZWOsvhQe0gc5O2jEXDpmdJ.c9rpAMXHL32FSdPbpymX
fkve8SL3Ru7snkA4a8VBH46vKQE0PVRJpxeYdxl78A2DNRJWLe2ymuoANFZ2
zMRwSOkPaMcit5U9OX.kZLKCRygvpDLWXZlfKOKCvNYYdOYlxxTKKSSURyuL
UFyH1tsXVJB9wfmaZ1HPejNBbEIif8YxnSFwdaSFcANDjt5P.uRGB+wtCAYx
gXxgXxgXEtiNDP8SEP2cHHicGB7jCwjCwjCwJut5PnefX5tCAdr6P3M4PL4P
L4PrB0UGBOv04P3M1cHPSNDSNDSNDqfc0g.bkyg.M1cHfSNDSNDSNDm8qN+b
NDfvqbNDvwtCwz2X9jCwjCAsi1C3qbBDfQt8vj2vj2v+y7FTTO+nwe+62oZ7
aQ4mZXjINjtoZzd0S4lyaCgioYRFWAy5Mx6jF8LKNlxq+dGtiEuWv3xRQ37P
i1W8qlvVUSEuHcerlrqj7MPRP6JIOSjDYDpIe6pInIZxxQ3XCzDZDhI6ZNAM
wbxxRx0DLAGgZxtgSEuYQerlbsKm.FnI7HDS1MWWwa+zGpI6lWAXR522wxwg
lBsqlLIuBvt4eAlLaN+QHlrbHtIScxxQ3ljWwtA3lXWpjsu0jjuoRhXMIQLU
RXqIIroRxyZRxyTIgrljPlJIn8lzjoRBXOeISkj87kLYJS.KOMNivzEdWA.B
o3c4xS+b1i0+2p3z+R+9TiH.0K8UXwZVexhnM+Gy+OTFPLyM
-----------end_max5_patcher-----------
</code></pre>

[Machinate]

ah yes!

I wonder how many people have made their own bin2dec, dec2bin abstractions? I certainly found it plenty frustrating to do these cascades of objects over the years.

cheers for that.

[misal]

Thanks Machinate and broc.

Yes, the idea of representing the rows as 16-bit value came in mind, too. This way i even have only 8 parameters. I think i will go this way.
Thanks for your patch, broc. Is there no object, which translates binaries to decimals and vice versa?

[Machinate]

well, here are my humble things:

http://dl.dropbox.com/u/12606333/aw.binarylist.maxpat

http://dl.dropbox.com/u/12606333/aw.dec2binary.maxpat

aw.binarylist is a lot more elegant - it'll take any length of binary lists and output the proper dec.
aw.dec2binary is set up for 8-bit, but can easily be expanded, of course.

If it could be done inside [vexpr] then that certainly would be a simpler solution.

[misal]

That's great, Machinate! Thanks for sharing.

[Machinate]

anytime I'm working on a snazzier version of the "to-binary" one right now. I'll post it here when/if I can suss it tonight.

[Machinate]

ahem. Okay, that wasn't as hard as I'd remembered it - on the recommendation of the cycling folks a while back, the fastest way to do a "for" loop is to use uzi. So I did.
This one is somewhat slick - set the argument to however many bits you want out of it:

This replaces aw.dec2bin

http://dl.dropbox.com/u/12606333/aw.decbinlist.maxpat

hope this works for ya

[Machinate]

OH, and while I remember it:

Now you can easily switch your setup to use live.step instead of toggles, greatly reducing complexity in your patch

[misal]

Now i'm blown away! i mean, i never liked live.step, but now i see some real usage of it. It might really simplify a lot of what i'm going for.
Thanks again, Machinate.