Not all operating systems like the '<' and '>' in the object names

I'm aware there's some issue of OS not liking such object names, but I don't get it.

For example, [<] and [>] are vanilla objects, don't they load in every OS?

And what does it mean? Do these objects not load on every system even when declared?

I know it loads on MAC OS, what I use, when declared anyway

But I also know that if you try and load [<~] and [>~] from zexy you need a [hexloader] object. Don't know why it doesn't load without it.

cheers

It's only when the name is used as part pf a path (like C:/pd/extra/<~.dll) that the problem shows up.

Ok, but I still don't get how this problem manifests itself.

Don't the externals load in every OS? Particularly, don't the cyclone objects load on every system even when declared? Because they do on MAC OS when declared.

And why do I need to use the [hexloader] object to load [<~] and [>~] from zexy?

I would suggest using [lt] and [gt] for 'less than' and 'greater than' as is done in many assembly languages.

In fact, in Max, you can load [>~] as [greaterthan~], all the nettles objects have actually other such names

[greaterthaneq~] for [>=~], [lessthan~] and [lessthaneq~] for [<~] and [<=~]

[equals~] for [==~]

[notequals~] for [!=~]

[plusequals~] for [+=~]

[rminus~] for [!-~] ([rminus] for [!-])

[rdiv~] for [!/~] ([rdiv] for [!/])

[modulo~] for [%~]

perhaps we could use this

cheers

2016-02-14 13:43 GMT-02:00 Martin Peach chakekatzil@gmail.com:

On Sun, Feb 14, 2016 at 10:00 AM, Alexandre Torres Porres < porres@gmail.com> wrote:

...

Not all operating systems like the '<' and '>' in the object names

I'm aware there's some issue of OS not liking such object names, but I don't get it.

For example, [<] and [>] are vanilla objects, don't they load in every OS?

They load because they are built-in so Pd doesn't need to go to the OS filesystem to find them. It's only when the name is used as part pf a path (like C:/pd/extra/<~.dll) that the problem shows up. I would suggest using [lt] and [gt] for 'less than' and 'greater than' as is done in many assembly languages.

Martin

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

2016-02-14 16:42 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:

you are using distribution of zexy that has deliberately broken zexy

into pieces. when zexy is built correctly (as a single multi-object-file

library) there is absolutely no problem.

Well, it seemed I could have another version of zexy, so I tried downloading new ones from deken with the latest vanilla.

zexy-v2.2.6svn-(Darwin-i386-32)(Darwin-x86_64-32)-externals.zip didn't seem to work, I had to use [hexloader] apparently, but I didn't have it. Yeah, I thought [hexloader] was part of zexy, but it ain't...

Now, zexy-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar *works!* I can load them without [hexloader]. So that's when zexy is built correctly (as a single multi-object-file library), right?

2016-02-14 14:31 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at

:

For example: the one-clas-per-file-libdir is the reason you can't easily have externals with names like "<~" and ">~".

Maybe this is saying the same thing? Depending on how you build it then it doesn't work? Seems so to me...

Not sure if I'm missing something, but basically it seems you can avoid the issues of not being able to load externals named [>~] or whatever...

More important to this discussion is, *the way cyclone is built has no such problems*, as I can load all the object names *without* [hexloader].

Now, is it just me on my Mac Os, or there might still be issues with other Operational Systems? I asked this on my first message, cause that's what Fred Jan seemed to imply to me. Anyway, I'm not sure, I actually think now they'll load just anywhere.

Who can help me?

Thanks

Pd namespaces and the Pd loading mechanism are too complex to change without a spec for both the current and proposed system. Problems of not thinking ahead: unnecessary code duplication like flatspace, replacing one problem with another like one-class-per-file libdir, the whole svn personal-cloud-workspace-as-a-library deal in the first place, and so on...

For example: the one-clas-per-file-libdir is the reason you can't easily have externals with names like "<~" and ">~".  Internal classes are loaded by default from files that have alphanumeric names, so there it isn't a problem.  That's why you need to introduce another external "hexloader", and make sure it always loads first.  (Plus the new bother of mapping hex values to ASCII characters in file names, and remembering how to read those names.) -Jonathan

