[PD] Nettles. Was: Cyclone: List of Issues with existing objects by Alexandre Porres

Matt Barber brbrofsvl at gmail.com
Mon Feb 15 01:26:32 CET 2016 

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" <ico at vt.edu> wrote:

>
> On Sun, Feb 14, 2016 at 5:54 PM, Jonathan Wilkes via Pd-list <
> pd-list at 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 <
>> antoine at 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 at 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 <brbrofsvl at 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 <ico at 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 <ico at 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
>> ico at 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" <fjkraan at 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 <porres at gmail.com
>> <mailto:porres at 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 at 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 at 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160214/08a10981/attachment-0001.html>

More information about the Pd-list mailing list