I've only partially followed all this discussion (not using Max myself), but maybe an object I wrote could help you building such abstractions :
[moonlib/dinlet~] is an [inlet~] with an init float value (constant signal) as an argument. This default value is overloaded when a signal is connected to the inlet, but restored when the signal is disconnected. A float sent to it would overwrite the default constant value. Of course the init default value could be one of the abstraction's arguments ($xxx)... BUT : - there is a very little hack (which could be called a bugfix...) that has to be made to pd source (this change is written in comment in the source file of dinlet~). I should open a ticket for that in the sourceforge repo. The involved bug is mixing the different float values up when [dinlet~] is used together with normal [inlet]s. - I should add a missing feature in dinlet~, which would add an inlet to the [dinlet~] object itself, to allow changing the default value inside of the abstraction. If anyone think this would be helpful, I could do this (open a ticket and update moonlib about this missing inlet). 2016-02-14 20:29 GMT+01:00 Jonathan Wilkes via Pd-list <[email protected] >: > > Why not simply have an inlet that can handle both inside an abstraction > and route signal one way and number the other and then sprinkle that with > dynamic nlet creation and you're done? Then you can simply abstract most > cases. > > I read (and like) your spec on dynamic nlet creation, but I have a problem > with section 2.1 Signals: > > "To handle the dynamic creation of signal inlets and their routing within > the abstraction, the implementation must" > > It looks like the rest of the section is missing. :) > > -Jonathan > > > > > On Sunday, February 14, 2016 1:51 PM, Matt Barber <[email protected]> > wrote: > > > I tried coding that once, but it seemed like it needed some big change in > architecture. Technically it's only the main signal that accepts both > messages and signals in this way, where you would want to route the > message. Floats should almost always be promoted to signals. > > On Sun, Feb 14, 2016 at 1:18 PM, Ivica Ico Bukvic <[email protected]> wrote: > > Why not simply have an inlet that can handle both inside an abstraction > and route signal one way and number the other and then sprinkle that with > dynamic nlet creation and you're done? Then you can simply abstract most > cases. > > > On 2/14/2016 11:36 AM, Matt Barber wrote: > > [gt~] is a great example of something that could work as an abstraction, > except for the pesky right inlet which should take a signal if there's no > creation argument, but float otherwise. > > On Sun, Feb 14, 2016 at 10:50 AM, Ivica Bukvic <[email protected]> wrote: > > What I am also trying to do eventually in pd-l2ork is weed out redundant > objects and only keep the ones that do the said task the best while still > supporting other objects' idiosyncrasies (if any). There is absolutely no > reason to have multiple objects of the same kind. Ultimately, one could > keep all the externals in the same folder and completely do away with all > the declares, imports, and other things that make learning pd unnecessarily > harder. > -- > Ivica Ico Bukvic, D.M.A. > Associate Professor > Computer Music > ICAT Senior Fellow > Director -- DISIS, L2Ork > Virginia Tech > School of Performing Arts – 0141 > Blacksburg, VA 24061 > (540) 231-6139 > [email protected] > www.performingarts.vt.edu > disis.icat.vt.edu > l2ork.icat.vt.edu > ico.bukvic.net > On Feb 14, 2016 8:40 AM, "Fred Jan Kraan" <[email protected]> wrote: > > Hi Alexandre, > > guess some of it is in: > http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html > > > This list is also becoming a list of what has been done. > > > As with _nettles_ > > "try to resurrect as independent object library" > > Anyway, tell me if this gets includes on this file. > > > Yes, the nettles-objects are part of the latest cyclone versions. They are > part of the nettles library, which can be loaded with [declare]. Not all > operating systems like the '<' and '>' in the object names and there is > overlap with other library objects, so only loading them when needed is > cleaner. > > > cheers > > ps. count me in for help with the help files > > > Great! > > Greetings, > > Fred Jan > > > 2016-02-11 22:18 GMT-02:00 Alexandre Torres Porres <[email protected] > <mailto:[email protected]>>: > > Howdy, it's a known fact brazilians will start the year only after > carnival, so here I am. > > I'd like to share my list of things to do with existing Cyclone > Objetcs. Obviously there might be other issues with other objects > that would make them up to date with the current version of Max (Max > 7). Nonetheless, this is what I find relevant, and I've been really > checking it through. > > It's only about 11 objects, some has already been discussed here and > might have been fixed or in the process to be taken care of, forgive > me if so. > > I have it attached and also as a link to a google doc > > > https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing > > Next, I will get together a list of new objects I think should be > included, many of which I've already made as abstractions (kind of > to show how it works like I did with [teeth~], cause I really think > they should all be done as externals). > > Cheers > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > <http://lists.puredata.info/listinfo/pd-list> > http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > <http://lists.puredata.info/listinfo/pd-list> > http://lists.puredata.info/listinfo/pd-list > > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