On Sunday, February 14, 2016 10:52 AM, Ivica Bukvic <ico@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@vt.edu www.performingarts.vt.edu disis.icat.vt.edu l2ork.icat.vt.edu ico.bukvic.netOn Feb 14, 2016 8:40 AM, "Fred Jan Kraan" fjkraan@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@gmail.com mailto:porres@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-3nXy2Q...

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

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 14/02/16 16:37, Alexandre Torres Porres wrote:

...

hat's why you need to introduce another external

...

"hexloader", and make sure it always loads first.

but why don't I need this when I load the cyclone externals?

hexloader is only need for 2 cases afaict:

1. if you want an abstractions with '/' in the object name (not allowed by filesystems)

2. single-object externals with non-alphanumeric characters (not allowed in C identifiers)

multi-object libraries avoid (2) by exposing a C function libraryname_setup() in libraryname.pd_whatever instead of objectname_setup() in objectname.pd_whatever, and libraryname_setup() can register all the objects in the library at once (not just [libraryname]).

I'm guessing cyclone is a multi-object library that you load with -lib cyclone (or declare), so there is no need for hexloader.

Claude

http://mathr.co.uk

[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@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@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@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@gmail.com mailto:porres@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-3nXy2Q...

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

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

but why don't I need this when I load the cyclone externals?

If every cyclone external has already been loaded before your patch loads, then there's no problem. The problem comes when Pd tries to search for a binary to load-- for example, when you type a name into an object box that Pd doesn't know.  If that name has characters that can't appear in a filename (like "<") then you need to have hexloader loaded already.

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@vt.edu mailto:ico@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 <tel:%28540%29%20231-6139>
ico@vt.edu <mailto:ico@vt.edu>
www.performingarts.vt.edu <http://www.performingarts.vt.edu>
disis.icat.vt.edu <http://disis.icat.vt.edu>
l2ork.icat.vt.edu <http://l2ork.icat.vt.edu>
ico.bukvic.net <http://ico.bukvic.net>

On Feb 14, 2016 8:40 AM, "Fred Jan Kraan" <fjkraan@xs4all.nl
<mailto:fjkraan@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@gmail.com <mailto:porres@gmail.com>
        <mailto:porres@gmail.com <mailto:porres@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 <mailto:Pd-list@lists.iem.at> mailing list
    UNSUBSCRIBE and account-management ->
    http://lists.puredata.info/listinfo/pd-list


_______________________________________________
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

Well, if it does not break backwards compatibility of nlets, I am all for including it in pd-l2ork...

On Sun, Feb 14, 2016 at 1:38 PM, Matt Barber brbrofsvl@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@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@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@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@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@gmail.com mailto:porres@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-3nXy2Q...

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

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 brbrofsvl@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@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@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@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@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@gmail.com mailto:porres@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-3nXy2Q...

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

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 antoine@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 brbrofsvl@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@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@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@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@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@gmail.com mailto:porres@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-3nXy2Q...

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

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@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@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 dspinstantiate new objectrebuild dsp graph (as you would with instantiation of any new signal objectresume dspredraw 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@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 brbrofsvl@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@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@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@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@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@gmail.com mailto:porres@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-3nXy2Q...

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

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

On Mon, Feb 15, 2016 at 10:36 AM, Alexandre Torres Porres porres@gmail.com wrote:

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.

If you look in Pd source file x_arithmetic.c you will find this line: binop2_gt_class = class_new(gensym(">"), (t_newmethod)binop2_gt_new, 0, What it does is register the symbol ">" and associate it with the function binop2_gt_new, which will create the "greater than" object. If the symbol had not been set up when Pd started (when x_arithmetic_setup() is called at startup), then Pd would start looking through its list of directories to search for a file named >.pd_linux, or >.darwin, or >.dll, or other suffixes, depending on the OS. None of those names are legal file names on those systems, so an error would occur and the object would not create. Cyclone, when it's properly set up, will also register a bunch of symbols when it starts, thereby avoiding file searches for illegal filenames. If only part of cyclone is loaded, it may not have registered the weird symbols, so they won't load.

Martin

On 2016-02-15 07:38 PM, Martin Peach wrote:

If you look in Pd source file x_arithmetic.c you will find this line: binop2_gt_class = class_new(gensym(">"), (t_newmethod)binop2_gt_new, 0,

Well, by looking at the nettles.c code, we find the exact same structure

sigeq_class = class_new(gensym("==~"),(t_newmethod)sigeq_new, 0,

So cyclone is taking care of this problem in the same way!

None of those names are legal file names on those systems.

Cool, so it's not a matter of one particular OS having an issue an not another, it's a general issue to all of them that have the workaround which is already done.

Cyclone, when it's properly set up, will also register a bunch of symbols

when it starts, thereby avoiding file searches for illegal filenames.

Yep, this is what I'm assuming, that you can make it work if you do the right thing. For example, I mentioned I downloaded a version of the zexy library that loads [>~] without the need of a [hexloader] object. I just put "zexy" in the search patch and [>~] loads quite easily.

If only part of cyclone is loaded, it may not have registered the weird symbols, so they won't load

These objects are not loaded, so only a part of cyclone is in fact loaded, I'm not sure why yet, it's kinda over my head. I'm having a hard time trying to figure it out the issues of needing to use [declare] and not loading this files beforehand.

But I just believe you can have them load with no problem in any OS now, right?

cheers

2016-02-15 20:33 GMT-02:00 Martin Peach chakekatzil@gmail.com:

On Mon, Feb 15, 2016 at 5:21 PM, Alexandre Torres Porres Looks like it. You just need to make sure that code is called somehow, e.g. by declaring its library.

But it's not like using [declare] is the only way to do this, right?

They should load on any OS, as long as the library setup has been done so Pd knows about them.

meaning it could be done in a way that doesn't need [declare], right?

cheers

Hi Alexandre,

please let me know of any issues I'm still not getting

PureData goes to great length to find and load the objects you want, and I understand only a part of it. Several objects and loaders are added to improve the behaviour, but at the cost of more complexity. You could restart pd, set logging to "4: all" and try to load an object to see what is done. You could even make an abstraction with special characters in the name to see what happens. The loading is pretty much the same. There should be several discussions about load behaviour in the archive.

Personally, I prefer to fix bugs in cyclone ;-).

cheers

Greetings,

Fred Jan

Hi Alexandre,

Howdy, if you understand only a part of it, I know that I know about nothing.

But hey, as I understand it, there's quite some work to make it (loading the weird name objects without [declare]) happen and you'd rather focus on other fixes, cool.

Well, I'm just starting using github https://github.com/porres/pd-cyclone https://l.facebook.com/l.php?u=https%3A%2F%2Fgithub.com%2Fporres%2Fpd-cyclone&h=FAQF6upTy and have mobilized others to collaborate with new objects for cyclone, according to that list I shared these days.

You may have noticed a pull request already for [pong]. I'm working with someone else and we should be having scale / scale~ / atodb / dbtoa / atodb~ / dbtoa~ / trunc~ ready quite soon!

Yes, I noticed. I appreciate all you do for pd and cyclone in particular, but I cannot accept the request. Cyclone is one of the few libraries with a closed set of objects; only those part of Max/MSP, arbitrary set around version 4.6 or 5.

Cyclone is already quite big, with 150+ objects. This seems a good reason to be selective in which objects should be added. Just because objects are or should be in Max/MSP is not reason enough. If it exists in another library, it is unneeded IMHO.

I can bother myself to try and deal with the issues regarding these objects, but I think a start could be to create new objects with the unweird names, this is not in conflict with Max compatibility, as it also loads these objects via the same way (again, they'd be: /greaterthan~ / greaterthaneq~ / lessthan~ / lessthaneq~ / equals~ / notequals~ / plusequals~ / rminus~ / rminus / rdiv~ / rdiv / modulo~/). It wouldn't get in conflict with current state of cyclone either and the help files of these objects could refer to nettles and all. Cool? Later on in the game I can try and figure out how to load them without declare.

Personally I have no issue with [declare] as it is vanilla. Or with the weird names; if you want un-weird names, abstractions (containing [declare] should work too?

cheers

cheers

Greetings,

Fred Jan

Hello,

First, thanks a lot all of you which are working in this project! I'm learning a lot and I have much more to learn because of your work. It is very important to me and for those who are coming. Thanks!

Second, I'm pd and Max 7 user, and would like to say which in my point of view cyclone is very useful to anyone like me which use pd and max... Max 7 are very used for Ableton Live users because Max for Live and a library (cyclone) bridging cycling74 platform with pd are a useful tool to learn patchs and coffee them with different features offered by each of them. And for me is something sad to know that bridge is large outdated, and the worse, we have people interested in make the updates to allow patches workables in pd (cyclone) and Max and exist the possibility of stay with an outdated compatibility. Only to reforce, several people I know are working and learning max4live, that is Max 7, what seems relevant this update.

This is only my point of view. A user, and I wish contributor too in the future.

Cheers

Esteban Viveros

Em qua, 17 de fev de 2016 17:46, Marco Matteo Markidis < mm.markidis@gmail.com> escreveu:

Dear Fred,

some of the objects proposed by Porres could be added in cyclone? If yes, we can work on them; otherwise I see your todo list1. If you confirm this list probably it's better to work to fix bugs.

Cheers,

Marco Matteo Markidis

2016-02-17 19:33 GMT+01:00 Fred Jan Kraan fjkraan@xs4all.nl:

...

Hi Alexandre,

Howdy, if you understand only a part of it, I know that I know about

...

nothing.

But hey, as I understand it, there's quite some work to make it (loading the weird name objects without [declare]) happen and you'd rather focus on other fixes, cool.

Well, I'm just starting using github https://github.com/porres/pd-cyclone < https://l.facebook.com/l.php?u=https%3A%2F%2Fgithub.com%2Fporres%2Fpd-cyclon... and have mobilized others to collaborate with new objects for cyclone, according to that list I shared these days.

You may have noticed a pull request already for [pong]. I'm working with someone else and we should be having scale / scale~ / atodb / dbtoa / atodb~ / dbtoa~ / trunc~ ready quite soon!

Yes, I noticed. I appreciate all you do for pd and cyclone in particular, but I cannot accept the request. Cyclone is one of the few libraries with a closed set of objects; only those part of Max/MSP, arbitrary set around version 4.6 or 5.

Cyclone is already quite big, with 150+ objects. This seems a good reason to be selective in which objects should be added. Just because objects are or should be in Max/MSP is not reason enough. If it exists in another library, it is unneeded IMHO.

...

I can bother myself to try and deal with the issues regarding these objects, but I think a start could be to create new objects with the unweird names, this is not in conflict with Max compatibility, as it also loads these objects via the same way (again, they'd be: /greaterthan~ / greaterthaneq~ / lessthan~ / lessthaneq~ / equals~ / notequals~ / plusequals~ / rminus~ / rminus / rdiv~ / rdiv / modulo~/). It wouldn't get in conflict with current state of cyclone either and the help files of these objects could refer to nettles and all. Cool? Later on in the game I can try and figure out how to load them without declare.

Personally I have no issue with [declare] as it is vanilla. Or with the weird names; if you want un-weird names, abstractions (containing [declare] should work too?

...

cheers

cheers

Greetings,

Fred Jan

---

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

Thanks Porres! I'm waiting good news.... Perhaps a cyclone fork, maybe UpCyclone :P

And again.. Thanks every pd/library maintainer for your time of life!

Em sáb, 20 de fev de 2016 às 01:51, Alexandre Torres Porres < porres@gmail.com> escreveu:

Thanks for your thoughts and message here, Esteban, but I started a fork of this thread focusing on updating and including more objects to cyclone : *[Not accepting new objects in Cyclone, why not? (was Re: [PD] Nettles)]*

I plan to respond to you on that thread.

cheers

2016-02-19 23:31 GMT-02:00 Esteban Viveros emviveros@gmail.com:

...

Hello,

First, thanks a lot all of you which are working in this project! I'm learning a lot and I have much more to learn because of your work. It is very important to me and for those who are coming. Thanks!

Second, I'm pd and Max 7 user, and would like to say which in my point of view cyclone is very useful to anyone like me which use pd and max... Max 7 are very used for Ableton Live users because Max for Live and a library (cyclone) bridging cycling74 platform with pd are a useful tool to learn patchs and coffee them with different features offered by each of them. And for me is something sad to know that bridge is large outdated, and the worse, we have people interested in make the updates to allow patches workables in pd (cyclone) and Max and exist the possibility of stay with an outdated compatibility. Only to reforce, several people I know are working and learning max4live, that is Max 7, what seems relevant this update.

This is only my point of view. A user, and I wish contributor too in the future.

Cheers

Esteban Viveros

Em qua, 17 de fev de 2016 17:46, Marco Matteo Markidis < mm.markidis@gmail.com> escreveu:

...

Dear Fred,

some of the objects proposed by Porres could be added in cyclone? If yes, we can work on them; otherwise I see your todo list1. If you confirm this list probably it's better to work to fix bugs.

Cheers,

Marco Matteo Markidis

2016-02-17 19:33 GMT+01:00 Fred Jan Kraan fjkraan@xs4all.nl:

...

Hi Alexandre,

Howdy, if you understand only a part of it, I know that I know about

...

nothing.

But hey, as I understand it, there's quite some work to make it (loading the weird name objects without [declare]) happen and you'd rather focus on other fixes, cool.

Well, I'm just starting using github https://github.com/porres/pd-cyclone < https://l.facebook.com/l.php?u=https%3A%2F%2Fgithub.com%2Fporres%2Fpd-cyclon... and have mobilized others to collaborate with new objects for cyclone, according to that list I shared these days.

You may have noticed a pull request already for [pong]. I'm working with someone else and we should be having scale / scale~ / atodb / dbtoa / atodb~ / dbtoa~ / trunc~ ready quite soon!

Yes, I noticed. I appreciate all you do for pd and cyclone in particular, but I cannot accept the request. Cyclone is one of the few libraries with a closed set of objects; only those part of Max/MSP, arbitrary set around version 4.6 or 5.

Cyclone is already quite big, with 150+ objects. This seems a good reason to be selective in which objects should be added. Just because objects are or should be in Max/MSP is not reason enough. If it exists in another library, it is unneeded IMHO.

...

I can bother myself to try and deal with the issues regarding these objects, but I think a start could be to create new objects with the unweird names, this is not in conflict with Max compatibility, as it also loads these objects via the same way (again, they'd be: /greaterthan~ / greaterthaneq~ / lessthan~ / lessthaneq~ / equals~ / notequals~ / plusequals~ / rminus~ / rminus / rdiv~ / rdiv / modulo~/). It wouldn't get in conflict with current state of cyclone either and the help files of these objects could refer to nettles and all. Cool? Later on in the game I can try and figure out how to load them without declare.

Personally I have no issue with [declare] as it is vanilla. Or with the weird names; if you want un-weird names, abstractions (containing [declare] should work too?

...

cheers

cheers

Greetings,

Fred Jan

---

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

+1 To Ivica's proposal and rationale. There are plenty of people willing to help with development and maintenance. If a Max 4.6 compatibility library is really necessary, perhaps that could be the fork with the new name.

On Sat, Feb 20, 2016 at 11:04 AM, Ivica Ico Bukvic ico@vt.edu wrote:

FWIW, Fred, if there is a way to convince you to allow for adding new objects, I would certainly like to second that. In the eyes of new pd users who are familiar with Max, Cyclone is not only a Max 4.6 compatibility library, it is first and foremost Max compatibility library and that would suggest newer objects should be in there. I imagine the only reason they simply weren't already added is likely due to lack of a developer and maintainer. The last thing pd community needs is yet another library that may end-up without a maintainer. The confusion one will have to deal with by creating cyclone/prepend vs. <some-other-lib>/pong is pointless at best. If maintaining library overhead is a concern, please note we've already done a fair amount of creating updated help files for the entire cyclone library in pd-l2ork, as well as fixing and upgrading a number of objects, all of which I've gladly shared with you and continue to contribute as much as you allow and my time permits. But please, let's not start yet another library. If anything, we should look into consolidating. Pd-L2Ork has already started doing this. e.g. one of the examples brought up regarding Eric Lyon's potpourri and cyclone's cartopol~ and poltocar~, in pd-l2ork, potpourri objects are not being built because they are not necessary. All this with the goal of eventually doing away with subfolders/declares/imports and other middleware and simply having all the best externals in one folder and getting rid of the rest (or perhaps adding them in the unsupported/legacy subfolder). In such an ecosystem PD META will take care of the attribution and bug reporting and we'll be all better for it, particularly in terms of encouraging new users to join the pd community.

On 2/17/2016 1:33 PM, Fred Jan Kraan wrote:

...

Hi Alexandre,

Howdy, if you understand only a part of it, I know that I know about

...

nothing.

But hey, as I understand it, there's quite some work to make it (loading the weird name objects without [declare]) happen and you'd rather focus on other fixes, cool.

Well, I'm just starting using github https://github.com/porres/pd-cyclone < https://l.facebook.com/l.php?u=https%3A%2F%2Fgithub.com%2Fporres%2Fpd-cyclon... and have mobilized others to collaborate with new objects for cyclone, according to that list I shared these days.

You may have noticed a pull request already for [pong]. I'm working with someone else and we should be having scale / scale~ / atodb / dbtoa / atodb~ / dbtoa~ / trunc~ ready quite soon!

Yes, I noticed. I appreciate all you do for pd and cyclone in particular, but I cannot accept the request. Cyclone is one of the few libraries with a closed set of objects; only those part of Max/MSP, arbitrary set around version 4.6 or 5.

Cyclone is already quite big, with 150+ objects. This seems a good reason to be selective in which objects should be added. Just because objects are or should be in Max/MSP is not reason enough. If it exists in another library, it is unneeded IMHO.

...

I can bother myself to try and deal with the issues regarding these objects, but I think a start could be to create new objects with the unweird names, this is not in conflict with Max compatibility, as it also loads these objects via the same way (again, they'd be: /greaterthan~ / greaterthaneq~ / lessthan~ / lessthaneq~ / equals~ / notequals~ / plusequals~ / rminus~ / rminus / rdiv~ / rdiv / modulo~/). It wouldn't get in conflict with current state of cyclone either and the help files of these objects could refer to nettles and all. Cool? Later on in the game I can try and figure out how to load them without declare.

Personally I have no issue with [declare] as it is vanilla. Or with the weird names; if you want un-weird names, abstractions (containing [declare] should work too?

...

cheers

cheers

Greetings,

Fred Jan

---

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

2016-02-20 17:11 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at

:

Is there actual Pd code for Max 6+ classes somewhere behind this 40+ message thread?

The thread was first about compiling the nettles and also did comport parallel discussions about how to implement abstractions that behaved like externals. The discussion about including new objects started very late on this thread and I opened another one to discuss it, but it didn't catch on. I'm giving it up and joining back here.

The last discussion started by Fred saying he couldn't accept my pull request of a new [pong] object, which is not available in Max 5, so it's a Max6+ feature. In his response, Fred mentioned a couple of things, one of which being: "*Cyclone is one of the few libraries with a closed set of objects; only those part of Max/MSP, arbitrary set around version 4.6 or 5.*"

• maybe the problem with Fred not accepting pong is because of that, I can

only infere.

Another thing he mentioned is that objects with the same functionality from other libraries should not be implemented in cyclone. I don't think that way and Ivica +1 do not either. One way or another, I don't know of any objects that have the same functionalities as pong (wrapper and folder), so being Max 6+ meets one of Fred's restriction.

But then, I don't really know where this fact that cyclone "is" like that (*one of few libraries with closed set of objects*) came about, as it's not something that was ever discussed on the list or ever shared with the community. Never was something dictated or imposed by the original author or described in the project. It seems more like an opinion of what Fred thinks cyclone should be.

Apparently, it is not a consensus in the community. I was able to mobilize a few people to help and code new objects, all in favour of adding Max6+ features. Marco, who joined this thread to discuss this 3 days ago, was helping me coding 6 new objects alone, and is now on hold waiting for this discussion to progress.

Jonathan, this addresses your inquire and much more, I'm digressing, and will now respond to other messages on this thread, take care.

2016-02-19 23:31 GMT-02:00 Esteban Viveros emviveros@gmail.com:

cyclone is very useful to anyone like me which use pd and max (...) bridging cycling74 platform with pd are a useful tool to learn patches and copy them

From its early time, cyclone aimed to a compatibility to Max/MSP and, at

the time, was obviously centered around the current and most to date version (4.6). Citing the original project description, it was "*mainly for people using both Max and Pd, and thus wanting to develop cross-platform patches*". So yeah Esteban, cyclone is originally for people/users like you!

for me is something sad to know that bridge is large outdated, and the

worse, we have people interested in make the updates to allow patches workables in pd (cyclone) and Max and exist the possibility of stay with an outdated compatibility.

I understand your concern to all of a sudden, when we have a mobilization to work on cyclone, that there's a hold back to that. Cyclone was made available still "at an early stage" (as described in the original project description). This means it wasn't able to meer its full potential of cloning every object, although a huge amount of great work had been done. These days, even some of the great work that had been done is now partially outdated indeed. That the work we should do investing in maintaining cyclone should consciously keep it outdated on purpose doesn't seem right to me.

This is only my point of view. A user, and I wish contributor too in the future.

Being a user (with the exact profile the library was created for) does not

invalidate your opinion, on the contrary. I guess I feel users are somewhat intimidated to join discussions around here, or even participate on the list, so you popping up is a great contribution, we need your voice. And I don't believe any user with your profile will like the idea that the cloned library for Pd doesn't care about newer versions of Max. That might be a hell of a turn off...

On the other hand, such an idea could come only from not an user, or from someone who's not even considering or thinking about users, it's more of a maintenance's point of view concern, the issue being that there'd be more work involved in it than a will to commit to such amount of task.

Which is cool, no one is getting paid for this. The weird thing is that such personal and individual idea should prevail in a project where other people are willing to contribute and push it forward. It's not a matter of asking someone to work on stuff they don't wanna, the work is already being done for other who are excited to do it...

2016-02-20 15:57 GMT-02:00 Matt Barber brbrofsvl@gmail.com:

+1 To Ivica's proposal and rationale. There are plenty of people willing to help with development and maintenance. If a Max 4.6 compatibility library is really necessary, perhaps that could be the fork with the new name.

I'm actually confused, as I see Fred is putting out a revision of Cyclone with a different project description and all. I wanted to discuss this in yet another thread I opened, but here we go, hehe...

Anyway, I hope there's no need to any "fork" and that we could all work together on the best interest of the community. Maintaining a fork that's arbitrarily compatible to an old version and then having another one that's not incompatible to the "legacy" cyclone, but only has a little more objects and functionalities is insane (it's not like there's a crazy huge amount of objects and functionalities from Max6+ to cover). It's insane because whatever work is being done in the "legacy"cyclone will be incorporated in the "modern" on with only a handful of extra features. Should this exist and people should bother with the confusion and do we have to explain to them why it is like that?

But I agree that reducing the scope of the original project and arbitrarily being against the inclusion of particular objects and totally against the inclusion of any objects from an arbitrarily set version of Max should be considered as a fork of the project.

cheers

2016-02-20 20:53 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:

One last question: Does Max/MSP retain all the same class interfaces for version 4/5 classes in later versions of Max/MSP? For example, is Max 7 guaranteed to be backwards compatible with all the internal classes of Max 4.5?

Lets go as low as 4.6, version from the time of cyclone's release.

I, for one, haven't found any backwards compatibility issue yet. All I see is objects respecting backwards compatibility and including a few new features.

Examples: - maximum buffer allowed in buffir~ is now 4096 samples instead of 256.

• [wave~] first offered no interpolation (0) or linear interpolation (1),

now offers 4 other interpolation methods (2-6)

I did search around, I haven't mapped all changes possible one by one, I focused on important objects and found a few things, not much. I mean to say it's probably not too crazy like them updating every object at every new release. Most are still the same in Max 7 as they were in 4.6! I did share all features to be included so objects could be updated, the number it's like new features for 4 or 5 objects...

Now, when implementing new objects that were present in 4.6, one has no good reason to go back to version 4.6 instead of checking Max 7 to clone the new version without even bothering if it is different than before...

Don't know how many of the objects I suggested are also Max6+, pong might be the very only one...

cheers

On Sun, Feb 14, 2016 at 11:27 PM, Jonathan Wilkes jancsika@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 brbrofsvl@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@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 antoine@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 brbrofsvl@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@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@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@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@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@gmail.com mailto:porres@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-3nXy2Q...

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

As Ivica mentioned, abstractions are preferable from an educational point of view. And they are easier to maintain... So I see no problem adding them just like [teeth~]. If performance gets an issue, it is always possible to code that object, or its critical part, in c.

The problem with teeth~ now is that it has no arguments. Ok, that's easy to fix, but there's a problem managing arguments with abstractions, and this is what I was trying to explain in response to Ivica's email.

For example, in [comb~], if you send a signal to an inlet, it overwrites the argument value, but if you disconnect that signal connection it will revert to the argument's value. That's how it works in Max too and I don't know any other way to achieve this other than with an external.

Please find attached an example with comb~ that illustrates this, when you disconnect the signal connection (value of 0) it'll restore the argument value (0.99).

Anyway, this is a common behaviour for such objetcs, so even if it's cool and easy to make an abstraction, ot's just best for the design if you code an external.

Another issue I could point with an abstraction in Pd for [teeth~] is that the delay objects are kinda buggy in Pd, where you can't really go up to the specified delay lenght. I've already reported this by the way. So, a more accurate delay network could be achieved with an external.

Moreover, it should be really easy to make a teeth~ external from the code in comb~

cheers

It would be useful to make a list of things objects often do that abstractions can't​ (or can't do easily).

1. Variable numbers of xlets (except with initbang and dynamic patching,

which is tough to rely on for a library like cyclone) - e.g. [trigger].

2. Main signal inlets that also take messages (e.g. [tabread4~]).

3. Signal inlets which are initialized by an argument and can be set by a

float, where the argument/float value returns if the signal is disconnected (e.g. [osc~].

4. Inlets which take signals or messages depending on the argument (e.g.

[*~ ] vs [*~ 0.5]).

You can all think of others.

On Sat, Feb 13, 2016 at 1:59 PM, Alexandre Torres Porres porres@gmail.com wrote:

As Ivica mentioned, abstractions are preferable from an educational point

...

of view. And they are easier to maintain... So I see no problem adding them just like [teeth~]. If performance gets an issue, it is always possible to code that object, or its critical part, in c.

The problem with teeth~ now is that it has no arguments. Ok, that's easy to fix, but there's a problem managing arguments with abstractions, and this is what I was trying to explain in response to Ivica's email.

For example, in [comb~], if you send a signal to an inlet, it overwrites the argument value, but if you disconnect that signal connection it will revert to the argument's value. That's how it works in Max too and I don't know any other way to achieve this other than with an external.

Please find attached an example with comb~ that illustrates this, when you disconnect the signal connection (value of 0) it'll restore the argument value (0.99).

Anyway, this is a common behaviour for such objetcs, so even if it's cool and easy to make an abstraction, ot's just best for the design if you code an external.

Another issue I could point with an abstraction in Pd for [teeth~] is that the delay objects are kinda buggy in Pd, where you can't really go up to the specified delay lenght. I've already reported this by the way. So, a more accurate delay network could be achieved with an external.

Moreover, it should be really easy to make a teeth~ external from the code in comb~

cheers

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list