Ah well, just trying with a pointer there instead now. Is is possible that I shouldn’t be assuming that what I get back from newobject_sprintf is the object itself (rather than, say, the box)? Gist updated
Narrator: it was the box
Yes - it is the box, and using jbox_get_object() fixes everything.
I expect this might be helpful
If you’d read it in the past.
I prefer a more impressionistic relationship with text, y’know. And, indeed, jbox_get_object has fixed everything. Thanks for being additional eyes / brain. I shall reinstate setting the processor object in the host box (e.g. [bufproc slide~ 10 10]) and see where that leads.
It’s also in the MaxAPI doc about newobject_sprintf … Anyway
- you’ll need to start thinking about multiple inputs and outputs.
- as you don’t care where the objects are in the patch newobject_fromboxtext might be easier than newobject_sprintf
- as far as I’m aware there’s no way to make an object in a patch (or about any of box attributes) with typed arguments, and reconverting to text is not nice. The wrapper for framelib demos how to grab the text of your object box (which you’d then need to remove the attributes from and the first bit) - that’s probably the nastiest part of this task.
- Also gets more complex if your hosted object takes attributes…
(NB, I just moved this whole discussion to its own thread, as we’d drifted somewhat from the topic of weighted averaging!)
impressionistic…
Yes, next up. My general feeling is that the user will need to be explicit.
I’m literally whole seconds ahead of you
Yes. I haven’t thought very hard about any of that yet. If @danieleghisi is dreaming of something more like the bach ‘lambda’ patches, I may see if I can swerve round all this by trying to copy an extant subpatch that’s connected to our object and run that.
1 Like
What the hell! I lose track of the topic for like two weeks and @weefuzzy & @a.harker are already on track to implement it! You are amazing. Hats off! Can I also steal it for ears once it’s done? 
I’ll add a spoilsport question: how do you think it may be possible to deal with all the MSP object that are parametrized via control messages instead of signals? E.g. How may one build an off-line envelope, say, for [supervp.trans~] whose transposition amount has to be given in control? There’s quite a lot of them, especially 3rd-parties, reminiscent of a signal/control rate distinction. Perhaps a custom snapshot~ object, able to communicate in some particular way?
1 Like
I think @weefuzzy is trying to implement this for ears but I’m not sure.
As far as I can see we are at a point where the interface matters. @weefuzzy so far has been looking at how to host a single object. For the lambda stuff it gets more complicated, because the only way I can think that is viable is to copy the lambda subpatch. This gets complex for what will happen for messages within the subpatch and when. At the moment I can’t see an easy way from the API to create a copy of a patcher, but I assume the patcher is basically a dictionary and if one could access that one could make a copy - maybe a question for the c74 elves.
I’d suggest making some (non-functional) patches demonstrating how you think this should work and then they could be used to discuss the issues that arise. It’s totally possible to have messages from inside/outside communicating with one another, so there are quite a few different possibilities.
If lamda subpatches in which messages (internally) function is the goal then I’d suggest the following:
- figure out how to copy the subpatch
- explore having a local scheduler (as in poly~) that can be updated in between audio blocks.
A dictionary is my hope too, as the alternative would seem to be traverseing a whole patch box by box and then <something>. There’s a promising looking message called appendtodictionary that both jpatcher and jbox seem to expose (I’m just dumping the class c_messlist to try and get a handle on what might be possible).
Agree some mock ups would be useful to get a feeling for more ambitious uses. Objects whose state is set by messages are especially troublesome, but I’m sure we’ll think of something (and I can see you already have…)
Seems to work
t_dictionary* d = dictionary_new();
object_method(patch,gensym("appendtodictionary"), d);
void* p2 = jpatcher_load_fromdictionary("buggerlugs", 0, (t_object*)d, 0, NULL);
I can sucessfully copy the patcher I’ve made on the fly, locate the in/out proxy objects, compile the dsp and do the buffer processing against the copy.
Damn… Must code/type faster
t_dictionary*dict = dictionary_new();
t_atom a;
object_method(patch, gensym("appendtodictionary"), dict);
atom_setobj(&a, dict);
t_object *patch2 = (t_object *)object_new_typed(CLASS_NOBOX, gensym("jpatcher"),1, &a);
object_method(patch, gensym("front"));
object_method(patch2, gensym("front"));
1 Like
I’d suggest that the best time to identify the lambda is on connection, at which point you can also then refuse multiple connections. You might also decide only to accept sub patchers/abstractions, which if I remember correctly will actually look like jpatchers in a box - I’d have to check that.
That might be connectionaccept or patchlineupdate (both covered in the framelib max object stuff)
I was wondering about that, specifically about whether a connection-based idiom had anything to reccomend it over using a scripting name and object_obex_lookup or something, viz
[bufproc]X[p lambda]
vs
[p lambda] //@varname foo
[bufproc foo]
Over to @danieleghisi here - personally I’d load a patch from disk (poly~ style) because there are definitely going to be some weirdnesses that result from copying the patch for some cases), so for me this is all about interface preference.
Hi @a.harker, I understand.
Honestly, whatever may work would be amazing. From an interface point of view, I hate poly~s. For one thing, not being able to embed the poly patcher in the main patcher is a drag whenever you need to share or embed your work in a coherent way. It makes no sense that I need to share 2 or more patches just because I want to play some notes in polyphony, at least give me the option to embed the subpatcher, as in [bpatcher], say.
In this sense, I’m more confortable with bach-style lambdas, but again that’s a personal preference and if there were anything like [bufproc my_patch_like_poly] that would be just as amazing, honestly.
Top notch case would be if it could do both
Depending on whether it has a patch as argument or not. But I’m very much unaware of the intricacies of the issue (just skimming the surface by “kinda following” your lines of thoughts in here ) so I have no idea what would be actually usable in practice.
Here are a couple of mock up things done in 5 minutes, hope they make some sense.
Again, they are lambda-style but a poly-like thing would be still awesome.
Is this something along what you were thinking?
----------begin_max5_patcher----------
1758.3oc6Zs0bahCE9YmeELL6iY8fD2r2m596nSGOxfrsZwRLHQZR6z7ae0E
.CNBLNFRa2lNYL0mCR57czQmaxe+tEtaYOh4tN+iyGcVr362sXgljhvhpuuv
8H5wjLDW+ZtT7WYa+r68FVB7iBMYLpfur.u+4ZNjTMc4692vnZhzxiDZFVnm
J3IhrRQMUPE0bjH4.gteSANQXDPfevRu6c7WEodD4o9DBW547opwXlFwS4Xy
.bcc9jhyOt6N0G2ORHlvNdDSEuDiY3GPBBiZCigVwHvJF85Gi9QFL5EpdDFq
wnmBiSHPPeibrTbvFLBlFX.WsdY3IX.lEXrsb2NbgMT3OQn.D1BE9qmETfQI
GbLPwIufkf4bbpCihc19j5Q8.xHTbBqjpGkuEPClHPGDo.cnu5yXMlChmkcN
GVQMvyHbgsMRuoAS.OsKCescHvrc9p2HG1C3C17.BhtBbLfGPe+V.Hb8b4.b
XDhRsBwqwAH7RPDpc7EEMBDd+DixbGQAhxyYbrMX5OM6jfX+SHLFbYbxI6on
L2lWPOmRueF7UAvEt6HxfT3BtJJ0IIXgKJOuE4EsFhRq7YldhVceCIB0PBzP
RZZSpGeXCUTgDYBIrJKzRp6iQ0gPTSCKEWPKI5YxPTt+TIR5cBJ5HlmiRLCV
sgUy9jtJFns2AlPiQA5.+Aq7Notja06yXIeAm1xQfTIlioDZdAlKcBYhb2lc
JdGpLSrYGiJ3juoEAfbSvF+cUhnUlJPnk++sfH2ipek8EjTFUIDc1JTjqWNo
gfAagsAi9MnnbKCVZCJ0K8vjKAYIeKpPsSsMC25nlz.mwx5xpYbY3chJ14DJ
8Lsnfk2OyBx9CCL1sLIyiCM2ZN7MkTC2MRiBwFN5gtZaAJKq57Z2o+QDkbDI
vBhYK.50vDSQRfdfmTvxx5fWCmGrvIUZjmf+JIUlcjZgZaLHecRdsQjaytbJ
YOlK5RSf1y6RgKdxnzaQpba0g3MB7w7LIJ59BxiGxvh7CruxqdwZCs1JfSou
29PcamecnOjSvtNB4k43hGxWpcG9ryGZbKpTxsGQK2i9soayCY+AC5ySYnmI
lm4wpWj0+ftKOEbXQc.hJmPuR8kFP8.9fdAuWufGLFva734274vP2sC65TvZ
aYokaZJ9wV9kmDsiQV5Q8D9JrM7FksgISndzOuJEvIewpzt64DlVfT7sqY3r
xhj5MkJ6CmtxlzohfPahL8wlCQNdizp8ZkA+QJCg8JCUDqii6p7UmtwDWZCR
HJHaKEFUV6DStJ+mxf4aQYm4zyl606NIbSS1eZmdKSjgkVVULFyVElffqnkF
WLaWSVf.v54Lc2WSWM.fIsc.PXzDzUiWU0Ivoo5D3JnQ1gye8IWe2a.dSZeO
p2tlmt2npTwBFVOQU7a5hQEDfAu4VbwSjAm2p2LCtdKHFSSjExYAj1aqg+0V
LbEH8MU8ChhuLJOJq8hjb.IqYH6O3Ri8WaJeL.9dowuWZ76kFOkkF2MvUWeh
Tlz6C1Qbfvcj+gbZ6Oxw3P5dmcrhyYIcjkWJb5b0E81iwIrRoHSXDeSevifc
iGNQk+MPyDNlrT5J6KO6DzGnA8B5faq54pnKqjowz9evUioOBViy71nxZUJh
xolzXWnZChyGLZFGXOZxU8pHguVEI.pqSYs1rAXdbYc2zpojAC4n8XqpJDN0
A37Wx+fNfk8nWhmM8R0iUg+LzKC0QJ3z2QJ350ydKo7eiTOfoW8TYJLqpG3a
i+GzwsDSl+OOgc6MXTczK1q1k800r2A9eclhKzzptZLY5FIBxC0Yk1dhVnb8
rgmfpRa7TVQlsR49nLGF4BrIcq5EhrxOornJotkPKraR.+rAyXEoaPz8Y3ys
YqYxehKye5ELS2JSpjHLyYXGNxrpThqkkSwBQSvaTUtb1drLubDgZYPDE.xY
YMUXzYPRQDW7Bp0arcH93SeqqZtgWygf2au++OauOLx+2h16qZst+HZstJSW
0KNa82GNVg.NiBAXrBA3m7McnEh455V9U3Jeh+EPFpUx2v8Nc6BwpQJCwyoh
XjxvpYTFfWgL.9C7N.Gru9SzEIU8aY9mYe8scUmOq5t.WFc5Cx0W01CdSCar
U3j09zXOg+gTBwlFJD.FoV3daZC8X5FO2nbN+3QkJZ3il8bjP8SY2ouKQZrK
TzHVHP6jIbORRyYxbo402OWr92kr4GDW.zb6Ic9Fr52DQj4l7Te6FkZ.bjhM
7FWn3QtNfaEPcTw1WmnI.Of1ojMv5LE3ALh04VMDFqcvMavELlEZJPDHbLqT
vTrR9ick.Sg16RlC.+WfIiazytST0hb1cgd18f9x6.s+6+7769TmFQe244c+
3t+SQQKnh
-----------end_max5_patcher-----------
(One may need to make the number of channels explicit, I guess, by using some @inchans N and @outchans N.)
Looks plausible, although I’ve not looked at ears, so I don’t full understand the syntax, and certainly not under the hood. The only thing I’d say about this style is that the loopback into the object seems (from a technical point of view) like it might be superfluous. I get why it would be needed for message stuff, but essentially once the patch is identified the connections have served their purpose, and you only need one connection for that. However, this might be useful for identifying the number of the inlets/outlets, which would make the thing more flexible (or that you could ignore some ins/outs)