Inlet generating abstraction complications
Greetings patchers and patchettes;
I came up against a problem in a main patch I run as my liveset where all the subpatchers had disgusting amounts of chords everywhere. To solve this problem I made an abstraction.
The abstraction is designed to replace [pa(c)k] by generating inlets based on the number indicated by the argument (using some [thispatcher] stuff) and, instead of outputing the items as a list (which would cause all the items to output every time any of them changed which would cause unwanted triggers through the patch, or, if using [change] not allow me to repeat commands) [prepac] (my abstraction) just prepends each inlets data with an integer and outputs them together through one outlet (which eventually finds its way to a route object for separate and unadultered output.)
My problem is that whenever I open my patch containing the abstractions, although the argument and the inlets remain, the connected patchchords have been disconnected. My suspicion is that the abstraction reloads, (and thus recreates the inlets) fresh every time the main patch is opened.
Is there a way around this? If I can make unique instances of the abstraction and save it’s current state (without, ideally, having a different abstraction saved in my library for every argument I use) that would make matters easier.
Thanks in advance, Cheers.
What you suspect is the case. The only option is to start the abstraction with a maximum amount of inlets and remove the unwanted ones.
hm, did you give a look at [funnel] [spray] [listfunnel] ? i can’t say it for sure, but they might do what you want…
And, your [thispatcher] script, does it contain the correct (connect inlet1 0 object1 0) messages ?
Thanks @JVKR . That’s a great solution. I feel like it might mess with the shape of the abstraction in the patch but it’s the last object in my subpatchers usually, so no matter.
Thanks for your reply, @VICHUG I’ll check these out, I sometimes overlook simple solutions.
Forums > MaxMSP