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

[Derek Kwan]

Hello all,

Long time lurker, first time e-mailer. I get the digest version of these
e-mails so apologies if I'm not responding to the thread correctly.

I'm mostly active on the PD FB group and have been working with Alexandre
on updating cyclone, I've done a control rate pong so far and I'm finishing
up control and audio rate rounds, and he suggested I poke my head in. I
haven't been keeping up with the list that well but he gave me a gist of
the ongoings of this thread.

I used to use OS X mainly and used Max a lot (last version I heavily used
was 6) but about a year/year and a half ago got bit by the open-source bug
in a major way, wiped my hd, installed Ubuntu and never looked back. I do
miss a lot of features of Max (particularly matrixctrl, but I really don't
know how the GUI side of PD works) but at the same time appreciate that PD
is its own beast. I don't quite remember how soundfiles worked in Max, but
I really dig the PD approach to them in that everything is an array and I
like the C-like structs, although I haven't quite utilized them in my own
work quite yet. Maybe it's because PD is more spare object-wise or maybe
it's just that I've had more time to learn about programming and
DSP-related things, but working in PD feels less boxing-glovesy than
working in Max. That being said, I don't necessarily advocate an
object-by-object port of any version of Max, I don't want to see PD become
a Max ripoff, but at the same time I think PD can take a lot of inspiration
from some of the functionality of Max, esp. GUI-wise. Furthermore, it would
be nice to have some of that Max-inspired functionality centered in a
common library easily available to PD users. I remember in older days
making patches for people and just telling them to download PD-extended
since I knew all the objects I used were included in that particular
flavor. Anyways, I digress. I think it'd be a good idea to at least
maintain libraries like Cyclone and make sure that their documentation is
clear and accessible and while we're at it, update Cyclone with some of the
newer Max ideas, either direct ports or inspired by objects. The graphical
programming paradigm and Max have evolved a lot since Max 4 and I don't see
the harm in taking advantage of these new developments and putting them
into PD.

Derek

-- 

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

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

[Alexandre Torres Porres]

>  I did share all features to be included

according to my findings and research, of course

2016-02-20 21:34 GMT-02:00 Alexandre Torres Porres :

>
>
> 2016-02-20 20:53 GMT-02:00 Jonathan Wilkes :
>
>> 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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Alexandre Torres Porres]

2016-02-20 20:53 GMT-02:00 Jonathan Wilkes :

> 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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Jonathan Wilkes via Pd-list]

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?
-Jonathan

On Saturday, February 20, 2016 3:13 PM, Alexandre Torres Porres 
 wrote:
 

 
2016-02-20 17:11 GMT-02:00 Jonathan Wilkes via Pd-list :

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 :

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 

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

[Alexandre Torres Porres]

2016-02-20 17:11 GMT-02:00 Jonathan Wilkes via Pd-list :

> 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 :

> 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 :

> +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

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

[Jonathan Wilkes via Pd-list]

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

On Saturday, February 20, 2016 12:57 PM, Matt Barber  
wrote:
 

 +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  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. /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

 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


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

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

[Matt Barber]

+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  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. /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-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
>>
>> ___
>> 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

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

[Ivica Ico Bukvic]

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. 
/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
 
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

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

[Esteban Viveros]

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 <
por...@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 :
>
>> 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.marki...@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 list[1]. If you confirm
>>> this list probably it's better to work to fix bugs.
>>>
>>> Cheers,
>>>
>>> Marco Matteo Markidis
>>>
>>> [1]:
>>> http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
>>>
>>> 2016-02-17 19:33 GMT+01:00 Fred Jan Kraan :
>>>
 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

 ___
 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-lis

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

[Alexandre Torres Porres]

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 :

> 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.marki...@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 list[1]. If you confirm this
>> list probably it's better to work to fix bugs.
>>
>> Cheers,
>>
>> Marco Matteo Markidis
>>
>> [1]:
>> http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
>>
>> 2016-02-17 19:33 GMT+01:00 Fred Jan Kraan :
>>
>>> 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
>>>
>>> ___
>>> 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

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

[Esteban Viveros]

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.marki...@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 list[1]. If you confirm this
> list probably it's better to work to fix bugs.
>
> Cheers,
>
> Marco Matteo Markidis
>
> [1]:
> http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
>
> 2016-02-17 19:33 GMT+01:00 Fred Jan Kraan :
>
>> 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
>>
>> ___
>> 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

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

