On Sun, Feb 14, 2016 at 11:27 PM, Jonathan Wilkes <jancs...@yahoo.com> wrote:
> Ivica, > The point is that with control objects one could make an object that > maps "n" abstraction inlets to a single object. That single object can > just prepend incoming messages with an index. Same with dispatching > objects to "n" outlets. > > Doing it that way allows the user to create abstractions with variable > xlets > without relying at all on dynamic patching. Thus the patches end up more > maintainable and easier to reason about. > Perhaps but this is not a case of multiple nlets. Rather it is a way to sidestep multiple nlets limitation that does not map 1:1 to the other solution as it requires prepending (or providing data for all nlets in a form of a list). > > You can't do the same with signal connections. So you'd have to sprout > as many outlets from your object as you have inlets, in which case it's > nearly > the same complexity as dynamic patching with [inlet~]. > True. > > -Jonathan > > > On Sunday, February 14, 2016 7:26 PM, Matt Barber <brbrof...@gmail.com> > wrote: > > > 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" <i...@vt.edu> wrote: > > > On Sun, Feb 14, 2016 at 5:54 PM, Jonathan Wilkes via Pd-list < > pd-list@lists.iem.at> 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 <anto...@metalu.net> > 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 < > pd-list@lists.iem.at>: > > > 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 <brbrof...@gmail.com> > 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 <i...@vt.edu> 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 <i...@vt.edu> 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 > i...@vt.edu > 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" <fjkr...@xs4all.nl> 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 <por...@gmail.com > <mailto:por...@gmail.com>>: > > 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 > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > <http://lists.puredata.info/listinfo/pd-list> > http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > <http://lists.puredata.info/listinfo/pd-list> > http://lists.puredata.info/listinfo/pd-list > > > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
