Re: [PD] Missing objects/methods in Pd WAS: objects with no alphanumerical names, how to build them?

[Dan Wilcox]

> On Apr 5, 2016, at 5:59 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Joking aside, at least some externals that prove to be very useful or even 
> fundamental (like zexy's sigops or [z~]) could find its way into the core now 
> and then. To me, Pd vanilla seems to be overly conservative in this respect. 
> On the other hand, I like that the set of objects is rather restricted, it's 
> just about a handful of objects which I think are really missing and 
> shouldn't require a user to get an external library. 
> 
> And when there are already good externals which do an important job, why not 
> include them? For example, Pd vanilla got its own set of OSC objects recently 
> (nice!), but they are rather awkward to use and have far less functionality 
> then, for example, the mrpeach objects (Miller actually refers to them in the 
> help patch).


The answer is maintainability:

OF has 3 core members and 10+ affiliated core devs with commit access.

Pd has 1 core member with commit access.

I feel like OF right now is where PD was circle early 2000s. At some point it 
will stabilize since so many people rely on it and get tired of bugs and 
breaking changes introduced by *so* many commits by so many people. IMO the OF 
core is now way too large and parts of it should be spun off as addons.

It makes more sense to have a solid, slim core which you can add functionality 
to -> externals. This way, we get stability at a (small) loss of convenience by 
having to add an external. deken will make this relatively painless once the 
next Pd release comes out.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 

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

Re: [PD] Missing objects/methods in Pd WAS: objects with no alphanumerical names, how to build them?

[Alexandre Torres Porres]

howdy, I guess you missed the "pd is limited" discussion from not long
ago...

well, vanilla is quite limited and there surely reasons for it. I can't
really answer you cause I don't know exactly what they are, I guess I'd
like to hear more about it too.

like anything in this world, something with particular characteristics have
advantages and disadvantages. A smaller package is easier for someone like
Miller to develop - it also makes it easy to allow things like libpd to
exist.

I guess lots of people didn't care much about vanilla's limitation as they
were using Pd-Extended. That's how I came to know pd over 10 years ago now
(damn). And what it was could be thought of as a not limited version of Pd.

To answer your inquiry, I, for one, could list so many things that I miss
in Pd Vanilla that I'd be actually describing how I miss a fork of Pd
Vanilla that relates to what Pd Extended was...

I guess it's alright that vanilla keeps it plain simple and that we have to
rely on external libraries. It's hard to say where to stop enhancing
vanilla... I guess there is no limit, the arbitrary line must be drawn by
whoever is running it to the point where it's reasonable to handle and
manage.

But anyway, the thing is that if vanilla is limited, then we need to rely
on many libraries, and the issue now becomes the external addons and who is
taking care of them. I could point that things aren't that well when we see
that the the great majority of pd-extended's libraries are currently
unmaintained (not to mention how Extended died on its own).

If most of these libraries were still being supported, and if the community
worked on a distribution with many features/libraries already wrapped
around vanilla, we wouldn't be having the 'what's missing in vanilla
discussion".

having said all that and not really concluding, I can say I miss in Pd
Vanilla:

a clear message in delwrite~
a peak amplitude output to env~
a wrap function in expr
a way to set initial state/current input samples in fexpr~
a knob GUI

a way to specify that the object I'm creating is from a particular external
library

and that pd~ external for max actually running

and finally, a patch that would make me a lot of money...

cheers


2016-04-05 20:59 GMT-03:00 Christof Ressi :

> Actually I never understood why relational and bitwise signal operators
> were never included in vanilla...
>
> Or: why zexy as a whole (despite of some obsolete objects) isn't part of
> the core :-).
>
> Joking aside, at least some externals that prove to be very useful or even
> fundamental (like zexy's sigops or [z~]) could find its way into the core
> now and then. To me, Pd vanilla seems to be overly conservative in this
> respect. On the other hand, I like that the set of objects is rather
> restricted, it's just about a handful of objects which I think are really
> missing and shouldn't require a user to get an external library.
>
> And when there are already good externals which do an important job, why
> not include them? For example, Pd vanilla got its own set of OSC objects
> recently (nice!), but they are rather awkward to use and have far less
> functionality then, for example, the mrpeach objects (Miller actually
> refers to them in the help patch).
>
> I personally like how openFrameworks, for example, makes good addons part
> of the core (ofxOsc, ofxGui ...).
>
>
> Another thing: there are definitely some methods missing in [list] and
> [array], like sorting, searching, iterating, inserting... Why do I have to
> rely on an external to sort a list? Just imagine the shock of someone
> coming from SuperCollider :-D.
>
> Don't get me wrong: The limited set of objects in vanilla definitely has
> its charme but in many aspects it seems too narrow.
>
> Maybe we could have a discussion, like: Which objects/methods are you
> missing the most in Pd vanilla?
>
>
>
> Gesendet: Dienstag, 05. April 2016 um 17:12 Uhr
> Von: "Jonathan Wilkes via Pd-list" 
> An: "Alexandre Torres Porres" , "Roman Haefeli" <
> reduz...@gmail.com>
> Cc: "pd-list@lists.iem.at" 
> Betreff: Re: [PD] objects with no alphanumerical names, how to build them?
>
> Here's some Pd Fan Fiction:
>
> Relational sigop author: Hey I got relational sigops.  You want them?
> Pd author: Yeah thanks, I forgot about those. *copy/paste*
> Pd community: Yay!
>
> Fin.
>
> -Jonathan
>
>
> On Tuesday, April 5, 2016 10:46 AM, Alexandre Torres Porres <
> por...@gmail.com> wrote:
>
>
>
> 2016-04-05 5:08 GMT-03:00 Roman Haefeli : If you're
> simply interested in knowing how things work technically, fine.
>
> I'd love to know, for sure, that's why I'm asking :)
>
>  Now that we have a chance to get rid of all hexloader related kludges,
> now you come and bring it up again.
>
> You see, I don't really get what you mean by "hexloader" or its related
> kludges. All I know is some [hexloader] object that is in my pd extended
> 0.42-5, and all I know is that I need to use it in order to load the [==~]
> object from zexy. What yo

Re: [PD] sanity check on workings of pd~

[Matt Barber]

You can get it down to one block. You can try zero, but it will crash;
maybe that's a bug (that is, maybe it shouldn't honor the request with an
attempt).

The default is five blocks of delay, if I remember correctly.

On Wed, Apr 6, 2016 at 12:00 AM, Miller Puckette  wrote:

