pd
pd copied to clipboard
pd-l2ork
[cyclone/uzi] is not recognized
Pd-l2Ork cannot create the object [cyclone/uzi], while it can create [cyclone/Uzi](note that in the latter Uzi starts with capital letter). This may cause problems of compatibility since pd-extended recognizes both spellings as being the same object.
This is because uzi is an alias for cyclone/kalashnikov, and aliases don't become valid until their original objects are loaded, and because pd-extended 41.4 loads entire cyclone as a library rather than individual objects. Pd-extended 0.42.x and up have this same problem with aliases. Currently there is no known graceful way of dealing with this beyond creating an actual symlink (and even then this needs to be tested). HTH
On Sat, Jan 31, 2015 at 6:31 PM, Gilberto Agostinho < [email protected]> wrote:
Pd-l2Ork cannot create the object [cyclone/uzi], while it can create cyclone/Uzi http://note%20that%20in%20the%20latter%20Uzi%20starts%20with%20capital%20letter. This may cause problems of compatibility since pd-extended recognizes both spellings as being the same object.
— Reply to this email directly or view it on GitHub https://github.com/pd-l2ork/pd/issues/14.
Pd-extended 0.42.x and up have this same problem with aliases.
I don't understand this, do you mean that it has the same problem with aliases as this one described in Pd-l2Ork? If so, then there is something wrong, since when using pd-extended 0.43.4 I am able to create [uzi], [Uzi], [cyclone/uzi] and [cyclone/Uzi].
Actually, the folder /usr/lib/pd-extended/extra/cyclone contains both an uzi.pd_linux and a Uzi.pd_linux (and one help file for each), whereas /usr/lib/pd-l2ork/extra/cyclone contains only the captalized version.
Just following up on this. I think this is because pd-extended tries to cover every possible legacy case. In Pd-L2Ork preference is given to using the same singular object to minimize redundancy (at the expense of potential backwards compatibility). You can always create your own symlinks if you would like to support backwards compatibility of these essentially redundant object names and this may very well be something we may want to provide as an optional addon for legacy support. What I propose that we do, is to get rid of Uzi and just keep lowercase uzi (we will try to get rid of all uppercase objects as we continue to filter 3rd party externals--if you would like to create a spreadsheet of proposed migration path for these this would help greatly move this initiative forward).
we will try to get rid of all uppercase objects as we continue to filter 3rd party externals--if you would like to create a spreadsheet of proposed migration path for these this would help greatly move this initiative forward
Ok, I will do that! I know some few objects beginning with capital letters, but I will go through all of them and see if I find something else. I will let you know about it.
Sent you the list by mail, let me know if I can be of any more help.
Gilberto, just to let you know I will be looking into this soon and hopefully there will be a solution as part of the next release. Hope this helps!