I asked for something like Antoine's design back in 2007. I think it's a great idea, because it behaves like a signal inlet in compiled objects. On Feb 14, 2016 6:48 PM, "Ivica Bukvic" <[email protected]> wrote:
> > On Sun, Feb 14, 2016 at 5:54 PM, Jonathan Wilkes via Pd-list < > [email protected]> wrote: > >> Hi Antoine, >> We're talking about two different kinds of "dynamic" nlets. Yours seems >> to >> set a value for the signal based on whether or not there is a connection >> to that >> inlet. What I'm talking about is a future object that would elegantly >> handle >> the creation of a variable number of inlets(~) or outlets(~) inside an >> abstraction. >> >> I'm pressing Ivica specifically on variable signal nlets because there's >> no way >> to flexibly handle them. >> > > Why not? First of all, we need to agree that such an object would be > mostly useful at instantiation time (e.g. a silly example would be an > abstraction that mimics selector~ behavior) and in dynamic patching where > after creation one would need to connect bunch of stuff to this object and > ensure that inside the abstraction additional inlets actually do something. > Second, let's assume the dynamic nlet creation object is the rightmost > object (otherwise user is asking for potential problems if something is > already connected to the second inlet and then suddenly first inlet grows a > couple more inlets before the second one--even this could be potentially > handled, with adequate changes inside the pd core, or in this case pd-l2ork > core). Now, if new nlets are generated, they will not autoconnect to > anything--this is user's responsibility likely through some sort of live or > scripted patching at instantiation time which could be driven from the same > argument. Once that is all taken into an account, the last thing is to > consider: > > suspend dsp > instantiate new object > rebuild dsp graph (as you would with instantiation of any new signal object > resume dsp > redraw object and parent object on its parent canvases > > One lingering concern is that this would effectively make the abstraction > dirty which could be either seen as a good thing or handled as something > that does not trigger the dirty flag. > > Best, > > Ico > > >> >> -Jonathan >> >> >> On Sunday, February 14, 2016 5:34 PM, Antoine Rousseau < >> [email protected]> wrote: >> >> >> 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 >> >> >> >> _______________________________________________ >> [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
