o.click~ with multiple address lookup like o.points.phase~

[kulpajj]

Rama and I have discussed this design question over the phone, but I am also leaving it here as a question.

Right now, o.points.buffer~, soon to just become o.points.phase~, has a middle inlet that receives integers as "address index or Id", allowing you to reference different addresses with the same prefix, e.g. /rhythms/0, /rhythms/1, /rhythms/2, etc. So when o.points.phase~ receives "2" it references /rhythms/2 and reads through that data.

Rama and I discussed whether o.click~ or o.num~ should also have a similar middle inlet allowing you to have /duration/0, /duration/1, /duration2, etc and reference which /duration address is referenced. This way, when sculpting musical phrases, there is some data, e.g. /rhythm/2, linked to a like-named and like-IDed duration, e.g. /duration/2.

Rama's chief concern as I understand it is that jit.buffer~ (upon which o.points.phase~ is based) has a maximum number of planes that can be allowed. This corresponds then to a maximum number of /duration addresses that would be allowed.

My main point is also that, ok, well then there are still a maximum number of /rhythm addresses that are allowed, so we might as well just see the design model through with consistency, and /rhythm and /duration will be linked by ID, appended to the address itself, and the middle inlet of o.points.phase~ and the time creation objects (o.click~ and o.num~) reference those IDs in like fashion. Again, if you run out of address buffer storage, then you would have anyway by your /rhythm addresses. It's very intuitive to link "thing-I-sculpted" (/rhythm) with "how-long-I-want-it-to-take" (/duration). And I think the lookup for ID of each should operate in a similar manner.

[ramagottfried]

I feel pretty strongly that adding extra inlets to o.click~ and o.num~ is unnecessary. o.click~ and o.num~ do very specific things, and you can easily get the behavior you want by patching the other objects together.

I think it's important to be able to thing with lists (row) just as much as a multidimensional array (row/column).

for example, see example patch below for two ways of recalling a value as notated as separate presets using o.points.buffer~ (soon to be renamed!), and outputting both the held value like o.num~ and an o.click~ version using change~ -> abs~ -> gate~.

note that the notation, or "interface", the way you specify and represent the value is different than the mechanics of looking it up.