> It has a specifiable delay in blocks, minimum 2 I believe.
>
> cheers
> Miller
>
> On Wed, Apr 06, 2016 at 02:52:10AM +, Jonathan Wilkes via Pd-list
> wrote:
> > Hi list,Does [pd~] have a one-block delay?
> > Thanks,Jonathan
> >
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Name conflicts "class overwritten; old one renamed 'x_aliased'

[Alexandre Torres Porres]

2016-04-05 20:37 GMT-03:00 cyrille henry :

> pd-l2ork is more recent, so i guess it use all latest vanilla feature.
>

not really, seems pd-l2ork hasn't been kept up to date to any specific
vanilla versio, like extended used to, so it's definitely a forkk per se.
And for what I tried, pd-l2ork behaves like extended 0.42-5, what I'm using
as a basis for comparison. I also tried vanilla 0.42-5 and saw that it
already have the overwriting feature, so I assumed is something they didn't
want in extended (0.43 still didn't have the overwritting, huh?).


> I think the aim is to be able to create object that are more optimized
> than native one. Or that add functionalities.
>

Seems not healthy in any way. If you want to make a better pd, well, you
can chose different names for externals, or really just fork it.

In general, I don't see any good reason to have externals with the same
name as vanilla internals, other than max/msp clones like good old cyclone
- but the way to deal with in extended worked fine, if you want line~ that
is compatible to max, use cyclone/line~


> Of course, one can use this feature to completely break pd.
>

yep



> it's possible to develop a [+] object that add number and string.
>

also possible to give it another name, or even to call [+] in a way that is
not overwritting an internal.


> there is no problem overwriting a vanilla object as long as you keep
> compatibilities.
>

well, for one, cyclone/line~ is not compatible.


> So, i don't see any problem overwriting vanilla objects, as long as object
> developers don't do anything stupid.
>

well, I pointed some existing issues that lies outside what you pictured...
and there is also other issues besides internals.


> anyhow, it make sens to be able to load zexy/<~ or nettles/<~ even if zexy
> and nettles are loaded as a lib. but [<~] is not vanilla, so this is an
> other discussion than vanilla object being overwritten.
>

another discussion, but quite parallel and that arise from the same matter.

and for this specific object, what make more sense to me is to use a small
> abstraction made around tabread~ and a 2 points table.
> 100% vanilla.
> 0% trouble.
>

well, it really makes sense to me not to bother to think of a vanilla
abstraction to substitute 2 existing externals that I already have...

And I can also remember several other external objects with the same name
that aren't compatible - such as "uzi" as an alias of kalashnikov or uzi
from cyclone...

it just makes a lot of sense to me tha Pd allows the user to have some
control over what objects and externals to call.

Way things are now, we have NO control whatsoever and this is bad. You
cannot guarantee that your patches will work as they should anywhere. It
would be good to attack this problem by actually allowing control to the
user, instead of being happy with laboring workarounds that don't really
solve anything and might even create more hassle...

I can think of many options to allow control to the user. Not allowing
vanilla objects to be overwritten is one. Allowing a user to choose an
object from a specific library os another. Both would solve this... and
seems like the best solution to me. On the other hand, I cannot think, yet,
of any good reason to leave things the way they are.

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

Re: [PD] sanity check on workings of pd~

[Miller Puckette]

It has a specifiable delay in blocks, minimum 2 I believe.

cheers
Miller

On Wed, Apr 06, 2016 at 02:52:10AM +, Jonathan Wilkes via Pd-list wrote:
> Hi list,Does [pd~] have a one-block delay?
> Thanks,Jonathan
> 

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


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

[PD] sanity check on workings of pd~

[Jonathan Wilkes via Pd-list]

Hi list,Does [pd~] have a one-block delay?
Thanks,Jonathan

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

[PD] Missing objects/methods in Pd WAS: objects with no alphanumerical names, how to build them?

[Christof Ressi]

Actually I never understood why relational and bitwise signal operators were 
never included in vanilla... 

Or: why zexy as a whole (despite of some obsolete objects) isn't part of the 
core :-).

