hi all ...
i'm currently thinking of a way to solve the nameclash problem (counter, scale, prepend, gate...)
here are some suggestions for a solution ... with some pros and cons:
namespaces: add the library name like library/object or library::object pros: - selectable at runtime
- the patch will work exactly as you expect, since you see that object is from library
cons: - "/" is already used for the search path (shouldn't be a big problem), "::" are two chars - only works if an object is compiled as library ... if a library is split to single externals (like the build system does) pd is not aware of the library name
startup flav: having another flag like -force library/object or -force library::object pros: - easy to use cons: - you can't use both library1::object and library2::object
- behaviour of the patch depends on startup flags (less portable)
communication: figure out, if the external name is already in use pros: - no implementation effords cons: - not really working (that's why we've got these problems *g*)
standard behaviour: if object1 is doing the same as object2, except that it is missing one feature, add this feature to object1, if they behave exactly the same, the nameclash isn't a problem any more ... (escept for the waste of memory) pros: - as above cons: - as above
personally i'd prefer the communication in combination with a startup flag ... but i'm curious about other ideas or comments ...
cheers ... tim
I think communication is necessary anyways, but a technical solution would allow pd to scale to a larger community. namespaces also allow names to be more easy to understand. A startup flag would be very nice to have now though, it would allow using all of the libraries
2€¢
. g
El 04/11/2004, a las 23:19, Tim Blechmann escribió:
hi all ...
i'm currently thinking of a way to solve the nameclash problem (counter, scale, prepend, gate...)
here are some suggestions for a solution ... with some pros and cons:
namespaces: add the library name like library/object or library::object pros: - selectable at runtime
- the patch will work exactly as you expect, since you see that object is from library
cons: - "/" is already used for the search path (shouldn't be a big problem), "::" are two chars - only works if an object is compiled as library ... if a library is split to single externals (like the build system does) pd is not aware of the library name
startup flav: having another flag like -force library/object or
-force library::object pros: - easy to use cons: - you can't use both library1::object and library2::object
behaviour of the patch depends on startup flags (less portable)
communication: figure out, if the external name is already in use pros: - no implementation effords cons: - not really working (that's why we've got these problems *g*)
standard behaviour: if object1 is doing the same as object2, except that it is missing one feature, add this feature to object1, if they behave exactly the same, the nameclash isn't a problem any more ... (escept for the waste of memory) pros: - as above cons: - as above
personally i'd prefer the communication in combination with a startup flag ... but i'm curious about other ideas or comments ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi, i'd prefer the namespace approach with some separation character that has a clear meaning and isn't otherwise widely used. e.g. / | _would be ok. Communication is always good but shouldn't be a must. There may be people contributing things that aren't good at it. I don't like the flag approach very much since it's more a private "fix", not a general solution.
best greetings. Thomas
----- Original Message ----- From: "Tim Blechmann" TimBlechmann@gmx.net To: pd-dev@iem.at Cc: pd-list@iem.at Sent: Thursday, November 04, 2004 11:19 PM Subject: [PD-dev] nameclashes
hi all ...
i'm currently thinking of a way to solve the nameclash problem (counter, scale, prepend, gate...)
here are some suggestions for a solution ... with some pros and cons:
namespaces: add the library name like library/object or library::object pros: - selectable at runtime
the patch will work exactly as you expect, since you see that object is from library cons: - "/" is already used for the search path (shouldn't be a big problem), "::" are two chars - only works if an object is compiled as library ... if a library is split to single externals (like the build system does) pd is not aware of the library name
startup flav: having another flag like -force library/object or -force library::object pros: - easy to use cons: - you can't use both library1::object and library2::object
behaviour of the patch depends on startup flags (less portable)
communication: figure out, if the external name is already in use pros: - no implementation effords cons: - not really working (that's why we've got these problems *g*)
standard behaviour: if object1 is doing the same as object2, except that it is missing one feature, add this feature to object1, if they behave exactly the same, the nameclash isn't a problem any more ... (escept for the waste of memory) pros: - as above cons: - as above
personally i'd prefer the communication in combination with a startup flag ... but i'm curious about other ideas or comments ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
i'd prefer the namespace approach with some separation character that has a clear meaning and isn't otherwise widely used. e.g. / | _would be ok. Communication is always good but shouldn't be a must. There may
a namespace would definitely be a clean approach ... but someone will have to rewrite the build system ... the fact that single externals from the build system will cause problems ... there is also the problem with cyclone, since you don't know if cyclone is one cyclone library, or split to hammer, sickle and dummy ...
cheers ... tim
hi list! I installed the debian pdp package from: http://sindominio.net/~caedes/debian/ . IT worked fine, i can activate the external..... the problem i have is that i cant create the new window, for example in the patch input_output (pdp/introduction) when i hit the create buttom the video window doenst appear. i get the following message in pd kernel: p_xv: cant open display :0
any idea of what is going wrong??? i have all the requirements installed. im using Pd version 0.37.1 devel and im on agnula demudi.
many thanks
pun chik
hi,
is your X server Xvideo capable ? you can know it with the command 'xvinfo', it will tell you the number of Xvideo ports ( Xvideo windows ) you can create on your system.
X-Video Extension version 2.2 screen #0 Adaptor #0: "Intel(R) 830M/845G/852GM/855GM/865G/915G Video Overlay" number of ports: 1
if you don't have Xvideo enabled, you have to replace all pdp_xv objects with pdp_glx objects.
cheers from Bergen, sevy
pun chik wrote:
hi list! I installed the debian pdp package from: http://sindominio.net/~caedes/debian/ . IT worked fine, i can activate the external..... the problem i have is that i cant create the new window, for example in the patch input_output (pdp/introduction) when i hit the create buttom the video window doenst appear. i get the following message in pd kernel: p_xv: cant open display :0
any idea of what is going wrong??? i have all the requirements installed. im using Pd version 0.37.1 devel and im on agnula demudi.
many thanks
pun chik
On Fri, Nov 05, 2004 at 03:19:58AM -0800, pun chik wrote:
hi list! I installed the debian pdp package from: http://sindominio.net/~caedes/debian/ . IT worked fine, i can activate the external..... the problem i have is that i cant create the new window, for example in the patch input_output (pdp/introduction) when i hit the create buttom the video window doenst appear. i get the following message in pd kernel: p_xv: cant open display :0
any idea of what is going wrong??? i have all the requirements installed. im using Pd version 0.37.1 devel and im on agnula demudi.
many thanks
pun chik
probably you don't have Xv try to run the program 'xvinfo' to find this out. another problem could be permissions of X server. yet another problem could be that your Xv only allows 1 open connection.
cheers tom
i got this:
xvinfo X-Video Extension version 2.2 screen #0 no adaptors present
any idea ?
On Fri, 5 Nov 2004 13:52:30 +0100, "Tom Schouten" doelie@zzz.kotnet.org said:
On Fri, Nov 05, 2004 at 03:19:58AM -0800, pun chik wrote:
hi list! I installed the debian pdp package from: http://sindominio.net/~caedes/debian/ . IT worked fine, i can activate the external..... the problem i have is that i cant create the new window, for example in the patch input_output (pdp/introduction) when i hit the create buttom the video window doenst appear. i get the following message in pd kernel: p_xv: cant open display :0
any idea of what is going wrong??? i have all the requirements installed. im using Pd version 0.37.1 devel and im on agnula demudi.
many thanks
pun chik
probably you don't have Xv try to run the program 'xvinfo' to find this out. another problem could be permissions of X server. yet another problem could be that your Xv only allows 1 open connection.
cheers tom
On Fri, Nov 05, 2004 at 05:21:01AM -0800, pun chik wrote:
i got this:
xvinfo X-Video Extension version 2.2 screen #0 no adaptors present
any idea ?
that's pretty clear, Xv is not supported. what card are you using?
the other alternative like yves explained is to use pdp_glx instead of pdp_xv. for this you need to have a working opengl (glx) setup.
cheers tom
On Fri, Nov 05, 2004 at 05:21:01AM -0800, pun chik wrote:
i got this:
xvinfo X-Video Extension version 2.2 screen #0 no adaptors present
any idea ?
make sure you have libxv1 - X Window System video extension library installed, and check for any commented xv load lines in XF86config..and run xhost + and export DISPLAY=:0
On Fri, 5 Nov 2004 13:52:30 +0100, "Tom Schouten" doelie@zzz.kotnet.org said:
On Fri, Nov 05, 2004 at 03:19:58AM -0800, pun chik wrote:
hi list! I installed the debian pdp package from: http://sindominio.net/~caedes/debian/ . IT worked fine, i can activate the external..... the problem i have is that i cant create the new window, for example in the patch input_output (pdp/introduction) when i hit the create buttom the video window doenst appear. i get the following message in pd kernel: p_xv: cant open display :0
any idea of what is going wrong??? i have all the requirements installed. im using Pd version 0.37.1 devel and im on agnula demudi.
many thanks
pun chik
probably you don't have Xv try to run the program 'xvinfo' to find this out. another problem could be permissions of X server. yet another problem could be that your Xv only allows 1 open connection.
cheers tom
-- pun chik punchik@fastmail.fm
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
or you can use pdp_sdl http://www.libsdl.org/index.php pat
----- Original Message ----- From: "pun chik" punchik@fastmail.fm To: PD-list@iem.at Sent: Friday, November 05, 2004 8:21 AM Subject: Re: [PD] pdp help!!!
i got this:
xvinfo X-Video Extension version 2.2 screen #0 no adaptors present
any idea ?
I know that the pd fileformat does not allow comments or headers. But I was thinking of a declaration in a header like "from iemlib import gate" and all gates in the patch would be iem ones. I dont like the idea of typing iem::gate all the time and I think it may be easier to define the object at the beginning of the pd file than replacing the text of every object. And you could use different library objects in different abstractions. Apart from that, I think, communication is best. Is there a list of all problem objects until now? i think also the capital letter-cyclone objects are problematic, because of the help-patches, which are not displayed correctly under windows.
Append (pd native, cyclone) Clip (pd native, cyclone) Line~ (pd native, cyclone) Snapshot~ (pd native, cyclone) Scope~ (pd native, cyclone) gate (iemlib, cyclone) prepend (iemlib, cyclone) split (iemlib, cyclone) and I think there are some cyclone dummies, which will be objects in the future (?). like sfplay~.
btw. arent there also problems with abstraction nameclashes?
marius.
----- Original Message ----- From: "Tim Blechmann" TimBlechmann@gmx.net To: pd-dev@iem.at Cc: pd-list@iem.at Sent: Thursday, November 04, 2004 11:19 PM Subject: [PD] nameclashes
hi all ...
i'm currently thinking of a way to solve the nameclash problem (counter, scale, prepend, gate...)
here are some suggestions for a solution ... with some pros and cons:
- namespaces: add the library name like library/object or
library::object pros: - selectable at runtime
- the patch will work exactly as you expect, since you see that object is from library
cons: - "/" is already used for the search path (shouldn't be a big problem), "::" are two chars - only works if an object is compiled as library ... if a library is split to single externals (like the build system does) pd is not aware of the library name
- startup flav: having another flag like -force library/object or -force
library::object pros: - easy to use cons: - you can't use both library1::object and library2::object
behaviour of the patch depends on startup flags (less portable)
communication: figure out, if the external name is already in use
pros: - no implementation effords cons: - not really working (that's why we've got these problems *g*)
- standard behaviour: if object1 is doing the same as object2, except
that it is missing one feature, add this feature to object1, if they behave exactly the same, the nameclash isn't a problem any more ... (escept for the waste of memory) pros: - as above cons: - as above
personally i'd prefer the communication in combination with a startup flag ... but i'm curious about other ideas or comments ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
I have a hard time myself with the library thing...I usually use only one or two objects from a library. Would it not be preferable to have the individual objects from a library inside their own folder nested inside the externs folder? I would also feel a lot better if there was a mechanism to register every object with a unique name, so that a developer who wanted to publish their object would register it in the database the same way you choose an email address: if the name is already in use, try again with another name. The names database could reside within the cvs repository. So you would have counter, counter1, counter2, ...
.02CAD Martin
Tim Blechmann wrote:
hi all ...
i'm currently thinking of a way to solve the nameclash problem (counter, scale, prepend, gate...)
here are some suggestions for a solution ... with some pros and cons:
namespaces: add the library name like library/object or library::object pros: - selectable at runtime
- the patch will work exactly as you expect, since you see that object is from library
cons: - "/" is already used for the search path (shouldn't be a big problem), "::" are two chars - only works if an object is compiled as library ... if a library is split to single externals (like the build system does) pd is not aware of the library name
startup flav: having another flag like -force library/object or -force library::object pros: - easy to use cons: - you can't use both library1::object and library2::object
- behaviour of the patch depends on startup flags (less portable)
communication: figure out, if the external name is already in use pros: - no implementation effords cons: - not really working (that's why we've got these problems *g*)
standard behaviour: if object1 is doing the same as object2, except that it is missing one feature, add this feature to object1, if they behave exactly the same, the nameclash isn't a problem any more ... (escept for the waste of memory) pros: - as above cons: - as above
personally i'd prefer the communication in combination with a startup flag ... but i'm curious about other ideas or comments ...
cheers ... tim
-
0001 -
ix -
Marius Schebella -
Martin Peach -
patrick -
pun chik -
Thomas Grill -
Tim Blechmann -
Tom Schouten -
Yves Degoyon