[Marco Matteo Markidis]

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 list[1]. If you confirm this
list probably it's better to work to fix bugs.

Cheers,

Marco Matteo Markidis

[1]: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html

2016-02-17 19:33 GMT+01:00 Fred Jan Kraan :

> 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
>
> ___
> 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

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

[Fred Jan Kraan]

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

 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

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

[Alexandre Torres Porres]

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

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!

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.

cheers

cheers

2016-02-16 16:39 GMT-02:00 Fred Jan Kraan :

> 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
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Fred Jan Kraan]

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

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

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

[Alexandre Torres Porres]

2016-02-15 20:33 GMT-02:00 Martin Peach :

> 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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Alexandre Torres Porres]

2016-02-15 18:23 GMT-02:00 Fred Jan Kraan 
>
> Most of cyclone are single objects files, as per pd-extended. The nettles
> part is a multi object library file. This seemed the simplest way to
> re-introduce them while avoiding the weird symbol issues. [declare] seemed
> more elegant than adding hexloader compliant object file names.
>

I'm sorry this is  still hard for me to get, so I need to keep asking
questions about what you mean. I guess I'm having a harder time
understanding what you mean by "adding hexloader compliant object file
names".

But I know this: I downlaoded zexy form deken and included it in the search
path of pd vanilla 0.46-7. I can now easily load an object like [>~]
without the need of the [hexloader] object, [declare] or anything.

There were also other given reasons, like this not being possible in a
particular OS, but that doesn't seem to be a problem.

So, simply put, it is possible... why couldn't we do this with cyclone? Or
is it quite possible but there is a choice not to do it?

Using declare is making it harder, so if there's a way to prevent it, I
strongly believe, as a Pd user that we should prevent it. In fact, I have
to confess that in 10 years of patching with Pd I had never needed to use
[declare], this is the first time I had to read its help file. I have also
written over 320 examples for my classes in Pd Extended and never had to
use it.

I find it really problematic that it seems you have to include flags, know
a weird name not related to "cyclone" and, worst of all, save and close
your patch to reopen and then be able to get the object you want. This is
really a bad choice over just being able to load the object without any of
this.

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

cheers

2016-02-15 20:21 GMT-02:00 Alexandre Torres Porres :

> 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
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Martin Peach]

On Mon, Feb 15, 2016 at 5:21 PM, Alexandre Torres Porres 
wrote:

> 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!
>


Looks like it. You just need to make sure that code is called somehow, e.g.
by declaring its library.


>
> ...
>

But I just believe you can have them load with no problem in any OS now,
> right?
>
>
>
They should load on any OS, as long as the library setup has been done so
Pd knows about them.

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

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

[Alexandre Torres Porres]

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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Fred Jan Kraan]

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


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.


Most of cyclone are single objects files, as per pd-extended. The 
nettles part is a multi object library file. This seemed the simplest 
way to re-introduce them while avoiding the weird symbol issues. 
[declare] seemed more elegant than adding hexloader compliant object 
file names.


Martin


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

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

[Martin Peach]

On Mon, Feb 15, 2016 at 10:36 AM, Alexandre Torres Porres 
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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Ivica Bukvic]

On Sun, Feb 14, 2016 at 11:27 PM, Jonathan Wilkes 
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 
> 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"  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 
> 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:

Re: [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 
:

> 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 
> 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"  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 crea

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

[Jonathan Wilkes via 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  
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"  wrote:


On Sun, Feb 14, 2016 at 5:54 PM, Jonathan Wilkes via Pd-list 
 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  
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 :

> 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  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 prom

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

[Matt Barber]

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"  wrote:

>
> On Sun, Feb 14, 2016 at 5:54 PM, Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at> wrote:
>
>> Hi Antoine,
>> We're talking about two different kinds of "dynamic" nlets.  Yours seems
>> to
>> set a value for the signal based on whether or not there is a connection
>> to that
>> inlet.  What I'm talking about is a future object that would elegantly
>> handle
>> the creation of a variable number of inlets(~) or outlets(~) inside an
>> abstraction.
>>
>> I'm pressing Ivica specifically on variable signal nlets because there's
>> no way
>> to flexibly handle them.
>>
>
> Why not? First of all, we need to agree that such an object would be
> mostly useful at instantiation time (e.g. a silly example would be an
> abstraction that mimics selector~ behavior) and in dynamic patching where
> after creation one would need to connect bunch of stuff to this object and
> ensure that inside the abstraction additional inlets actually do something.
> Second, let's assume the dynamic nlet creation object is the rightmost
> object (otherwise user is asking for potential problems if something is
> already connected to the second inlet and then suddenly first inlet grows a
> couple more inlets before the second one--even this could be potentially
> handled, with adequate changes inside the pd core, or in this case pd-l2ork
> core). Now, if new nlets are generated, they will not autoconnect to
> anything--this is user's responsibility likely through some sort of live or
> scripted patching at instantiation time which could be driven from the same
> argument. Once that is all taken into an account, the last thing is to
> consider:
>
> suspend dsp
> instantiate new object
> rebuild dsp graph (as you would with instantiation of any new signal object
> resume dsp
> redraw object and parent object on its parent canvases
>
> One lingering concern is that this would effectively make the abstraction
> dirty which could be either seen as a good thing or handled as something
> that does not trigger the dirty flag.
>
> Best,
>
> Ico
>
>
>>
>> -Jonathan
>>
>>
>> On Sunday, February 14, 2016 5:34 PM, Antoine Rousseau <
>> anto...@metalu.net> wrote:
>>
>>
>> I've only partially followed all this discussion (not using Max myself),
>> but maybe an object I wrote could help you building such abstractions :
>>
>> [moonlib/dinlet~] is an [inlet~] with an init float value (constant
>> signal) as an argument.
>> This default value is overloaded when a signal is connected to the inlet,
>> but restored when the signal is disconnected. A float sent to it would
>> overwrite the default constant value.
>>
>> Of course the init default value could be one of the abstraction's
>> arguments ($xxx)...
>>
>> BUT :
>>
>> - there is a very little hack (which could be called a bugfix...) that
>> has to be made to pd source (this change is written in comment in the
>> source file of dinlet~). I should open a ticket for that in the sourceforge
>> repo. The involved bug is mixing the different float values up when
>> [dinlet~] is used together with normal [inlet]s.
>>
>> - I should add a missing feature in dinlet~, which would add an inlet to
>> the [dinlet~] object itself, to allow changing the default value inside of
>> the abstraction.
>>
>> If anyone think this would be helpful, I could do this (open a ticket and
>> update moonlib about this missing inlet).
>>
>>
>>
>> 2016-02-14 20:29 GMT+01:00 Jonathan Wilkes via Pd-list <
>> pd-list@lists.iem.at>:
>>
>> > Why not simply have an inlet that can handle both inside an abstraction
>> and route signal one way and number the other and then sprinkle that with
>> dynamic nlet creation and you're done? Then you can simply abstract most
>> cases.
>>
>> I read (and like) your spec on dynamic nlet creation, but I have a
>> problem with section 2.1 Signals:
>>
>> "To handle the dynamic creation of signal inlets and their routing within
>> the abstraction, the implementation must"
>>
>> It looks like the rest of the section is missing. :)
>>
>> -Jonathan
>>
>>
>>
>>
>> On Sunday, February 14, 2016 1:51 PM, Matt Barber 
>> 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  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 

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

[Ivica Bukvic]

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 
> 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 
> 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  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  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 obj

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

[Jonathan Wilkes via Pd-list]

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  
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 :

> 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  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  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  wrote:
 
 What I am also trying to do eventually in pd-l2ork is weed out redundant 
objects and only keep the ones that do the said task the best while still 
supporting other objects' idiosyncrasies (if any). There is absolutely no 
reason to have multiple objects of the same kind. Ultimately, one could keep 
all the externals in the same folder and completely do away with all the 
declares, imports, and other things that make learning pd  unnecessarily 
harder. -- 
 Ivica Ico Bukvic, D.M.A.
 Associate Professor
 Computer Music
 ICAT Senior Fellow
 Director -- DISIS, L2Ork
 Virginia Tech
 School of Performing Arts – 0141
 Blacksburg, VA 24061
 (540) 231-6139
 i...@vt.edu
 www.performingarts.vt.edu
 disis.icat.vt.edu
 l2ork.icat.vt.edu
 ico.bukvic.net   On Feb 14, 2016 8:40 AM, "Fred Jan Kraan"  
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 mailto:por...@gmail.com>>:
 
     Howdy, it's a known fact brazilians will start the year only after
     carnival, so here I am.
 
     I'd like to share my list of things to do with existing Cyclone
     Objetcs. Obviously the

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

[Alexandre Torres Porres]

2016-02-14 15:55 GMT-02:00 Jonathan Wilkes via 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.
>

Jonathan, I don't ever need [hexloader] with the cyclone objects, because I
don't even have it in my latest vanilla.

So, apparently, because the way it was build, it just loads without these
issues and seemingly will load in any OS as I've been saying.

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

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

[Antoine Rousseau]

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 :

> > 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 
> 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  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  wrote:
>
> What I am also trying to do eventually in pd-l2ork is weed out redundant
> objects and only keep the ones that do the said task the best while still
> supporting other objects' idiosyncrasies (if any). There is absolutely no
> reason to have multiple objects of the same kind. Ultimately, one could
> keep all the externals in the same folder and completely do away with all
> the declares, imports, and other things that make learning pd unnecessarily
> harder.
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
> On Feb 14, 2016 8:40 AM, "Fred Jan Kraan"  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  >:
>
> 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
>
>
> htt

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

[Alexandre Torres Porres]

2016-02-14 14:57 GMT-02:00 Claude Heiland-Allen :
>
> hexloader is only need for 2 cases afaict:
>
> 1. if you want an abstractions with '/' in the object name
>(not allowed by filesystems)
>

Is it really just the "/" character? And is this case independent from #2?

Because... we were talking here about other characters such as "<"

And also, I can load objects like [!/~] from the newest cyclone without
[hexloader].

So I'm not sure about this.


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

Now, yeah, apparently, the greatest issue is how you build it...

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

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

[Alexandre Torres Porres]

2016-02-14 16:42 GMT-02:00 IOhannes m zmölnig :
>
> 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 :

> 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-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Jonathan Wilkes via Pd-list]

> 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  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  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  wrote:
 
 What I am also trying to do eventually in pd-l2ork is weed out redundant 
objects and only keep the ones that do the said task the best while still 
supporting other objects' idiosyncrasies (if any). There is absolutely no 
reason to have multiple objects of the same kind. Ultimately, one could keep 
all the externals in the same folder and completely do away with all the 
declares, imports, and other things that make learning pd  unnecessarily 
harder. -- 
 Ivica Ico Bukvic, D.M.A.
 Associate Professor
 Computer Music
 ICAT Senior Fellow
 Director -- DISIS, L2Ork
 Virginia Tech
 School of Performing Arts – 0141
 Blacksburg, VA 24061
 (540) 231-6139
 i...@vt.edu
 www.performingarts.vt.edu
 disis.icat.vt.edu
 l2ork.icat.vt.edu
 ico.bukvic.net   On Feb 14, 2016 8:40 AM, "Fred Jan Kraan"  
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 mailto:por...@gmail.com>>:
 
     Howdy, it's a known fact brazilians will start the year only after
     carnival, so here I am.
 
     I'd like to share my list of things to do with existing Cyclone
     Objetcs. Obviously there might be other issues with other objects
     that would make them up to date with the current version of Max (Max
     7). Nonetheless, this is what I find relevant, and I've been really
     checking it through.
 
     It's only about 11 objects, some has already been discussed here and
     might have been fixed or in the process to be taken care of, forgive
     me if so.
 
     I have it attached and also as a link to a google doc
 
     
https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing
 
     Next, I will get together a list of new objects I think should be
     included, many of which I've already made as abstractions (kind of
     to show how it works like I did with [teeth~], cause I really think
     they should all be done as externals).
 
     Cheers
 
 
 
 
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list
 

 ___
 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

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