Joking aside, at least some externals that prove to be very useful or even 
fundamental (like zexy's sigops or [z~]) could find its way into the core now 
and then. To me, Pd vanilla seems to be overly conservative in this respect. On 
the other hand, I like that the set of objects is rather restricted, it's just 
about a handful of objects which I think are really missing and shouldn't 
require a user to get an external library. 

And when there are already good externals which do an important job, why not 
include them? For example, Pd vanilla got its own set of OSC objects recently 
(nice!), but they are rather awkward to use and have far less functionality 
then, for example, the mrpeach objects (Miller actually refers to them in the 
help patch).

I personally like how openFrameworks, for example, makes good addons part of 
the core (ofxOsc, ofxGui ...).


Another thing: there are definitely some methods missing in [list] and [array], 
like sorting, searching, iterating, inserting... Why do I have to rely on an 
external to sort a list? Just imagine the shock of someone coming from 
SuperCollider :-D.

Don't get me wrong: The limited set of objects in vanilla definitely has its 
charme but in many aspects it seems too narrow. 

Maybe we could have a discussion, like: Which objects/methods are you missing 
the most in Pd vanilla?



Gesendet: Dienstag, 05. April 2016 um 17:12 Uhr
Von: "Jonathan Wilkes via Pd-list" 
An: "Alexandre Torres Porres" , "Roman Haefeli" 

Cc: "pd-list@lists.iem.at" 
Betreff: Re: [PD] objects with no alphanumerical names, how to build them?

Here's some Pd Fan Fiction:
 
Relational sigop author: Hey I got relational sigops.  You want them?
Pd author: Yeah thanks, I forgot about those. *copy/paste*
Pd community: Yay!
 
Fin.
 
-Jonathan
 

On Tuesday, April 5, 2016 10:46 AM, Alexandre Torres Porres  
wrote: 

 
 
2016-04-05 5:08 GMT-03:00 Roman Haefeli : If you're simply 
interested in knowing how things work technically, fine.
 
I'd love to know, for sure, that's why I'm asking :)

 Now that we have a chance to get rid of all hexloader related kludges,
now you come and bring it up again.
 
You see, I don't really get what you mean by "hexloader" or its related 
kludges. All I know is some [hexloader] object that is in my pd extended 
0.42-5, and all I know is that I need to use it in order to load the [==~] 
object from zexy. What you're talking about, somehow, relates to that? 
 
Anyway, seems so to me... and if so, the thing is that what I'm asking and 
doing has nothing to do with "hexloader"... (I never even mentioned about 
"hexloader", btw) ... and I read about the "hex loader" discussion as 
suggested, and found stuff that I didn't really think was related to my 
questions. Yeah, like I said, I don't really know much and I'd like to know, so 
I might be missing something, and someone can help me with it...
 
But the thing is, all I asked was how to compile an object like [==~] and make 
it load without being part of a library. I found on deken a zexy version that 
seemed to do that (specifically: 
zexy-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar).
 And it didn't need a [hexloader] object too, by the way.
 
I didn't get an answer, but me and my colleague were checking the source code 
from zexy and found some cues. We tried it... and it works!
 
Now I have an object that is compiled as [==~], it's not part of a library, and 
it loads and works on pd vanilla 0.46-7 64 bits, pd vanilla 0.46-7 32 bits and 
also Pd-Extended 0.42-5 (without the need of the [hexloader] object by the 
way). All you need is the ==~.pd_darwin object in a search path.
 
 
Speaking and thinking as a user, I think it is easy and great to have a working 
and compiled object that just loads and works, so that is what I 'm after.
 
But anyway, yeah, I wanna know what are the dangers and all...
 
cheers

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

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

Re: [PD] Name conflicts "class overwritten; old one renamed 'x_aliased'

[cyrille henry]

hello,

overwriting a vanilla object is relatively new feature. Newer than last 
pd-extended, that's why it did not make it to extended.
pd-l2ork is more recent, so i guess it use all latest vanilla feature.
I think the aim is to be able to create object that are more optimized than 
native one. Or that add functionalities.
Of course, one can use this feature to completely break pd.

"rm -rf /" is a command that will completely break your computer, but it will 
not be remove from your OS, because no one sane would try it.
it's the same for pd : no one sane would write a [+] object that did not add 
number.
but it's possible to develop a [+] object that add number and string.

there is no problem overwriting a vanilla object as long as you keep 
compatibilities.
if you don't keep vanilla compatibilities, chances are that no one will use 
your externals, since it will cause more problem than anything else.
So, i don't see any problem overwriting vanilla objects, as long as object 
developers don't do anything stupid.


anyhow, it make sens to be able to load zexy/<~ or nettles/<~ even if zexy and 
nettles are loaded as a lib. but [<~] is not vanilla, so this is an other discussion 
than vanilla object being overwritten.


and for this specific object, what make more sense to me is to use a small 
abstraction made around tabread~ and a 2 points table.
100% vanilla.
0% trouble.


cheers
cyrille



Le 06/04/2016 00:51, Alexandre Torres Porres a écrit :

howdy, as a remaining extended 0.42-5 user, I'm just now realizing how vanilla 
works when loading externals with the same name as a vanilla object or some 
other preloaded library - I have to say it was a surprise to see that it's 
different that how extended works, and that it doesn't seem like a good idea...

Anyway, you see, I got here zexy 2.2.6 (as a library) and cyclone (individual 
binaries but also has the nettles library) on vanilla 0.46-7 - both external 
libraries have abs~ (which is also a vanilla object) or an object like [>~] 
(part of nettles in cyclone). Both zexy and nettles are loaded via startup.

So funny stuff can happen... like, vanilla's abs~ is overwritten by zexy's and 
renamed to abs~_aliased, but if I call cyclone's abs~ specifying its folder as 
[cyclone/abs~], it overwrites zexy's abs~ and it is never possible to call 
zexy's abs~ ever again...

Ok, in the case of abs~ I think it should be removed from both cyclone and 
zexy, because it's not only that they share the same name between each other 
and a vanilla object, but they all do the same thing as the internal object... 
so it's completely redundanct - but this is another issue. One way or another, 
it helps illustrating my point.

So, moving on to the case of [>~], we see from previous discussions that they need to be 
loaded as libraries for sanity's sake. But then I can never specify which [>~] I want - 
if both are via startup or declare, I can never be sure or control which one I'm specifying 
as either >~ or >~_aliased...

The point is: perhaps there could be a better way to force vanilla to load an 
internal object?

Or if not a vanilla object, perhaps that could be a way to specify and object 
inside one external library or another?

The way things are, it's all just really out of control and I can think of many 
scenarios where patches need to be edited when loaded because of what's going 
on in that particular machine, such as what patch had been opened before, 
etc... I know this probably has been discussed for ages and many people had 
already thought about it... I also know I have NO clue on the technical details 
and what has already been done, but I would like to ask and suggest things.

What would make sense to me is that vanilla objects would always prevail and be 
called with priority. This is how things were in Extended (and now pd-l2ork I 
guess) - externals with the same name as a vanilla objects could only be called 
only if explicitly specified.

In the case of cyclone's [line~] it's easy to specify if you wan cyclone's 
version or not by specifying the folder [cyclone/line~]

But the problem is when you're using a library, because you seemingly can't specify a 
given loaded external library when instantiating an object... such as [zexy/<~] or 
[nettles/<~] - and yes, they are different, by the way, before anyones asks ;)

So, in short, all could be sorted and taken care if:

1- vanilla objects are never overwritten
2- external objects can be specified by a path even if they are loaded as a library 
with declare or via the startup (ex: zexy/<~ or nettles/<~)

cheers



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



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

[PD] Name conflicts "class overwritten; old one renamed 'x_aliased'

[Alexandre Torres Porres]

howdy, as a remaining extended 0.42-5 user, I'm just now realizing how
vanilla works when loading externals with the same name as a vanilla object
or some other preloaded library - I have to say it was a surprise to see
that it's different that how extended works, and that it doesn't seem like
a good idea...

Anyway, you see, I got here zexy 2.2.6 (as a library) and cyclone
(individual binaries but also has the nettles library) on vanilla 0.46-7 -
both external libraries have abs~ (which is also a vanilla object) or an
object like [>~] (part of nettles in cyclone). Both zexy and nettles are
loaded via startup.

So funny stuff can happen... like, vanilla's abs~ is overwritten by zexy's
and renamed to abs~_aliased, but if I call cyclone's abs~ specifying its
folder as [cyclone/abs~], it overwrites zexy's abs~ and it is never
possible to call zexy's abs~ ever again...

Ok, in the case of abs~ I think it should be removed from both cyclone and
zexy, because it's not only that they share the same name between each
other and a vanilla object, but they all do the same thing as the internal
object... so it's completely redundanct - but this is another issue. One
way or another, it helps illustrating my point.

So, moving on to the case of [>~], we see from previous discussions that
they need to be loaded as libraries for sanity's sake. But then I can never
specify which [>~] I want - if both are via startup or declare, I can never
be sure or control which one I'm specifying as either >~ or >~_aliased...

