Max: Procesing buffer~ with MSP objects (hacking)

New Ideas
61

I understand, that makes sense. Indeed nothing would actually travel in those cables, so they are useless, you are right. That’s (I guess) why @weefuzzy used the varname to indentify the patcher.

62

Thanks for the mock-ups @danieleghisi. I guess there is some value in making the connections explicit, insofar as it documents the intended behaviour, and allows some flexibility about routing etc. The mc connection is an interesting touch: I haven’t dabbled in the API for this stuff yet, but will see what’s possible.

In your example, we might be able to get away without having to use a special snapshot~ style object by making our own scheduler and attaching that to the patch: this can then be shunted on by a certain amount after each DSP tick (or some number of DSP ticks?) so that objects like this (hopefully) Just Work.

Next steps would seem to be

  • Getting a handle on the connections with patchlineupdate and connectionaccept and working out how to enforce sensible restrictions here
  • Looking at this mc idea and seeing if it can be made to work (which would be sweet)
63

So, looking at @a.harker’s dark arts for managing connections in framelib, I’m not convinced that a connection idiom is going to be much use here

  • One can manage connections from an object quite easily, so it’s simple enough to make it only connect to a subpatcher and only connect to a single thing at once. But you can’t manage incoming connections the same way
  • So the capacity for badness (connections to different objects, or nonsensical objects) seems like it would outweigh potential benefits

Instead, I’ll try for something more poly-like, but that allows subpatchers (as well as loading from disk). For this it probably makes sense to make the input/output proxy-objects needed to inject data into the dsp chain explicit, and use them much like in~ and out~ work in a poly~. That is, you’d make a subpatcher using (say) ears.in~ <channel> and ears.out~ <channel> to specify the disposition of data from and to buffer~s, and then load either from a named subpatch or an abstraction.

64

Just came across the HOA Library again, it seems that their hoa.3d.process (and 2d.process) follow the logic @weefuzzy mentioned embedding a subpatch with hoa.in and hoa.out.