[IOhannes m zmölnig]

On 02/14/2016 05:36 PM, Alexandre Torres Porres wrote:
> Ok, but I still don't get how this problem manifests itself.
> 

objects can have any names, on all operating system.

there are two problems though, both related with loading a file that
provides an objectclass.

this is because the Pd looks for a file named after the objectclass, and
once it has found that file it will look for a function within the file
named after the objectclass.

but:

#1 filenames have some restrictions (and different restrictions on
different platforms/filesystems).
often special characters like "<", ">", "&", "|", "/", and "\" in
filenames are problematic/forbidden.
(sometimes ordinary names are forbidden, try "AUX" on w32).
some filesystems don't even distinguish between "Cycle" and "cycle"
(shudder).

#2 function names have even more restrictions (they can basically only
consist of letters, numbers and underscore, but must not start with a
number.

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

because
#1 hexloader solves the problems explained  above.
AND
#2 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.


dmsare
IOhannes




signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Ivica Bukvic]

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  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  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  wrote:
>>
>>> What I am also trying to do eventually in pd-l2ork is weed out redundant
>>> objects and only keep the ones that do the said task the best while still
>>> supporting other objects' idiosyncrasies (if any). There is absolutely no
>>> reason to have multiple objects of the same kind. Ultimately, one could
>>> keep all the externals in the same folder and completely do away with all
>>> the declares, imports, and other things that make learning pd unnecessarily
>>> harder.
>>>
>>> --
>>> Ivica Ico Bukvic, D.M.A.
>>> Associate Professor
>>> Computer Music
>>> ICAT Senior Fellow
>>> Director -- DISIS, L2Ork
>>> Virginia Tech
>>> School of Performing Arts – 0141
>>> Blacksburg, VA 24061
>>> (540) 231-6139
>>> i...@vt.edu
>>> www.performingarts.vt.edu
>>> disis.icat.vt.edu
>>> l2ork.icat.vt.edu
>>> ico.bukvic.net
>>> On Feb 14, 2016 8:40 AM, "Fred Jan Kraan"  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  >:
>
> Howdy, it's a known fact brazilians will start the year only after
> carnival, so here I am.
>
> I'd like to share my list of things to do with existing Cyclone
> Objetcs. Obviously there might be other issues with other objects
> that would make them up to date with the current version of Max
> (Max
> 7). Nonetheless, this is what I find relevant, and I've been really
> checking it through.
>
> It's only about 11 objects, some has already been discussed here
> and
> might have been fixed or in the process to be taken care of,
> forgive
> me if so.
>
> I have it attached and also as a link to a google doc
>
>
> https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing
>
> Next, I will get together a list of new objects I think should be
> included, many of which I've already made as abstractions (kind of
> to show how it works like I did with [teeth~], cause I really think
> they should all be done as externals).
>
> Cheers
>
>
>
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management ->
 
 http://lists.puredata.info/listinfo/pd-list

