CarpentersKeys

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.

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.)

inlet-generating-abstraction-complications

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 ?

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.

Hey @CARPENTERKEYS, was wondering what solution did you use in the end? I had exactly same problem - I used some scripting messages with [thispatcher] so that my first argument defined the number of outlets. However every time it loaded it would disconnect itself. Wonder if you could still do it with javascript?

Hey @IVANKO I took @JVKR 's advice and saved the abstraction with 50 or so inlets and deleted the calculated the difference between that and the argument to delete the unnecessary ones. Works finely.

Inlet generating abstraction complications