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

[Alexandre Torres Porres]

hmmm, much of the discussion here could be maybe at another thread about
creating functionalities (in externals or pd-l2ork) that allow abstractions
to behave more like externals, so I'd suggest changing the topic for that
to go on. btw, I wouldn't see the point of relying on another external from
another library to make cyclone abstractions, and regarding the case of
some simple nettles objects, the main issue is not compiling externals
(because, well, they are already coded, complied and done), but this
discussion of the problems on how to load their object names.

Regarding this matter, it's been noted that "some OS don't like somes
character/names (like >).

Well, I find from the discussion that this is not quite true, cause the
issues for them to not load are for other reasons that seem to be covered
in the way the objects are built in cyclone. I might be missing something,
but that's what I got. And also, I asked this in my first message, but no
one answered or pointed that although these nettles externals load in MAC
OS that they do not load on Windows and Linux - so I'm gonna go with my
hunch that they do load.

Which brings me to inquire why not just have these externals load by
default in the Cyclone library?

If in fact it turns out that some OS can't load their weird symbol names,
there are also the regular name versions of all of them from Max that we
could use (In fact, we could use them as alias too even if there's no
actual issue...)

[greaterthan~] (>~), [greaterthaneq~] (>=~), [lessthan~] (<~),
[lessthaneq~] (<=~), [equals~] (==~), [notequals~] (!=~), [plusequals~]
(+=~), [rminus~] (!-~), [rminus] (!-), [rdiv~] (!/~), [rdiv]
(!/), [modulo~] (%~).


Using declare is not a clean solution, it makes it really harder to
remember how to use declare and the library to load, and then you need to
save the patch and reopen it for it to take effect, that's quite a work,
specially if it doesn't seem necessary at all, when they seem to be loading
just fine.

And even if they don't, that's not a reason to take them out of the
library. For example, in the zexy externals, even when they don't load
unless you use [hexloader], they're still there for you.

And, well, some objects might be on other libraries, but I don't know, I
counted 3 out of 12 that are in zexy (with some issues like having to use
[hexloader]). But this is not by far a reason to hide and/or exclude the
objects from cyclone. Even if the 12 of them were out there in other
libraries, it doesn't make much sense to hide or remove them because it
doesn't mean everyone will have the other libraries alternatives. And some
people like me may hope to depend on the smallest number of libraries as
possible, so getting the full potential of cyclone would be ideal.

If you were thinking about Pd Extended, that could make sense, but that's
dead. Or, in the development of Pd L2ork, that's also reaonsable to remove
redundancies, but this is not where we are at. This is just a library of
externals and there doesn't seem to be any reason for not to load these
objects by default.

Am I making sense?

What would I be missing that's an issue for loading them by default?

Thanks
Alex

2016-02-15 2:27 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list at lists.iem.at>
:

> 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.
>
> 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~].
>
> -Jonathan
>
>
> On Sunday, February 14, 2016 7:26 PM, Matt Barber <brbrofsvl at 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" <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
>
>
>
>
> _______________________________________________
> 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/20160215/962122a7/attachment-0001.html>