>>>
>>> ___
>>> 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

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

[Matt Barber]

​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  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  wrote:
>
>> What I am also trying to do eventually in pd-l2ork is weed out redundant
>> objects and only keep the ones that do the said task the best while still
>> supporting other objects' idiosyncrasies (if any). There is absolutely no
>> reason to have multiple objects of the same kind. Ultimately, one could
>> keep all the externals in the same folder and completely do away with all
>> the declares, imports, and other things that make learning pd unnecessarily
>> harder.
>>
>> --
>> Ivica Ico Bukvic, D.M.A.
>> Associate Professor
>> Computer Music
>> ICAT Senior Fellow
>> Director -- DISIS, L2Ork
>> Virginia Tech
>> School of Performing Arts – 0141
>> Blacksburg, VA 24061
>> (540) 231-6139
>> i...@vt.edu
>> www.performingarts.vt.edu
>> disis.icat.vt.edu
>> l2ork.icat.vt.edu
>> ico.bukvic.net
>> On Feb 14, 2016 8:40 AM, "Fred Jan Kraan"  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 >>> >:

 Howdy, it's a known fact brazilians will start the year only after
 carnival, so here I am.

 I'd like to share my list of things to do with existing Cyclone
 Objetcs. Obviously there might be other issues with other objects
 that would make them up to date with the current version of Max (Max
 7). Nonetheless, this is what I find relevant, and I've been really
 checking it through.

 It's only about 11 objects, some has already been discussed here and
 might have been fixed or in the process to be taken care of, forgive
 me if so.

 I have it attached and also as a link to a google doc


 https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing

 Next, I will get together a list of new objects I think should be
 included, many of which I've already made as abstractions (kind of
 to show how it works like I did with [teeth~], cause I really think
 they should all be done as externals).

 Cheers



>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> 
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>> ___
>> 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

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

[Ivica Ico Bukvic]

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 > wrote:


What I am also trying to do eventually in pd-l2ork is weed out
redundant objects and only keep the ones that do the said task the
best while still supporting other objects' idiosyncrasies (if
any). There is absolutely no reason to have multiple objects of
the same kind. Ultimately, one could keep all the externals in the
same folder and completely do away with all the declares, imports,
and other things that make learning pd unnecessarily harder.