The point is: perhaps there could be a better way to force vanilla to load
an internal object?

Or if not a vanilla object, perhaps that could be a way to specify and
object inside one external library or another?

The way things are, it's all just really out of control and I can think of
many scenarios where patches need to be edited when loaded because of
what's going on in that particular machine, such as what patch had been
opened before, etc... I know this probably has been discussed for ages and
many people had already thought about it... I also know I have NO clue on
the technical details and what has already been done, but I would like to
ask and suggest things.

What would make sense to me is that vanilla objects would always prevail
and be called with priority. This is how things were in Extended (and now
pd-l2ork I guess) - externals with the same name as a vanilla objects could
only be called only if explicitly specified.

In the case of cyclone's [line~] it's easy to specify if you wan cyclone's
version or not by specifying the folder [cyclone/line~]

But the problem is when you're using a library, because you seemingly can't
specify a given loaded external library when instantiating an object...
such as [zexy/<~] or [nettles/<~] - and yes, they are different, by the
way, before anyones asks ;)

So, in short, all could be sorted and taken care if:

1- vanilla objects are never overwritten
2- external objects can be specified by a path even if they are loaded as a
library with declare or via the startup (ex: zexy/<~ or nettles/<~)

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

Re: [PD] objects with no alphanumerical names, how to build them?

[Alexandre Torres Porres]

2016-04-05 16:03 GMT-03:00 cyrille henry :

> experience told me that if you are looking for trouble, you will find them
> at some point.
>

I hear you, it's just that I found that zexy library with such files
compiled and all, so I naively thought that there was an easy way out of
all these troubles.

I remember I had asked about that before, not on this thread only, but it
was never cleared to me, so I had to figure out by myself now how zexy
works in windows: it does use those weird names that require hexloader, so
it can't run on vanilla on windows. That's nice to learn.

Anyway, seems that loading these objects as a library is the only clean and
safe solution for trouble.

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

Re: [PD] objects with no alphanumerical names, how to build them?

[Jonathan Wilkes via Pd-list]

I'd like to make a Request for Peer Pressure:
Externals should only use alphanumeric characters and the underscore character.
Exceptions are: classes that should have long ago shipped with Vanilla, classes 
to gain compatibility with Max/MSP, 
domain-specific operators for a monolithic external library (i.e., one where 
you're probably going to load the entire 
library rather than individual classes from it), and legacy pd-extended bunk.
So learning about hexloader is good, maintaining zexy/cyclone is good, 
documenting problem characters on 
various OSes is good, shipping an external with a creator ":)" is bad.
-Jonathan


 

On Tuesday, April 5, 2016 2:37 PM, Alexandre Torres Porres 
 wrote:
 

 2016-04-05 12:26 GMT-03:00 Roman Haefeli :

On Windows, for instance, you can't have ? < > | : * \ / " in filenames.

I just confirmed you can't have those characters in a .dll file
So, besides these characters in Windows, what are other forbiden ones in other 
operational systems we run pd on?
I have Mac Os and it seems only colon (:) is prohibited (as in windows), or dot 
(.) at the beginning of a file.
How about Linux?
cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


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

Re: [PD] objects with no alphanumerical names, how to build them?

[Roman Haefeli]

On Die, 2016-04-05 at 15:32 -0300, Alexandre Torres Porres wrote:
> 2016-04-05 12:26 GMT-03:00 Roman Haefeli :
> On Windows, for instance, you can't have ? < > | : * \ / " in
> filenames.
> 
> 
> I just confirmed you can't have those characters in a .dll file

Just to be clear, it's not about the dll file or the dll fileformat. The
restricting factor is the file system (and probably the operating
system). 

> So, besides these characters in Windows, what are other forbiden ones
> in other operational systems we run pd on?

As I said, it depends rather on the file system than on the operating
system. Ext4, for instance, allows almost anything except / and \0
('null'). And the file names '.' '..' are restricted, too. '..pd_linux'
would theoretically work, but it would be a hidden file. I guess most
distros wouldn't allow to distribute a file with such a name. 

> I have Mac Os and it seems only colon (:) is prohibited (as in
> windows), or dot (.) at the beginning of a file.

Also here, the hfs+ file system has that restriction, not necessarily OS
X (though OS X and hfs+ are likely congruent). 

> How about Linux?

I guess most modern file systems have very few restrictions. However,
fat32 has certainly not less restrictions than ntfs (if not more) and it
can be mounted on Linux. And it is still widely used, on USB sticks or
whatsoever. It's not totally unreasonable to assume that someone runs Pd
from a fat32 formatted USB stick, thus it probably makes sense not to
assume a modern file system. I haven't tried, but I wouldn't be
surprised if a Debian system even works from a fat32 formatted USB
stick, simply because they restrict themselves to sane file names.

Some more details might be found here:
https://kb.acronis.com/content/39790

Roman






signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] objects with no alphanumerical names, how to build them?

[cyrille henry]

the problem did not came only from OS, but also from the filesystem.

dot at the beginning of the file usually mean that the file is hidden (but 
exist).

on a ext4 partition, only / is not possible in your list.

i don't know about fat : since it's the only filesystem that allow to be read / 
write by the 3 major OS, it's important to test.

i also don't know about what happen on a DVDROM.

experience told me that if you are looking for trouble, you will find them at 
some point.

cheers
c



Le 05/04/2016 20:32, Alexandre Torres Porres a écrit :

2016-04-05 12:26 GMT-03:00 Roman Haefeli mailto:reduz...@gmail.com>>:

On Windows, for instance, you can't have *? < > | : * \ / "* in filenames.


I just confirmed you can't have those characters in a .dll file

So, besides these characters in Windows, what are other forbiden ones in other 
operational systems we run pd on?

I have Mac Os and it seems only colon (*:*)**is prohibited (as in windows), or 
dot (.) at the beginning of a file.

How about Linux?

cheers


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



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

Re: [PD] New version of maxlib available via deken

[Fred Jan Kraan]

Hi Jonathan,


Sounds great!  Where is your repo?

Good point! I'll add that somewhere in the README next release. For now, 
you can find it at: https://github.com/electrickery/pd-maxlib. But to be 
compliant with the deken standard, the sources are included.



-Jonathan


Fred Jan



On Tuesday, April 5, 2016 2:13 PM, Fred Jan Kraan  wrote:


Hi All,

I just completed the upload of an updated version of maxlib to
puredata.info, and it is available via deken. I contacted Olaf and he is
ok with this release, as long as the bug-reports will be send to me.

