why do tilde objects work in vanilla pd, but the zexy tilde objects are so uncooperative?
hard off wrote:
why do tilde objects work in vanilla pd, but the zexy tilde objects are so uncooperative?
which object gives you trouble? [noisi~], [limiter~], [dirac~]?
anyhow, zexy's objects are not uncooperative at all.
zexy is and was meant to be compiled as a multi-object library, just like Pd (kind of).
then Pd-extended came along and tore the happy family apart into single-object externals and the trouble began. i guess you are using Pd-extended?
and no, this is no rant about Pd-extended, the problem is a deeper one (and was almost solved in Pd-vanilla - but alas! in the end it was not), it just happens to be exposed very much by PdX's policy.
so, please be cooperative, compile zexy yourself (as a multi-object library - which is the default), load it and be happy.
fgamsdr IOhannes
On Wed, 2008-07-16 at 12:01 +0200, IOhannes m zmoelnig wrote:
hard off wrote:
why do tilde objects work in vanilla pd, but the zexy tilde objects are so uncooperative?
which object gives you trouble? [noisi~], [limiter~], [dirac~]?
anyhow, zexy's objects are not uncooperative at all.
zexy is and was meant to be compiled as a multi-object library, just like Pd (kind of).
then Pd-extended came along and tore the happy family apart into single-object externals and the trouble began. i guess you are using Pd-extended?
and no, this is no rant about Pd-extended, the problem is a deeper one (and was almost solved in Pd-vanilla - but alas! in the end it was not),
what was the reason for that?
it just happens to be exposed very much by PdX's policy.
so, please be cooperative, compile zexy yourself (as a multi-object library - which is the default), load it and be happy.
last time i tested pd-extended, it was definitely not all tilde classes from zexy, that made troubles, but only [<~] and [>~]. probably there are some others, that have 'special' chars in their names. however, the rest was working well.
even while using pd-vanilla, i used to compile zexy as single-object externals in order to make my patches as troublefree as possible on pd-extended. i also used to use the hexloader and, iirc, i could instantiate [<~] and [>~] without problems (unlike pd-extended, that is why i switched back to a multiclass binary). anyway, my point is: it was once working here on my box without issues at all, even if i had zexy as single-objects externals. what does it need to make it work on pd-extended as well?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
oh sorry i should have been clearer. yes i was referring to >~ and <~ specifically. pd vanilla can load both the > and < characters, and tilde~ characters too. but pd extended can't load them together as part of the zexy library.
iohannes, i really appreciate all your hard work, and maybe my original mail looks a bit grouchy. it wasn't meant to be. i just think it's a real shame that pd-extended won't load these objects. they used to load fine in earlier versions of extended. personally i have just changed all my >~ objects to [expr~ $v1>n].
hard off wrote:
oh sorry i should have been clearer. yes i was referring to >~ and <~ specifically. pd vanilla can load both the > and < characters, and tilde~ characters too. but pd extended can't load them together as part of the zexy library.
iohannes, i really appreciate all your hard work, and maybe my original mail looks a bit grouchy.
no it's fine with me. it just seems like everybody seems to blame zexy for things it is innocent of.
it wasn't meant to be. i just think it's a real shame that pd-extended won't load these objects.
i totally agree.
they used to load fine in earlier versions of extended. personally i have just changed all my >~ objects to [expr~ $v1>n].
and then people came and started to complain why patches took 15 minutes to load when the hexloader is enabled...
anyhow, i think i have put enough of my ressources into trying to make this work in a general way but unfortunately without much success; so i guess i leave it there and advise people to use zexy as a multi-object library.
mfasdr IOhannes
Roman Haefeli wrote:
(and was almost solved in Pd-vanilla - but alas! in the end it was not),
what was the reason for that?
who knows? anyhow, i don't think it will be fixed upstream within the next years...
even while using pd-vanilla, i used to compile zexy as single-object externals in order to make my patches as troublefree as possible on pd-extended.
??? Pd-extended has no problems whatsoever in loading multi-object libraries. why should compiling zexy as single-object externals make it more troublefree (the only difference i know of is troubles with special-characters when using single-object externals)
i also used to use the hexloader and, iirc, i could instantiate [<~] and [>~] without problems (unlike pd-extended, that is why i switched back to a multiclass binary). anyway, my point is: it was once working here on my box without issues at all, even if i had zexy as single-objects externals. what does it need to make it work on pd-extended as well?
i don't know and my interest therein is decreasing.
fgmasdr IOhannes
On Wed, 16 Jul 2008, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
even while using pd-vanilla, i used to compile zexy as single-object externals in order to make my patches as troublefree as possible on pd-extended.
Pd-extended has no problems whatsoever in loading multi-object libraries. why should compiling zexy as single-object externals make it more troublefree
It's because multi-class externals has been defined as trouble and trouble has been defined as multi-class externals. There's no way out of this. Save your energy for something else.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Wed, 2008-07-16 at 13:09 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
(and was almost solved in Pd-vanilla - but alas! in the end it was not),
what was the reason for that?
who knows? anyhow, i don't think it will be fixed upstream within the next years...
even while using pd-vanilla, i used to compile zexy as single-object externals in order to make my patches as troublefree as possible on pd-extended.
??? Pd-extended has no problems whatsoever in loading multi-object libraries. why should compiling zexy as single-object externals make it more troublefree
sorry, obviously i wasn't clear enough. i wasn't saying, that pd-extended has problems with mutli-object libraries, but only that currently it uses single-object externals. in order to have the same problems as pd-extended users, i decided to install a single-object version of zexy on my box in order to _have_ (not avoid) the same problems, that pd-extended suffers from, just to help myself creating pd-extended compliant patches (so possible problems would already be triggered on my box). however, it seemed, that my installation still hadn't all of the issues, since [>~] and [<~] were still working for me.
(the only difference i know of is troubles with special-characters when using single-object externals)
there is also the issue, that aliases are not (completely) supported by pd-extended, afaik.
i also used to use the hexloader and, iirc, i could instantiate [<~] and [>~] without problems (unlike pd-extended, that is why i switched back to a multiclass binary). anyway, my point is: it was once working here on my box without issues at all, even if i had zexy as single-objects externals. what does it need to make it work on pd-extended as well?
i don't know and my interest therein is decreasing.
ok, i understand that.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
On Wed, 2008-07-16 at 13:09 +0200, IOhannes m zmoelnig wrote:
(the only difference i know of is troubles with special-characters when using single-object externals)
there is also the issue, that aliases are not (completely) supported by pd-extended, afaik.
Seems to me weird characters always cause trouble somewhere along the line. Why not rename them [lt~] and [gt~]? Then there's something in gridflow I think that actually uses * in its name, I mean why not make an external with the three-character name [ctl-alt-del]? Martin
On Wed, 2008-07-16 at 09:25 -0400, Martin Peach wrote:
Roman Haefeli wrote:
On Wed, 2008-07-16 at 13:09 +0200, IOhannes m zmoelnig wrote:
(the only difference i know of is troubles with special-characters when using single-object externals)
there is also the issue, that aliases are not (completely) supported by pd-extended, afaik.
Seems to me weird characters always cause trouble somewhere along the line. Why not rename them [lt~] and [gt~]? Then there's something in gridflow I think that actually uses * in its name, I mean why not make an external with the three-character name [ctl-alt-del]? Martin
why not calling them [greater_than_tilde] and [less_than_tilde] ?
anyway, the alias problem is not related to 'weird' (whoever decides, which are considered weird and which not) characters. when loading mulit-class externals, all the names get registered, so that pd already knows about the name, when instantiating an alias. in pd-extended, it works as well, but you have to first load the external by its original name, so that the alias gets registeredl. if you first try to instantiate by the alias name, then pd doesn't know what external to load. (sorry, if i use wrong terminology here and 'to register' means something different).
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
I think we have to face that pd's current features are not able to meet all needs: namespaces, special characters, fast loading, aliases... what is missing? does pd have something like a "registered objects list"? an index, which is created on pd startup that holds the name and aliases to all objects that can be created but without loading the objects themselves? maybe a hybrid somewhere between path information and the loading of a multi-external library. is this the way how it is done currently? this list should be dynamically editable and would hold the aliases for namespaces: counter = iem/counter loading the iem counter as default, but still enabling the creation of cyclone/counter. also all other aliases could be included. and it might as well speed up starting of patches since there is no need to search all directories for every object. it would extend the functionality of "path" by actually reading out a small amount of object information which allows for sorting, aliasing... marius.
Roman Haefeli wrote:
On Wed, 2008-07-16 at 09:25 -0400, Martin Peach wrote:
Roman Haefeli wrote:
On Wed, 2008-07-16 at 13:09 +0200, IOhannes m zmoelnig wrote:
(the only difference i know of is troubles with special-characters when using single-object externals)
there is also the issue, that aliases are not (completely) supported by pd-extended, afaik.
Seems to me weird characters always cause trouble somewhere along the line. Why not rename them [lt~] and [gt~]? Then there's something in gridflow I think that actually uses * in its name, I mean why not make an external with the three-character name [ctl-alt-del]? Martin
why not calling them [greater_than_tilde] and [less_than_tilde] ?
anyway, the alias problem is not related to 'weird' (whoever decides, which are considered weird and which not) characters. when loading mulit-class externals, all the names get registered, so that pd already knows about the name, when instantiating an alias. in pd-extended, it works as well, but you have to first load the external by its original name, so that the alias gets registeredl. if you first try to instantiate by the alias name, then pd doesn't know what external to load. (sorry, if i use wrong terminology here and 'to register' means something different).
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 16 Jul 2008, marius schebella wrote:
does pd have something like a "registered objects list"? an index, which is created on pd startup that holds the name and aliases to all objects that can be created but without loading the objects themselves?
reminds me that jMax had a two-step setup mechanism: all the libraries would be open, and the main setup function would be run, and class loaders would be run, but the classes were actually "loaded" later, on demand. In the end, it doesn't make so much of a difference, and it might be worse. It's better when all the class_new are in one spot because then the OS needs to read less blocks from the disk. When you load a big lib, anyway, the OS doesn't actually read the whole file immediately (which is one of the reasons why single-class externals don't save much RAM in practice).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Roman Haefeli wrote: (whoever decides, which are considered weird and which not) characters
To me, the set of characters that are not acceptable as part of filenames on at least one of the usual OSs, inclusive ored with the set of characters that are not acceptable to Tcl via Pd, comprise the set of weird characters.
Martin
On Wed, 16 Jul 2008, Martin Peach wrote:
Seems to me weird characters always cause trouble somewhere along the line. Why not rename them [lt~] and [gt~]? Then there's something in gridflow I think that actually uses * in its name,
I encoded that using the hexloader's convention for the benefit of the SVN, and then the Makefile copies that to the name that has '*' in it because it can't assume that the hexloader is actually there.
If all internal classes became single external classes, as some people have wished already, then you end up with bunch of classes named like [*] and [/] that have to be named something in the filesystem, and so should their helpfiles. Furthermore, by consistency, things closely related to the [*] class should be named with a "*" in the name instead of a "mul", and things closely related to [/] should be named with a "/" in the name instead of a "div", and so GridFlow's [inv*] was part of a jMax-compat layer and the original jMax class was called exactly [inv*] because the jMax authors judged it to be so closely related to [*]. There's another way of understanding the behaviour of that class, but in that case it is so closely related to [/] instead.
I mean why not make an external with the three-character name [ctl-alt-del]?
Ctrl and Alt are not characters and don't have any character code representation.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
If all internal classes became single external classes, as some people have wished already, then you end up with bunch of classes named like [*] and [/] that have to be named something in the filesystem, and so should their helpfiles. Furthermore, by consistency, things closely related to the [*] class should be named with a "*" in the name instead of a "mul", and things closely related to [/] should be named with a "/" in the name instead of a "div", and so GridFlow's [inv*] was part of a jMax-compat layer and the original jMax class was called exactly [inv*] because the jMax authors judged it to be so closely related to [*]. There's another way of understanding the behaviour of that class, but in that case it is so closely related to [/] instead.
Maybe by adding a list of aliases to the init file, arbitrarily named objects could be stored on a filesystem with safe names and instantiated using the weird name.
I mean why not make an external with the three-character name [ctl-alt-del]?
Ctrl and Alt are not characters and don't have any character code representation.
That makes them so much more interesting to implement ;) Or how about [ctl-g], which should make the computer beep whenever you type it in...
Martin
On Jul 16, 2008, at 12:37 PM, Martin Peach wrote:
Mathieu Bouchard wrote:
If all internal classes became single external classes, as some
people have wished already, then you end up with bunch of classes named like
[*] and [/] that have to be named something in the filesystem, and so
should their helpfiles. Furthermore, by consistency, things closely related to
the [*] class should be named with a "*" in the name instead of a "mul",
and things closely related to [/] should be named with a "/" in the name
instead of a "div", and so GridFlow's [inv*] was part of a jMax-compat layer
and the original jMax class was called exactly [inv*] because the jMax
authors judged it to be so closely related to [*]. There's another way of understanding the behaviour of that class, but in that case it is so closely related to [/] instead.Maybe by adding a list of aliases to the init file, arbitrarily named objects could be stored on a filesystem with safe names and
instantiated using the weird name.
and < are only problems on NTFS/Windows. So the files could be
called >~.pd and <~.pd on other more sane platforms, and some init
hack for Windows. The other issue is the setup function. Pd insists
on having the class name in the setup function. If it was just setup
() like Max/MSP, then that would not be an issue.
So we've discussed this a lot, but what needs to happen is that some
code needs to be written and tested. IOhannes has spend a ton of
time on this issue, and is understandably frustrated. I don't think
there is much to be gained by discussing it again, unless someone
steps up and works on it.
.hc
I mean why not make an external with the three-character name [ctl-alt-del]?
Ctrl and Alt are not characters and don't have any character code representation.
That makes them so much more interesting to implement ;) Or how about [ctl-g], which should make the computer beep whenever you type it
in...Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
ok, sorry to have caused a fuss.
last question: hypothetically, if miller was to include >~ and <~ into vanilla, would they load properly then?
i think those objects SHOULD be a part of vanilla pd anyway. in any sort of audio synthesis patch i do, they invariably need to be used.
hard off wrote:
ok, sorry to have caused a fuss.
last question: hypothetically, if miller was to include >~ and <~ into vanilla, would they load properly then?
yes of course.
again: the only problem with these objects is that you cannot have files (e.g. binary files containing the code for these objects; or abstractions) that are include characters like ">" on certain platforms.
the only solution for this is to use filenames that are named differently than the actual class.
this solution can be implenmented in various ways:
- include it into Pd-vanilla (so these objects would reside in the file
"pd.lib" or "pd")
- use multi-object libraries (so these objects reside in "zexy.l_i386")
- use aliases (so ">~" really lives in "gt~.pd")
- use a hexloader (kind of generated filenames that map to the original
classname), so ">~" resides in "0x3e0x7e.pd"
so it's rather simple, BUT:
- Pd-vanilla does not include all the fancy'n'cool objects into Pd (esp.
if they can be easily built as externals)
- multi-object libraries are deprecated in PdX
- aliases are problematic, as you have to tell Pd about these aliases
somehow (the mapping from ">~" to "gt~" is rather arbitrary)
- the hexloader has only been partially accepted into Pd-vanilla (that
is: the filename mangling part has been taken out); and the implementation of it as an external loader has only created problems for everyone.
mfgasdr IOhannes
On Jul 17, 2008, at 5:03 AM, IOhannes m zmoelnig wrote:
hard off wrote:
ok, sorry to have caused a fuss.
last question: hypothetically, if miller was to include >~ and <~
into vanilla, would they load properly then?yes of course.
again: the only problem with these objects is that you cannot have
files (e.g. binary files containing the code for these objects; or abstractions) that are include characters like ">" on certain
platforms.the only solution for this is to use filenames that are named differently than the actual class.
this solution can be implenmented in various ways:
- include it into Pd-vanilla (so these objects would reside in the
file "pd.lib" or "pd")
- use multi-object libraries (so these objects reside in
"zexy.l_i386")
- use aliases (so ">~" really lives in "gt~.pd")
- use a hexloader (kind of generated filenames that map to the
original classname), so ">~" resides in "0x3e0x7e.pd"
so it's rather simple, BUT:
- Pd-vanilla does not include all the fancy'n'cool objects into Pd
(esp. if they can be easily built as externals)
- multi-object libraries are deprecated in PdX
- aliases are problematic, as you have to tell Pd about these aliases
somehow (the mapping from ">~" to "gt~" is rather arbitrary)
- the hexloader has only been partially accepted into Pd-vanilla (that
is: the filename mangling part has been taken out); and the implementation of it as an external loader has only created
problems for everyone.
So the loaded classes need to be fixed to that they are canvas-local,
not global like it is currently. If that was the case, then I could
see using multi-class-single-file libraries for cases like this,
provided that they could be used like [>~] and [math/>~]. The tricky
part would be getting the "math.pd_linux" file to load automatically
when someone creates [math/>~].
.hc
mfgasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
On Jul 17, 2008, at 4:34 AM, hard off wrote:
ok, sorry to have caused a fuss.
last question: hypothetically, if miller was to include >~ and <~
into vanilla, would they load properly then?
i think those objects SHOULD be a part of vanilla pd anyway. in
any sort of audio synthesis patch i do, they invariably need to be
used.
Depends on how they are built and loaded.
.hc
Mistrust authority - promote decentralization. - the hacker ethic
Hans-Christoph Steiner wrote:
On Jul 17, 2008, at 4:34 AM, hard off wrote:
ok, sorry to have caused a fuss.
last question: hypothetically, if miller was to include >~ and <~ into vanilla, would they load properly then?
i think those objects SHOULD be a part of vanilla pd anyway. in any sort of audio synthesis patch i do, they invariably need to be used.
Depends on how they are built and loaded.
i guess that hard off was thinking of the way internals are currently included into Pd (compiled statically into a multi-object "library" that get's automatically loaded at startup) when he was asking to "include" them into vanilla, rather than include them like "expr" (as an external that ships with the vanilla distribution)
fgamsdr IOhannes
yeah totally.
it seems nonsensical that pd has > and < for control signals, but not for audiorate signals.
and as andy obiwan mentioned before [pow~] would also be very useful.
as far as i can guess, all of these objects are very simple code-wise.
On Wed, 16 Jul 2008, Roman Haefeli wrote:
(the only difference i know of is troubles with special-characters when using single-object externals)
there is also the issue, that aliases are not (completely) supported by pd-extended, afaik.
Don't expect aliases to be supported by software made by someone who thinks aliases are wrong or ugly or evil. That's someone who would deprecate class_addcreator just because.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
-
Enrique Erne -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
marius schebella -
Martin Peach -
Mathieu Bouchard -
Roman Haefeli