-- 
Ivica Ico Bukvic, D.M.A.

Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139 
i...@vt.edu 
www.performingarts.vt.edu 
disis.icat.vt.edu 
l2ork.icat.vt.edu 
ico.bukvic.net 

On Feb 14, 2016 8:40 AM, "Fred Jan Kraan" mailto:fjkr...@xs4all.nl>> wrote:

Hi Alexandre,

guess some of it is in:

http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html


This list is also becoming a list of what has been done.


As with _nettles_

"try to resurrect as independent object library"

Anyway, tell me if this gets includes on this file.


Yes, the nettles-objects are part of the latest cyclone
versions. They are part of the nettles library, which can be
loaded with [declare]. Not all operating systems like the '<'
and '>' in the object names and there is overlap with other
library objects, so only loading them when needed is cleaner.


cheers

ps. count me in for help with the help files


Great!

Greetings,

Fred Jan


2016-02-11 22:18 GMT-02:00 Alexandre Torres Porres
mailto:por...@gmail.com>
>>:

Howdy, it's a known fact brazilians will start the
year only after
carnival, so here I am.

I'd like to share my list of things to do with
existing Cyclone
Objetcs. Obviously there might be other issues with
other objects
that would make them up to date with the current
version of Max (Max
7). Nonetheless, this is what I find relevant, and
I've been really
checking it through.

It's only about 11 objects, some has already been
discussed here and
might have been fixed or in the process to be taken
care of, forgive
me if so.

I have it attached and also as a link to a google doc


https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing

Next, I will get together a list of new objects I
think should be
included, many of which I've already made as
abstractions (kind of
to show how it works like I did with [teeth~], cause I
really think
they should all be done as externals).

Cheers



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


___
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

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

[Jonathan Wilkes via 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.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Alexandre Torres Porres]

2016-02-14 14:36 GMT-02:00 Matt Barber :

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

The thing with the max objects is the same as I pointed with the [comb~]
object, if the signal inlet is disconnected, the argument value is
restored. So it's only as an object.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Claude Heiland-Allen]

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


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

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

[Alexandre Torres Porres]

> 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?

2016-02-14 14:31 GMT-02:00 Jonathan Wilkes via Pd-list :

> 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  wrote:
>
>
> What I am also trying to do eventually in pd-l2ork is weed out redundant
> objects and only keep the ones that do the said task the best while still
> supporting other objects' idiosyncrasies (if any). There is absolutely no
> reason to have multiple objects of the same kind. Ultimately, one could
> keep all the externals in the same folder and completely do away with all
> the declares, imports, and other things that make learning pd unnecessarily
> harder.
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
> On Feb 14, 2016 8:40 AM, "Fred Jan Kraan"  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  >:
>
> Howdy, it's a known fact brazilians will start the year only after
> carnival, so here I am.
>
> I'd like to share my list of things to do with existing Cyclone
> Objetcs. Obviously there might be other issues with other objects
> that would make them up to date with the current version of Max (Max
> 7). Nonetheless, this is what I find relevant, and I've been really
> checking it through.
>
> It's only about 11 objects, some has already been discussed here and
> might have been fixed or in the process to be taken care of, forgive
> me if so.
>
> I have it attached and also as a link to a google doc
>
>
> https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing
>
> Next, I will get together a list of new objects I think should be
> included, many of which I've already made as abstractions (kind of
> to show how it works like I did with [teeth~], cause I really think
> they should all be done as externals).
>
> Cheers
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
> ___
> 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

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

[Matt Barber]

[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  wrote:

> What I am also trying to do eventually in pd-l2ork is weed out redundant
> objects and only keep the ones that do the said task the best while still
> supporting other objects' idiosyncrasies (if any). There is absolutely no
> reason to have multiple objects of the same kind. Ultimately, one could
> keep all the externals in the same folder and completely do away with all
> the declares, imports, and other things that make learning pd unnecessarily
> harder.
>
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
> On Feb 14, 2016 8:40 AM, "Fred Jan Kraan"  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 >> >:
>>>
>>> Howdy, it's a known fact brazilians will start the year only after
>>> carnival, so here I am.
>>>
>>> I'd like to share my list of things to do with existing Cyclone
>>> Objetcs. Obviously there might be other issues with other objects
>>> that would make them up to date with the current version of Max (Max
>>> 7). Nonetheless, this is what I find relevant, and I've been really
>>> checking it through.
>>>
>>> It's only about 11 objects, some has already been discussed here and
>>> might have been fixed or in the process to be taken care of, forgive
>>> me if so.
>>>
>>> I have it attached and also as a link to a google doc
>>>
>>>
>>> https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing
>>>
>>> Next, I will get together a list of new objects I think should be
>>> included, many of which I've already made as abstractions (kind of
>>> to show how it works like I did with [teeth~], cause I really think
>>> they should all be done as externals).
>>>
>>> Cheers
>>>
>>>
>>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
> ___
> 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

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

