well, I've checked the messages in the "hex loader" thread from nov 2007, it seems to talk a lot about the code of what is now the [hexloader] object in pd extended, but i didn't see how it related to my questions, which is how does the latest zexy library, available now via deken and seemingly from 2013, does create objects with not alphanumerical names, and without the need of the [hexloader] object.

If I miss something, I'm sorry, but I still need more clues and guidelines.

thanks

2016-04-04 19:11 GMT-03:00 Alexandre Torres Porres porres@gmail.com:

will do, but can you confirm if:

the version found via deken, as: *zexy-v0-0extended-(Darwin-* *i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar*

Is this the one available from last released extended (0.43).

and if this is the source code then https://sourceforge.net/p/pure-data/svn/HEAD/tree/branches/pd-extended/0.43/...

thanks

I also asked something in my first email and I hope I can confirm it

I tried making a second name - or an "alias" - for [equals~] (using C.2.9 class_addcreator C.2.9 in http://pdstatic.iem.at/externals-HOWTO/pd-externals-HOWTOse8.html )

But it didn't seem to work. I can get [==~] to instantiate as an alias, but only after I first instantiate it as "[equals~]".

So, what's the deal, when does this aliasing work? Only if you load it as a library?

2016-04-05 1:19 GMT-03:00 Alexandre Torres Porres porres@gmail.com:

Well, I also found this zexy git https://git.iem.at/pd/zexy/

not sure how it compiles to objects like ==~ - coz i couldn't compile. But my colleague, Flavio, checked it out, and seems to have realized about the trick to compile an object as "==~". We did it and I compiled it for Mac Os and it is working.

By the code from the git above as a model, we changed the original code from:

*void equals_tilde_setup(void){ equals_class = class_new(gensym("equals~"),(t_newmethod)equals_new, 0,sizeof(t_equals), 0, A_GIMME, 0);sic_setup(equals_class, equals_dsp, SIC_FLOATTOSIGNAL);}*

To:

*void setup_0x3d0x3d0x7e(void){equals_class = class_new(gensym("==~"),(t_newmethod)equals_new, 0,sizeof(t_equals), 0, A_GIMME, 0);sic_setup(equals_class, equals_dsp, SIC_FLOATTOSIGNAL);}*

*void setup(void){setup_0x3d0x3d0x7e();}*

Then the compiled object can be named as ==~ and it loads fine here. Should I expect that it loads just fine in any other OS as well?

cheers

2016-04-05 5:08 GMT-03:00 Roman Haefeli reduzent@gmail.com:

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

2016-04-05 12:11 GMT-03:00 Martin Peach chakekatzil@gmail.com:

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

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" pd-list@lists.iem.at An: "Alexandre Torres Porres" porres@gmail.com, "Roman Haefeli" reduzent@gmail.com Cc: "pd-list@lists.iem.at" 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 porres@gmail.com wrote:

2016-04-05 5:08 GMT-03:00 Roman Haefeli reduzent@gmail.com: 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%5Bhttps://lists.puredata.info/l...]  _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]

Hi, I followed the "how is pd limited" discussion, but to me that was rather about general limitations. Although the topics are definitely related.

A smaller package is easier for someone like Miller to develop - it also makes it easy to allow things like libpd to exist.

True, and I totally acknowledge that. I was justing talking about a handful of objects and methods that I feel are missing and shouldn't need an external. Of course it can become a bottomless bit easily.

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

Yes, I think you totally hit the crucial point here!

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

Maybe what we could do is to provide a small list of the best and most important libs, telling what they do and when you need them, so a new user at least *knows* about them. It could be a short wiki like: You want to do this? This libraries will do the job: ...

What do you think about it?

Anyway, here's my little list of 'forgotten' objects/methods:

relational sigops like [<~], [>~], [==~] [!=~] maybe binary sigops, but since they are not used that often, [expr~] might be ok...

[atan2~] (I can emulate all of these with [expr~]/[expr] but apparantly it's not as cheap as dedicated objects)

signum object for floats and signals

a xor object [^]

a simple samplewise delay like zexy's [z~]

some more methods for [array] and [list] for iterating, sorting and inserting/removing.

a knob GUI

yeah, it's actually quite ironic that a graphical computer music software doesn't offer knobs :-)

I don't believe that such fundamental objects/methods would cause a significant maintainance overhead.

And sometimes I don't get why some method is included while others are missing: [text] has a fancy autoplay method, but [list] misses a sorting and iterating method (given the fact that up to Pd 46.6 you can't do iterations over lists in linear time without externals or clever abstractions like [list-drip]...)

Gesendet: Mittwoch, 06. April 2016 um 06:41 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] Missing objects/methods in Pd WAS: objects with no alphanumerical names, how to build them?

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 christof.ressi@gmx.at: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" <pd-list@lists.iem.at[pd-list@lists.iem.at]> An: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]>, "Roman Haefeli" <reduzent@gmail.com[reduzent@gmail.com]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[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 <porres@gmail.com[porres@gmail.com]> wrote:

2016-04-05 5:08 GMT-03:00 Roman Haefeli <reduzent@gmail.com[reduzent@gmail.com]>: 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][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]  _______________________________________________ Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]

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

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

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

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

(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

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

 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

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 <ico@vt.edu> 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 reduzent@gmail.com:

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

2016-04-05 12:26 GMT-03:00 Roman Haefeli reduzent@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

2016-04-05 16:03 GMT-03:00 cyrille henry ch@chnry.net:

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

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 <porres@gmail.com> wrote:

2016-04-05 12:26 GMT-03:00 Roman Haefeli reduzent@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