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 finis
> 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
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 a
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
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
exte
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 co
+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
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 sug
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, Esteba
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:
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
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/cyclon
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 githu
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.
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
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 lo
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 hex
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 nettle
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(
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 wei
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
> t
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
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
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
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
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
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(~) o
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-- f
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 t
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
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
> 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
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
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 accept
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
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 o
> 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
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
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 '/'
> 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
> wi
[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
> 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 th
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-clo
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 a
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 e
>
> 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
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
47 matches
Mail list logo