Apart from the restyled help-patches, I fixed some issues.

Release notes 1.5.6:
- Changed version to 1.5.6,
- Fixed help symbol for arbran, beta, bilex, cauchy, delta, expo, gauss,
linear, poisson, triang, weibull,
- Added checks for missing arrays: arbran, subst,
- Removed alias 'd' for dist,
- Removed error for second inlet of pitch. Have to find out its usage,
- Applied sourceforge patch 1199 for garray_getfloatwords issue,

ToDo:
- Fix instability of netclient, netserver (or remove all net* objects),
- Change array code to support delayed loading (arbran, subst, ..),

There is still a problem with the net* objects, and I am tempted to
remove them in a next release as there are stable alternatives.

Greetings,

Fred Jan

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




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

Re: [PD] objects with no alphanumerical names, how to build them?

[Roman Haefeli]

On Die, 2016-04-05 at 13:25 -0300, Alexandre Torres Porres wrote:
> 2016-04-05 12:26 GMT-03:00 Roman Haefeli :
> (Then there was the issue with object name aliases, so that
> you could load [s2l] only after having created [symbol2list],
> but this
> is another story).
> 
> 
> Roman, I've been asking about that too. I had an object like
> [equals~], and I wanted to have [==~] as an alias - but I can only do
> it after I first load [equals~].
> 
> 
> How does it work? An alias is only possible if you load the externals
> as a library? Not as a single object binary? Seems so, but i'm just
> confirming

Please someone correct me, but I think it's because the alias name is
only registered after the dll file has been loaded and the dll can only
be loaded by its filename. Pd doesn't know about a '==~' class until the
'equals~.dll' has been loaded that registers the '==~' class. 

Roman 



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] objects with no alphanumerical names, how to build them?

[Alexandre Torres Porres]

2016-04-05 12:26 GMT-03:00 Roman Haefeli :

> On Windows, for instance, you can't have *? < > | : * \ / "* in filenames.


I just confirmed you can't have those characters in a .dll file

So, besides these characters in Windows, what are other forbiden ones in
other operational systems we run pd on?

I have Mac Os and it seems only colon (*:*) is prohibited (as in windows),
or dot (.) at the beginning of a file.

How about Linux?

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

Re: [PD] New version of maxlib available via deken

[Jonathan Wilkes via Pd-list]

Sounds great!  Where is your repo?
-Jonathan
 

On Tuesday, April 5, 2016 2:13 PM, Fred Jan Kraan  wrote:
 

 Hi All,

I just completed the upload of an updated version of maxlib to 
puredata.info, and it is available via deken. I contacted Olaf and he is 
ok with this release, as long as the bug-reports will be send to me.

Apart from the restyled help-patches, I fixed some issues.

Release notes 1.5.6:
- Changed version to 1.5.6,
- Fixed help symbol for arbran, beta, bilex, cauchy, delta, expo, gauss, 
linear, poisson, triang, weibull,
- Added checks for missing arrays: arbran, subst,
- Removed alias 'd' for dist,
- Removed error for second inlet of pitch. Have to find out its usage,
- Applied sourceforge patch 1199 for garray_getfloatwords issue,

ToDo:
- Fix instability of netclient, netserver (or remove all net* objects),
- Change array code to support delayed loading (arbran, subst, ..),

There is still a problem with the net* objects, and I am tempted to 
remove them in a next release as there are stable alternatives.

Greetings,

Fred Jan

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


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

Re: [PD] objects with no alphanumerical names, how to build them?

[IOhannes m zmölnig]

On 04/05/2016 05:35 PM, Ivica Ico Bukvic wrote:
> Another thought could be having hexloader be folded into core pd...

well, a trimmed down hexloader *is* included in Pd-vanilla.

however, it only handles the case for ordinary non-alpha characters and
is lacking an escape mechanism for characters prohibited by the filesystem.

gfmadsr
IOhannes



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

[PD] New version of maxlib available via deken

[Fred Jan Kraan]

Hi All,

I just completed the upload of an updated version of maxlib to 
puredata.info, and it is available via deken. I contacted Olaf and he is 
ok with this release, as long as the bug-reports will be send to me.


Apart from the restyled help-patches, I fixed some issues.

Release notes 1.5.6:
- Changed version to 1.5.6,
- Fixed help symbol for arbran, beta, bilex, cauchy, delta, expo, gauss, 
linear, poisson, triang, weibull,

- Added checks for missing arrays: arbran, subst,
- Removed alias 'd' for dist,
- Removed error for second inlet of pitch. Have to find out its usage,
- Applied sourceforge patch 1199 for garray_getfloatwords issue,

ToDo:
- Fix instability of netclient, netserver (or remove all net* objects),
- Change array code to support delayed loading (arbran, subst, ..),

There is still a problem with the net* objects, and I am tempted to 
remove them in a next release as there are stable alternatives.


Greetings,

Fred Jan

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

Re: [PD] objects with no alphanumerical names, how to build them?

[Alexandre Torres Porres]

2016-04-05 12:26 GMT-03:00 Roman Haefeli :

> (Then there was the issue with object name aliases, so that
> you could load [s2l] only after having created [symbol2list], but this
> is another story).
>

Roman, I've been asking about that too. I had an object like [equals~], and
I wanted to have [==~] as an alias - but I can only do it after I first
load [equals~].

How does it work? An alias is only possible if you load the externals as a
library? Not as a single object binary? Seems so, but i'm just confirming

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

Re: [PD] objects with no alphanumerical names, how to build them?

[Alexandre Torres Porres]

2016-04-05 12:11 GMT-03:00 Martin Peach :

> You're lucky that OSX accepts filenames like ==~.pd_darwin. Will it also
> accept *~.pd_darwin? Or <~.pd_darwin?
>

Yeah Martin, I can name the .pd_darwin objects to almost whatever, I've
been testing here and the only problem so far is a file containing ":" or
starting with a "." - but even something like ¿~.pd_darwin is fine :)

What OS are you on? And what is the deal there?

And, like I've been saying, I downloaded
*zexy-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar*

it has compiled objects as <~.pd_darwin but also 0x3c0x7e.pd_darwin

not sure how that is for another OS, can you tell me what happens in yours?

Anyway, I got my cues from the code in zexy to compile a ==~ object and I'm
pretty sure it will work for other things like <~ and whatever here on Mac
Os, but I haven't tried another yet (will do soon).

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

Re: [PD] objects with no alphanumerical names, how to build them?

[Jonathan Wilkes via Pd-list]