[Alexandre Torres Porres]

> 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 :

> On Sun, Feb 14, 2016 at 10:00 AM, Alexandre Torres Porres <
> por...@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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Jonathan Wilkes via Pd-list]

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  wrote:
 

 What I am also trying to do eventually in pd-l2ork is weed out redundant 
objects and only keep the ones that do the said task the best while still 
supporting other objects' idiosyncrasies (if any). There is absolutely no 
reason to have multiple objects of the same kind. Ultimately, one could keep 
all the externals in the same folder and completely do away with all the 
declares, imports, and other things that make learning pd unnecessarily 
harder.-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.netOn Feb 14, 2016 8:40 AM, "Fred Jan Kraan"  
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 mailto:por...@gmail.com>>:

    Howdy, it's a known fact brazilians will start the year only after
    carnival, so here I am.

    I'd like to share my list of things to do with existing Cyclone
    Objetcs. Obviously there might be other issues with other objects
    that would make them up to date with the current version of Max (Max
    7). Nonetheless, this is what I find relevant, and I've been really
    checking it through.

    It's only about 11 objects, some has already been discussed here and
    might have been fixed or in the process to be taken care of, forgive
    me if so.

    I have it attached and also as a link to a google doc

    
https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing

    Next, I will get together a list of new objects I think should be
    included, many of which I've already made as abstractions (kind of
    to show how it works like I did with [teeth~], cause I really think
    they should all be done as externals).

    Cheers




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


___
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

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

[Ivica Bukvic]

What I am also trying to do eventually in pd-l2ork is weed out redundant
objects and only keep the ones that do the said task the best while still
supporting other objects' idiosyncrasies (if any). There is absolutely no
reason to have multiple objects of the same kind. Ultimately, one could
keep all the externals in the same folder and completely do away with all
the declares, imports, and other things that make learning pd unnecessarily
harder.

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Feb 14, 2016 8:40 AM, "Fred Jan Kraan"  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 > >:
>>
>> Howdy, it's a known fact brazilians will start the year only after
>> carnival, so here I am.
>>
>> I'd like to share my list of things to do with existing Cyclone
>> Objetcs. Obviously there might be other issues with other objects
>> that would make them up to date with the current version of Max (Max
>> 7). Nonetheless, this is what I find relevant, and I've been really
>> checking it through.
>>
>> It's only about 11 objects, some has already been discussed here and
>> might have been fixed or in the process to be taken care of, forgive
>> me if so.
>>
>> I have it attached and also as a link to a google doc
>>
>>
>> https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing
>>
>> Next, I will get together a list of new objects I think should be
>> included, many of which I've already made as abstractions (kind of
>> to show how it works like I did with [teeth~], cause I really think
>> they should all be done as externals).
>>
>> Cheers
>>
>>
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Martin Peach]

On Sun, Feb 14, 2016 at 10:00 AM, Alexandre Torres Porres 
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

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

[Alexandre Torres Porres]

>
> 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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Fred Jan Kraan]

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 mailto:por...@gmail.com>>:

Howdy, it's a known fact brazilians will start the year only after
carnival, so here I am.

I'd like to share my list of things to do with existing Cyclone
Objetcs. Obviously there might be other issues with other objects
that would make them up to date with the current version of Max (Max
7). Nonetheless, this is what I find relevant, and I've been really
checking it through.

It's only about 11 objects, some has already been discussed here and
might have been fixed or in the process to be taken care of, forgive
me if so.

I have it attached and also as a link to a google doc


https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing

Next, I will get together a list of new objects I think should be
included, many of which I've already made as abstractions (kind of
to show how it works like I did with [teeth~], cause I really think
they should all be done as externals).

Cheers




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