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.
-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
_______________________________________________
[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