Let's wait to see if we ever get a bug report about that.  AFAICT Pd-l2ork 
loads what needs to be loaded-- "susceptible to" isn't a good reason to awaken 
the makefile monster.

-Jonathan 

On Tuesday, April 5, 2016 11:38 AM, Ivica Ico Bukvic  wrote:
 

  Another thought could be having hexloader be folded into core pd... It is 
currently autoloaded in pd-l2ork but that approach is still susceptible to 
overrides to the default config. Perhaps we should fold it into pd-l2ork? An 
alternative is having aliases...
 
 On 4/5/2016 10:43 AM, Alexandre Torres Porres wrote:
  
 
 
 2016-04-05 5:08 GMT-03:00 Roman Haefeli :
 
 If you're simply interested in knowing how things work technically, fine.
 
  I'd love to know, for sure, that's why I'm asking :)    
Now that we have a chance to get rid of all hexloader related kludges,
 now you come and bring it up again.
 
  You see, I don't really get what you mean by "hexloader" or its related 
kludges. All I know is some [hexloader] object that is in my pd extended 
0.42-5, and all I know is that I need to use it in order to load the [==~] 
object from zexy. What you're talking about, somehow, relates to that?  
  Anyway, seems so to me... and if so, the thing is that what I'm asking and 
doing has nothing to do with "hexloader"... (I never even mentioned about 
"hexloader", btw) ... and I read about the "hex loader" discussion as 
suggested, and found stuff that I didn't really think was related to my 
questions. Yeah, like I said, I don't really know much and I'd like to know, so 
I might be missing something, and someone can help me  with it...  
  But the thing is, all I asked was how to compile an object like [==~] and 
make it load without being part of a library. I found on deken a zexy version 
that seemed to do that (specifically: 
zexy-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar).
 And it didn't need a [hexloader] object too, by the way. 
  I didn't get an answer, but me and my colleague were checking the source code 
from zexy and found some cues. We tried it... and it works! 
  Now I have an object that is compiled as [==~], it's not part of a library, 
and it loads and works on pd vanilla 0.46-7 64 bits, pd vanilla 0.46-7 32 bits 
and also Pd-Extended 0.42-5 (without the need of the [hexloader] object by the 
way). All you need is the ==~.pd_darwin object in a search path. 
  
  Speaking and thinking as a user, I think it is easy and great to have a 
working and compiled object that just loads and works, so that is what I 'm 
after. 
  But anyway, yeah, I wanna know what are the dangers and all... 
  cheers 
  
 
  
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
 
 
 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


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

Re: [PD] objects with no alphanumerical names, how to build them?

[Alexandre Torres Porres]

2016-04-05 12:35 GMT-03:00 Ivica Ico Bukvic :

> Another thought could be having hexloader be folded into core pd...
>

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

Re: [PD] objects with no alphanumerical names, how to build them?

[cyrille henry]

Le 05/04/2016 17:26, Roman Haefeli a écrit :
...

I maybe was over-dramatizing the situation,


i don't think you are over dramatizing.
I've developed a fear of using externals in pd since the hexloader/zexy story.

10 years of vanilla only patching IS over-dramatizing. ;-)

cheers
c

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

Re: [PD] objects with no alphanumerical names, how to build them?

[Alexandre Torres Porres]

2016-04-05 12:26 GMT-03:00 Roman Haefeli :

> it's not possible to have >~.dll


I don't have windows, so please explain me better. Does window forbid a
file to be named >~.dll or is there a problem with an existing  >~.dll file
being uploaded into Pd?

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

Re: [PD] objects with no alphanumerical names, how to build them?

[Ivica Ico Bukvic]

Another thought could be having hexloader be folded into core pd... It 
is currently autoloaded in pd-l2ork but that approach is still 
susceptible to overrides to the default config. Perhaps we should fold 
it into pd-l2ork? An alternative is having aliases...


On 4/5/2016 10:43 AM, Alexandre Torres Porres wrote:



2016-04-05 5:08 GMT-03:00 Roman Haefeli >:


 If you're simply interested in knowing how things work
technically, fine.


I'd love to know, for sure, that's why I'm asking :)

Now that we have a chance to get rid of all hexloader related kludges,
now you come and bring it up again.


You see, I don't really get what you mean by "hexloader" or its 
related kludges. All I know is some [hexloader] object that is in my 
pd extended 0.42-5, and all I know is that I need to use it in order 
to load the [==~] object from zexy. What you're talking about, 
somehow, relates to that?


Anyway, seems so to me... and if so, the thing is that what I'm asking 
and doing has nothing to do with "hexloader"... (I never even 
mentioned about "hexloader", btw) ... and I read about the "hex 
loader" discussion as suggested, and found stuff that I didn't really 
think was related to my questions. Yeah, like I said, I don't really 
know much and I'd like to know, so I might be missing something, and 
someone can help me with it...