----------begin_max5_patcher----------
1638.3oc6a0zihaDD8LyuBKeBTXY5uba6HsRIWx4bJWxLZTCzCi20XSrMSX1
Ua9sm9Cav.Fnwz.yrBocMCME8y0qKW0qKa99ccbGltfm657qN+sSmNe+tNcT
CIGnS4663NksXTLKWYlaB+eSG9E295OpfunPM7DVA++pFMY9znjXdg5afJGb
FqXzKQISdJiOpPinOb.nuCFRjuPTuAgF.bdb07jNunZhfkiFMVgn3r3SH+JH
mkwy4IErhnzj5HfzHnlaP4gkyudxKdaFWasadzjDVr6RCxKdKV8YttxA9wc2
IOz+znJ1v7lYJ3gXJjuuxc7aASEXDSg7IuiXpQuvRlvaKYQTthWaHqPyHKxU
IrJeT5rVeslGV9BDCV9xNnEPCzB8PzRnBCJpQZ4Z30zv.0oTH8DbaO2yYPdq
xbV4W5kyVk5j39gKKXkWCosNMH18iXFsRGGEfacJMzExw4eaLaTKyNUFM6Uc
7HtFEZmqQSGLJc5rzb9Vqb2qx4U7Wr36ARJFz+gjZiAkiAWeLjbLz5igkigW
eLhbLhbr3zzuNe18uI4DnLSErubFjeCgEOVyjERSjVHBDDWJH3qGqNkiiR3i
RmmnNu822BwyoIEOyFwqSpMr3f88pUPEQUgeP.s1Bjblxi9lZlfxz+lFVBNP
IEJPiME2XME4xynz3zLs0fAvff9a7BbeklqE1ydkO9ogySFGyeJlmLo3EEWQ
HMYvXVAqjc756DJgA5KOnnF0A4X.w5Cvf+gHhUP02WtZKBFzeUHza4eQ66DH
9ene4bKMmDr9zPTeQusldnMvJzPrfmNVd.CwBYArfFhE1BXgLDKRci.kXohn
ToDTG.9KC5PkVffMM4McXeAHqsBtFEuFGz5SRPKOIW6br9hQs+t9IHw4wOdk
.pggpNvln.To92DZsovMGsASQZSQaNZClh0lh2bzFLknMkr4nJSarvj3JkSu
xTXft5PHYfLlQu4UjreBmbkI3g1CHVq51ymdkpLQvzaUltUY5JVY5DhM1nb0
YM7HXqBO6BNKELZpyAsIbWBmyCXtygrIbWDmCZtygsIbWDmCYtyQrIbG14Zo
JM9hYYBoZi4RC2Tp1T1rtNOj33DylNbLqKqu5cNNhuezjjtre4A26e6A29Nu
xhmy6x54zq+1VrPZAnm7C502YBufMdrPMPNOuqXvdMJrgtud6XptFjtMsTsf
Frt6k.vwpqA0ftlCcKSvTklJOng5ZpYzATz7Gyii+S1nuxKDrZ820pH.gmNj
ms+NMYHc6S0MtFAkxH8na0dsVS1K09NUDnt4YVBaptSU+dVDK9.KKPc2WnP7
QcOGDD8yworhZpIilnnikdwYoQmBTN5tbFPzLOFHWFv3iuKmPnYrnG55batT
grsjVfA9pnSvAnklBCW172YrLQPWAO6IdBaX75WXrWJiDX3M6RFxMjkL4L2I
cQP8XELGIaVlZUu4MJnEwX3CDigJuKE3PyHLaRVWwlWzXwPqrIe8Jldy8POE
q5GXis36Y3JYf+UZK9Puaaw+1V7u3awuc5wZNO8TnWvfzAyRiDWjNX37meVH
ZyYU1CmeKIMaJK9oE6nQgnlRgfOnXNjOU2SPr9FkuyT7zFRLPcOrrJS+K6Jd
vJ5cgkOv.AJlxh5cCOd4t+LHbshOA.cg+iWTQf66YEnk9GT+fGzFEn9lH.8i
lTRTnm9wQosRI28ific0Dt2Vkr5gN3yNp1lrpkIU8FYqdezasmDgO6vx4+SW
g6qUtzc4T16SvdlmT+HaRRI8C0OcBDfJYFgZgzXX22aM63mQc8kqezxVcArl
tdj6MA52DneSf9IIPWmB25pyqjJoapT6TmeAEmq9XkGuwORBkqIGecBOOcd1
npSmpegBNqbtw77hnDUeFpaD0c22GDSQBZBPxyF3p7cYi4pbivSB4.SPNbMi
rDxaLq6.5.Kvtn.So2SFIhIH4YiHFpIHQNGgLxmCayf9joSjIHgsAcZzUfny
w0AFwlflWHAmlSaR9M4yR00BZYLNx17MzyDn8uTAUJmz97qIoGj2gylhmOQn
MIfFZkbfljdnZQ3rWeN7bPllT4BdN.FaHvV+xSSRLXCQAFUo1F0vL.msqfo0
txlM6UdVdowJHDaK3K58Dq90g3JTtqeqR2taF+0nJ6U+1GbYYBY7EBM7yyzR
jWP0sEP0m2rj4QkqYBj+wc+uwXWD2
-----------end_max5_patcher-----------

[ramagottfried]

p.s. I've been wondering if maybe some of these gen~ based objects should be turned into C externals @equilet any thoughts on that? that might add some flexibility and possibly some efficiency.. not sure.

[equilet]

I'm happy to leave them as is (as "grey boxes") until we have a specific need.

[ramagottfried]

Yeah I like that idea too,... but for instance there is a limit to the number of indexed xy pairs we can currently use due to the fact that we're using jit.buffer~ to write the points into a buffer, there's a limit to the number of planes .:: although I guess probably some kind of workaround could be found, at some point it's easier to just write an object...

I also wonder about the stability of having loads of gen~ objects... it might be more production level to have it all compiled... not sure. Also i guess if it's open source then it's still greybox ? but yeah, not quite as prototype-able, hmm

Sent via satellite

On Oct 16, 2017, at 21:51, Jeffrey Lubow notifications@github.com wrote:

I'm happy to leave them as is (as "grey boxes") until we have a specific need.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[equilet]

Can we use msp buffers + scripting? polybuffer~? Something similar?

[ramagottfried]

hmm yeah maybe polybuffer~ might work, or we could concatenate the phrases instead of using planes with jit.buffer~ ... that's probably the best route I think, since we can't change actual buffers at sample rate in gen~.

[equilet]

Why is jit.buffer~ preferable to buffer~? Is it more convenient in some way? More feature-rich?