But the thing is, all I asked was how to compile an object like [==~] 
and make it load without being part of a library. I found on deken a 
zexy version that seemed to do that (specifically: 
/zexy-v0-0extended-(Darwin-/i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals./tar/). 
And it didn't need a [hexloader] object too, by the way.


I didn't get an answer, but me and my colleague were checking the 
source code from zexy and found some cues. We tried it... and it works!


Now I have an object that is compiled as [==~], it's not part of a 
library, and it loads and works on pd vanilla 0.46-7 64 bits, pd 
vanilla 0.46-7 32 bits and also Pd-Extended 0.42-5 (*_without_* the 
need of the [hexloader] object by the way). All you need is the 
==~.pd_darwin object in a search path.



Speaking and thinking as a user, I think it is easy and great to have 
a working and compiled object that just loads and works, so that is 
what I 'm after.


But anyway, yeah, I wanna know what are the dangers and all...

cheers




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


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

Re: [PD] objects with no alphanumerical names, how to build them?

[Roman Haefeli]

Ok. You were lucky to have chosen '==' as an object name, then.

The insanity begins, when the object names use characters that are
forbidden by some file systems. On Windows, for instance, you can't
have ? < > | : * \ " in filenames. This means, if you want to be able to
load such an object, you need some mechanism to substitute those
characters by something that is allowed.

This is where hexloader comes into play. It was necessary because
Pd-extended decided to split libraries into single-object-files, so that
each object has its own dll|pd_darwin|pd_linux file. However, it's not
possible to have >~.dll. The problem got worked-around by substituting
the forbidden characters by their hexadecimal representation.  I don't
know the exact details, but hexloader enabled Pd to search not only for
the name you entered into the object box, but also for its hex counter
part. This means you could create an object [>~] and Pd would load
0x3e0x7e.dll, if it was available.

All this caused some degree of confusion, since hexloader wasn't loaded
per default in Pd-extended. This means, after [import zexy] you were
able to create [symbol2list], but not [>~]. You had to [import
hexloader], too, to be able to use [>~]. This created troubles for quite
many users. (Then there was the issue with object name aliases, so that
you could load [s2l] only after having created [symbol2list], but this
is another story).

All this was never an issue with the canonical zexy library, because
everything is packed in zexy.dll|pd_darwin|pd_linux. Once you load zexy,
all its classes simply worked. 

I maybe was over-dramatizing the situation, since your example with [==]
seems to work fine. However, since Pd-extended has reached its end of
life, we should take the chance to learn from its mistakes and I
consider the forceful splitting of libraries a mistake and the proposed
solution with hexloader a kludge. It might would make things a bit more
straight forward, if hexloader was part of Pd, but that's not likely to
happen (I remember Miller having expressed hesitation). And the whole
hexloader thing is currently not necessary as long as external authors
put their classes with 'weird' names into multi-object libraries with
'sane' names or use only 'sane' names for their single-object
externals.  

I hope I could make things a bit more clear and my explanations stick to
the facts.

Roman


On Tue, 2016-04-05 at 11:43 -0300, Alexandre Torres Porres wrote:
> 
> 
> 2016-04-05 5:08 GMT-03:00 Roman Haefeli :
>  If you're simply interested in knowing how things work
> technically, fine.
> 
> 
> I'd love to know, for sure, that's why I'm asking :)
>  
> Now that we have a chance to get rid of all hexloader related
> kludges,
> now you come and bring it up again.
> 
> 
> You see, I don't really get what you mean by "hexloader" or its
> related kludges. All I know is some [hexloader] object that is in my
> pd extended 0.42-5, and all I know is that I need to use it in order
> to load the [==~] object from zexy. What you're talking about,
> somehow, relates to that? 
> 
> 
> Anyway, seems so to me... and if so, the thing is that what I'm asking
> and doing has nothing to do with "hexloader"... (I never even
> mentioned about "hexloader", btw) ... and I read about the "hex
> loader" discussion as suggested, and found stuff that I didn't really
> think was related to my questions. Yeah, like I said, I don't really
> know much and I'd like to know, so I might be missing something, and
> someone can help me with it...
> 
> 
> But the thing is, all I asked was how to compile an object like [==~]
> and make it load without being part of a library. I found on deken a
> zexy version that seemed to do that
> (specifically: 
> zexy-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar).
>  And it didn't need a [hexloader] object too, by the way.
> 
> 
> I didn't get an answer, but me and my colleague were checking the
> source code from zexy and found some cues. We tried it... and it
> works!
> 
> 
> Now I have an object that is compiled as [==~], it's not part of a
> library, and it loads and works on pd vanilla 0.46-7 64 bits, pd
> vanilla 0.46-7 32 bits and also Pd-Extended 0.42-5 (without the need
> of the [hexloader] object by the way). All you need is the
> ==~.pd_darwin object in a search path.
> 
> 
> 
> 
> Speaking and thinking as a user, I think it is easy and great to have
> a working and compiled object that just loads and works, so that is
> what I 'm after.
> 
> 
> But anyway, yeah, I wanna know what are the dangers and all...
> 
> 
> cheers
> 
> 
> 
> 



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] objects with no alphanumerical names, how to build them?

[Jonathan Wilkes via Pd-list]

Here's some Pd Fan Fiction:

Relational sigop author: Hey I got relational sigops.  You want them?
Pd author: Yeah thanks, I forgot about those. *copy/paste*Pd community: Yay!

Fin.
-Jonathan


On Tuesday, April 5, 2016 10:46 AM, Alexandre Torres Porres 
 wrote:
 

 

2016-04-05 5:08 GMT-03:00 Roman Haefeli :

 If you're simply interested in knowing how things work technically, fine.

I'd love to know, for sure, that's why I'm asking :) 
Now that we have a chance to get rid of all hexloader related kludges,
now you come and bring it up again.

You see, I don't really get what you mean by "hexloader" or its related 
kludges. All I know is some [hexloader] object that is in my pd extended 
0.42-5, and all I know is that I need to use it in order to load the [==~] 
object from zexy. What you're talking about, somehow, relates to that? 
Anyway, seems so to me... and if so, the thing is that what I'm asking and 
doing has nothing to do with "hexloader"... (I never even mentioned about 
"hexloader", btw) ... and I read about the "hex loader" discussion as 
suggested, and found stuff that I didn't really think was related to my 
questions. Yeah, like I said, I don't really know much and I'd like to know, so 
I might be missing something, and someone can help me with it...
But the thing is, all I asked was how to compile an object like [==~] and make 
it load without being part of a library. I found on deken a zexy version that 
seemed to do that (specifically: 
zexy-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar).
 And it didn't need a [hexloader] object too, by the way.
I didn't get an answer, but me and my colleague were checking the source code 
from zexy and found some cues. We tried it... and it works!
Now I have an object that is compiled as [==~], it's not part of a library, and 
it loads and works on pd vanilla 0.46-7 64 bits, pd vanilla 0.46-7 32 bits and 
also Pd-Extended 0.42-5 (without the need of the [hexloader] object by the 
way). All you need is the ==~.pd_darwin object in a search path.

Speaking and thinking as a user, I think it is easy and great to have a working 
and compiled object that just loads and works, so that is what I 'm after.
But anyway, yeah, I wanna know what are the dangers and all...
cheers


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


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

Re: [PD] objects with no alphanumerical names, how to build them?

[Martin Peach]

On Tue, Apr 5, 2016 at 10:43 AM, Alexandre Torres Porres 
wrote:

>
> Now I have an object that is compiled as [==~], it's not part of a
> library, and it loads and works on pd vanilla 0.46-7 64 bits, pd vanilla 
> 0.46-7
> 32 bits and also Pd-Extended 0.42-5 (*without* the need of the
> [hexloader] object by the way). All you need is the ==~.pd_darwin object
> in a search path.
>
>
> Speaking and thinking as a user, I think it is easy and great to have a
> working and compiled object that just loads and works, so that is what I 'm
> after.
>
> But anyway, yeah, I wanna know what are the dangers and all...
>
>
You're lucky that OSX accepts filenames like ==~.pd_darwin. Will it also
accept *~.pd_darwin? Or <~.pd_darwin?
Usually objects with weird names (names that are illegal as file names)
need to be set up in a library first, so that their names can be registered
without Pd having to search the filesystem for them.

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

Re: [PD] Fullscreen, not GEM, just a PD screen?

[Jonathan Wilkes via Pd-list]

It will come standard in the GUI port of Pd-l2ork.
I'll have an alpha release in a day or so...
-Jonathan
 

On Tuesday, April 5, 2016 10:01 AM, IOhannes m zmoelnig  
wrote:
 

 On 2016-04-05 03:47, Peter Nyboer wrote:
> A simple, somewhat newbie question: Is it possible to display a regular PD 
> window in fullscreen, or position it to fake fullscreen, on Linux? It seems 
> like it should be trivial to hide the application menu bar, but I have yet to 
> find anything - “fullscreen pure data” is polluted by GEM!!
> 

kiosk-plugin?

fgmasdr
IOhannes


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


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

Re: [PD] objects with no alphanumerical names, how to build them?

[Alexandre Torres Porres]

2016-04-05 5:08 GMT-03:00 Roman Haefeli :

>  If you're simply interested in knowing how things work technically, fine.


I'd love to know, for sure, that's why I'm asking :)


> Now that we have a chance to get rid of all hexloader related kludges,
> now you come and bring it up again.


You see, I don't really get what you mean by "hexloader" or its related
kludges. All I know is some [hexloader] object that is in my pd extended
0.42-5, and all I know is that I need to use it in order to load the [==~]
object from zexy. What you're talking about, somehow, relates to that?

Anyway, seems so to me... and if so, the thing is that what I'm asking and
doing has nothing to do with "hexloader"... (I never even mentioned about
"hexloader", btw) ... and I read about the "hex loader" discussion as
suggested, and found stuff that I didn't really think was related to my
questions. Yeah, like I said, I don't really know much and I'd like to
know, so I might be missing something, and someone can help me with it...

But the thing is, all I asked was how to compile an object like [==~] and
make it load without being part of a library. I found on deken a zexy
version that seemed to do that (specifically: *zexy-v0-0extended-(Darwin-*
i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.*tar*). And it
didn't need a [hexloader] object too, by the way.

I didn't get an answer, but me and my colleague were checking the source
code from zexy and found some cues. We tried it... and it works!

Now I have an object that is compiled as [==~], it's not part of a library,
and it loads and works on pd vanilla 0.46-7 64 bits, pd vanilla 0.46-7 32
bits and also Pd-Extended 0.42-5 (*without* the need of the [hexloader]
object by the way). All you need is the ==~.pd_darwin object in a search
path.


Speaking and thinking as a user, I think it is easy and great to have a
working and compiled object that just loads and works, so that is what I 'm
after.

But anyway, yeah, I wanna know what are the dangers and all...

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

[PD] Pd & Raspberry Pi Workshops in Montreal (April 9, 16, 23 at Eastern Bloc).

[Peter van Haaften]

Hello,

Starting this coming Saturday, I am offering three introductory workshops
to sound design and music composition with Pure Data. For the third
workshop, participants will learn how to run the instruments and sequencers
they built in the previous workshops on a Raspberry Pi 2, and develop
strategies for external control.

This series is intended for Pd newcomers with no programming background
necessary.

Dates: April 9, 16, and 23 from 11am-6pm.
Location: Eastern Bloc (7240 Clark).
Cost: $150 for the three part series (includes a Raspberry Pi 2).
Details:
http://easternbloc.ca/workshops-2015-2016.php?lien=workshops-2015-2016-puredata

Thanks!

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

Re: [PD] Fullscreen, not GEM, just a PD screen?

[IOhannes m zmoelnig]

On 2016-04-05 03:47, Peter Nyboer wrote:
> A simple, somewhat newbie question: Is it possible to display a regular PD 
> window in fullscreen, or position it to fake fullscreen, on Linux? It seems 
> like it should be trivial to hide the application menu bar, but I have yet to 
> find anything - “fullscreen pure data” is polluted by GEM!!
> 

kiosk-plugin?

fgmasdr
IOhannes




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

[PD] Fullscreen, not GEM, just a PD screen?

[Peter Nyboer]

A simple, somewhat newbie question: Is it possible to display a regular PD 
window in fullscreen, or position it to fake fullscreen, on Linux? It seems 
like it should be trivial to hide the application menu bar, but I have yet to 
find anything - “fullscreen pure data” is polluted by GEM!!

Peter


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

Re: [PD] [PD-announce] Camomile: An audio plugin that loads Pure Data patches

[Pierre Guillot]

>
> Hey Pierre,
>
>
>
> funnily it only gets recognized as instrument when before added as an
> effect, I realized now.
>
> I dont know what differences renoise does with vst / vsti...
>
> Some plugins in renoise also show all possible controll values in the gui
> of renoise and then you can assign midi controller channels with it.
>
> Camomile doesnt show its parameters in renoise gui. But if it has access
> to the midi it might be possible to root it via pd.
>
>
>
> How can i access the host midi? I tried ctlin but got no signals there. Is
> there a send for those like $0-octave or $0-playhead?
>
>
>
> Cheers...
>

Normally, all this stuff should work. How to use the playhead informations
and the MIDI events is explained here:
https://github.com/pierreguillot/Camomile/wiki/How%20to%20create%20patches%20for%20the%20plugin
https://github.com/pierreguillot/Camomile/wiki/Frequently%20Asked%20Questions
Renoise must have a very specific way to handle MIDI. I can compile a VST
and VSTi for the next release (that's not a big deal), perhaps it will be
better. I also planned to compile a LV2 plugin, perhaps this will solve
this problem. I keep you in touch if you want.
Cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] objects with no alphanumerical names, how to build them?

[Roman Haefeli]

On Mon, 2016-04-04 at 18:42 -0300, Alexandre Torres Porres wrote:
> howdy, I know I kinda asked about this before on the list, but now I'm
> really committed to understanding and building objects with "weird
> character" names, like [==~].

Speaking as user, please don't. Don't find out about it, don't create
such externals, don't distribute them. The world was fine before
Pd-extended split up perfectly working libraries into
single-object-per-file libraries that required stuff like hexloader
exactly because of the very issue you seem to show interest in. Although
it technically worked, hexloader was not loaded per default and this
meant that some objects of a library simply worked, while others didn't
until hexloader got loaded and it confused the hell out of people. 

Now that we have a chance to get rid of all hexloader related kludges,
now you come and bring it up again. If you're simply interested in
knowing how things work technically, fine. If you plan to work on such
externals, puulleeaaazeee reconsider for the sake of the sanity of
this community.

Thanks,
Roman




signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list