Are you really sure you want that? These days most Pd-users expect an implicit float-to-signal conversion. This might lead to unexpected (though well-defined) behaviour of your objects. My advice is to not try hard to break the expectancy of your users.
Hello,
In normal circumstances, I'd be in 100% agreement with you, the user experience should be consistent throughout the entirety of PD. But in this situation I'm doing work for cyclone, and in particular scope~ accepts a signal in the right inlet for graphing on the Y-axis and a separately a float to change the buffer size and I'm trying to stay as close to the original spec as possible.
===================== Derek Kwan www.derekxkwan.com
On 03/28/2016 01:27 AM, Derek Kwan wrote:
Are you really sure you want that? These days most Pd-users expect an implicit float-to-signal conversion. This might lead to unexpected (though well-defined) behaviour of your objects. My advice is to not try hard to break the expectancy of your users.
Hello,
In normal circumstances, I'd be in 100% agreement with you, the user experience should be consistent throughout the entirety of PD. But in this situation I'm doing work for cyclone, [...]
yes, sorry.
i only realized that this was about a max/msp compat object after i sent the email (and being virtually offline with only a mobile phone to type emails, i decided to not amend my post)
mfdsar IOhannes
Hi Derek,Have a look at the inlet_new code in m_obj.c. But after skimming it I don't see any sensible way to achieve what you want. I'd suggest just using the left-most inlet with a sensible method name. "Scope~" already has a capital "S" in the name for no _good_ reason, so it's not like the method space is the only discrepancy.
-Jonathan
On Monday, March 28, 2016 3:06 PM, IOhannes m zmölnig <zmoelnig@iem.at> wrote:
On 03/28/2016 01:27 AM, Derek Kwan wrote:
Are you really sure you want that? These days most Pd-users expect an implicit float-to-signal conversion. This might lead to unexpected (though well-defined) behaviour of your objects. My advice is to not try hard to break the expectancy of your users.
Hello,
In normal circumstances, I'd be in 100% agreement with you, the user experience should be consistent throughout the entirety of PD. But in this situation I'm doing work for cyclone, [...]
yes, sorry.
i only realized that this was about a max/msp compat object after i sent the email (and being virtually offline with only a mobile phone to type emails, i decided to not amend my post)
mfdsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2016-03-28 17:35 GMT-03:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at
:
after skimming it I don't see any sensible way to achieve what you want.
Just to be clear, do you mean you can't see any way, or that you may see some possible hacks that might be very clumsy and might not work well and be kind of non sensible tasks?
it's not like the method space is the only discrepancy.
In fact, the object already sets this method via a message in the first inlet, and this was working already in the last release, although the documentation was wrong, saying it had a "buffsize" method, when it is actually "bufsize". At first I thought the object was bugged, but the documentation was.
So we already have that implemented and it is fine. We've been working on it for a great deal now, and the only discrepancy left is this feature. It'd be good to make it 100% compatible, and it is really convenient to use this feature by the way - as we always have to tweak with this parameter when using scope~
cheers
Actually after looking deeper I have no clue. It looks like cyclone has some helper functions to set a separate float method for the leftmost signal inlet. If you can figure out how it works perhaps you can try doing the same for a secondary inlet. -Jonathan
On Monday, March 28, 2016 11:59 PM, Alexandre Torres Porres <porres@gmail.com> wrote:
2016-03-28 17:35 GMT-03:00 Jonathan Wilkes via Pd-list pd-list@lists.iem.at:
after skimming it I don't see any sensible way to achieve what you want.
Just to be clear, do you mean you can't see any way, or that you may see some possible hacks that might be very clumsy and might not work well and be kind of non sensible tasks?
it's not like the method space is the only discrepancy.
In fact, the object already sets this method via a message in the first inlet, and this was working already in the last release, although the documentation was wrong, saying it had a "buffsize" method, when it is actually "bufsize". At first I thought the object was bugged, but the documentation was.
So we already have that implemented and it is fine. We've been working on it for a great deal now, and the only discrepancy left is this feature. It'd be good to make it 100% compatible, and it is really convenient to use this feature by the way - as we always have to tweak with this parameter when using scope~ cheers
Actually after looking deeper I have no clue. It looks like cyclone has some helper functions to set a separate float method for the leftmost signal inlet. If you can figure out how it works perhaps you can try doing the same for a secondary inlet.
Hello Jonathan,
Yeah, scope's setup calls sic_setup (defined in shared/sickle/sic.c) which takes in a dsp function and a float function as input. Looks like if there is a float function passed, the signal stuff gets handled by class_domainsignalin() while floats are handled by class_addfloat() and there isn't a float function passed, it's just all handled by CLASS_MAINSIGNALIN(). I know CLASS_MAINSIGNALIN() and class_addfloat() are called from input into the main inlet, and i suppose class_domainsignalin() is too? There's another function sic_inlet() in sic.c but it looks like just a wrapper around inlet_new() and pd_float().
Derek Kwan www.derekxkwan.com
Well, I just couldn't understand how to get the behavior you're after by looking at the inlet_new code. But looking at that cyclone wrapper function it seems like you should be able to get the same behavior with a proxy inlet. -Jonathan
On Tuesday, March 29, 2016 8:01 AM, Derek Kwan <derek.x.kwan@gmail.com> wrote:
Actually after looking deeper I have no clue. It looks like cyclone has some helper functions to set a separate float method for the leftmost signal inlet. If you can figure out how it works perhaps you can try doing the same for a secondary inlet.
Hello Jonathan,
Yeah, scope's setup calls sic_setup (defined in shared/sickle/sic.c) which takes in a dsp function and a float function as input. Looks like if there is a float function passed, the signal stuff gets handled by class_domainsignalin() while floats are handled by class_addfloat() and there isn't a float function passed, it's just all handled by CLASS_MAINSIGNALIN(). I know CLASS_MAINSIGNALIN() and class_addfloat() are called from input into the main inlet, and i suppose class_domainsignalin() is too? There's another function sic_inlet() in sic.c but it looks like just a wrapper around inlet_new() and pd_float().
Derek Kwan www.derekxkwan.com
2016-03-29 18:55 GMT-03:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at
:
looking at that cyclone wrapper function it seems like you should be able to get the same behavior with a proxy inlet.
an example of an object that uses it? where exactly is this function?
thanks
an example of an object that uses it? where exactly is this function?
Scope~ itself uses sic_setup (for the leftmost inlet). -Jonathan
On Wednesday, March 30, 2016 11:03 AM, Alexandre Torres Porres <porres@gmail.com> wrote:
2016-03-29 18:55 GMT-03:00 Jonathan Wilkes via Pd-list pd-list@lists.iem.at:
looking at that cyclone wrapper function it seems like you should be able to get the same behavior with a proxy inlet.
an example of an object that uses it? where exactly is this function? thanks
 an example of an object that uses it? where exactly is this function?
Scope~ itself uses sic_setup (for the leftmost inlet). -Jonathan
Hello,
So I gave using class_domainsignalin() and class_addfloat() a shot in the setup of both main and proxy classes in my test external which is what sic_setup() is doing for audio rate objects with separate float methods and it does work for the main inlet (which was never an issue) but produces the same results as before for the proxy inlet. Maybe I'm not using the proxy class correctly? And sic_inlet is just a wrapper around inlet_new() and sets a default value of the signal via pd_float() so that's no help to me either.
Basically what connects the proxy inlet to the main class from what i've found here: http://puredata.info/Members/mjmogo/proxy-example-for-pd.zip/view is that the proxy class is declared as a member in the main class's struct (t_proxy pxy for example) and serves as the dest for a new inlet declared in the main class's new method through:
inlet_new(&x -> x_obj, &x -> pxy.l_pd, 0, 0);
which creates a control inlet but all of the proxy's class's methods are accessible (besides dsp methods since it's a control inlet, I've tried...) or this other way I've tried:
inlet_new(&x -> x_obj, &x -> pxy.l_pd, &s_signal, &s_signal); or inlet_new(&x -> x_obj, &x -> pxy.l_pd, &s_signal, 0);
both of which create an audio inlet and none of the proxy class's methods are accessible (including the class_domainsignalin() and class_addfloat() methods declared in the proxy class) but you can get the signal value going into the second inlet from the main class's perform method.
The other things that sic_setup does is if passed SIC_NOMAINSIGNALIN, just make's a float inlet and if passed no float function, makes just a regular signal inlet that interprets floats as signals via CLASS_MAINSIGNALIN().
I'll do more digging...
Derek Kwan www.derekxkwan.com
(oops, forgot to cc the list, sorry iohannes, still getting a handle on this...)
did i miss something? why would it not work with proxy inlets?
With the code I found here: http://puredata.info/Members/mjmogo/proxy-example-for-pd.zip/view tackling proxy inlets (basically making a proxy class and pointing the destination of inlet_new to it), declaring inlet_new with 0's as the selectors (as in the example code) would result in a control inlet (when I'm wanting a signal inlet) but methods like class_addfloat declared in the proxy class's setup would work.
Passing &s_signal as the first selector in inlet_new would result in a second inlet, but the values of the signal were only accessible within the main class's dsp/perform methods and not within dsp/perform methods declared in proxy's setup but more importantly, the class_addfloat and so on methods declared in proxy's setup aren't callable.
===================== Derek Kwan www.derekxkwan.com
On 2016-03-28 22:35, Jonathan Wilkes via Pd-list wrote:
"Scope~" already has a capital "S" in the name for no _good_ reason, so it's not like the method space is the only discrepancy.
the *very good* reason for the capital "S" is that back in the days when cyclone was developed, Pd (vanilla) sported a [scope~] object.
fgmadrt IOhannes
Yes, there's a very good reason to employ a solution to a name clash. Also, using a capital letter in an external name is a poor solution to that problem. Even calling the thing "pdrunsonwindowstooscope~" would have been better. -Jonathan
On Tuesday, March 29, 2016 3:21 AM, IOhannes m zmoelnig <zmoelnig@iem.at> wrote:
On 2016-03-28 22:35, Jonathan Wilkes via Pd-list wrote:
"Scope~" already has a capital "S" in the name for no _good_ reason, so it's not like the method space is the only discrepancy.
the *very good* reason for the capital "S" is that back in the days when cyclone was developed, Pd (vanilla) sported a [scope~] object.
fgmadrt IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2016-03-30 00:03, Jonathan Wilkes via Pd-list wrote:
Yes, there's a very good reason to employ a solution to a name clash.
Also, using a capital letter in an external name is a poor solution to that problem. Even calling the thing "pdrunsonwindowstooscope~" would have
well, yes or no.
[Scope~] did solve the nameclash after all, even if you build cyclone as a set of single-object-externals and deployed on a case-insensitive filesystem.
so i'm not sure what you are trying to prove with random belittelations.
fgmdsr IOhannes
pdrunsonwindowstoo
maybe windows is/was not that case sensitive?
On 30 Mar 2016, at 09:53, IOhannes m zmoelnig zmoelnig@iem.at wrote:
pdrunsonwindowstoo
2016-03-30 4:53 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
[Scope~] did solve the nameclash after all, even if you build cyclone as a set of single-object-externals and deployed on a case-insensitive filesystem.
well, we don't need to solve that anymore. And by the way, nowadays also Scope~ loads as scope~ since - if I'm not mistaken - Pd Extended 0.43 (cyclone version 0.1alpha56), where this change happened.
So, what did this change actually changed? Say someone started using [scope~] nowadays, may this object not instantiate somewhere with alpha56+ cyclone versions? Why and how?
And what would change if the official name restores to scope~ (with Scope~ being called the way "scope~" is now?
cheers
2016-04-06 18:53 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
And what would change if the official name restores to scope~ (with Scope~ being called the way "scope~" is now?
Well, I tested it here... I traded it for the opposite. I changed "Scope~" to "scope~" and made it instantiate as Scope~ as well for backwards compatibility. Works fine.
cheers
I don't think that's backwards compatible. For example-- if the user isn't loading cyclone by default, and their patch does this: [declare -lib cyclone/Scope~] [Scope~]
If by "traded" you mean you renamed the binary to scope~.pd_linux, this won't load anymore. I'd actually be in favor of breaking that compatibility if there were a way to get rid of all those capital letters from cyclone. However, you still need "Append" to differentiate from the internal "append" class, so you can't change that one. Also-- why is there a class_addcreator to add "cyclone/*" for each class? That _should_ be superfluous... -Jonathan
On Friday, April 8, 2016 2:21 PM, Alexandre Torres Porres <porres@gmail.com> wrote:
2016-04-06 18:53 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
And what would change if the official name restores to scope~ (with Scope~ being called the way "scope~" is now?
Well, I tested it here... I traded it for the opposite. I changed "Scope~" to "scope~" and made it instantiate as Scope~ as well for backwards compatibility. Works fine. cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
2016-04-08 16:11 GMT-03:00 Jonathan Wilkes jancsika@yahoo.com:
if the user isn't loading cyclone by default, and their patch does this: [declare -lib cyclone/Scope~]
Ok, but what would that do in the first place? I don't think I get [declare] yet, can you find a specific individual binary or object inside a library?
Then, cyclone does not come as a library for a long time, and "Scope~" is not part of a "-lib"
If by "traded" you mean you renamed the binary to scope~.pd_linux, this won't load anymore.
Nope, I changed stuff in the code as well
I might be wrong, but it seems possible to change it and maintain backwards compatibility and get rid of this annoying Capital letter, but I'm consulting you guys to be sure.
you still need "Append" to differentiate from the internal "append" class, so you can't change that one.
Things, to my surprise, things work in a new and weird way to me in Pd Vanilla. Any class you call that is not the internal one overwrites the internal library. I discussed this on a previous thread these days (Name conflicts "class overwritten; old one renamed 'x_aliased').
The way things are in cyclone nowadays, and I had given the example of "line~" is that it has the "Line~" official and legacy name version but also calls the objects as alias "line~" or "cyclone/line~"
Also-- why is there a class_addcreator to add "cyclone/*" for each class? That _should_ be superfluous...
It's not for every class, but these one with name clashing issues.
So, anyway. How things are now, if I call "Line~", internally it will find the alias "line~" and load it overwritting vanilla's line~. That sucks cause they're not compatible. And basically you had this Capital letter in the first place to avoid name clashing and it was clashing it anyway... (yeah, quite ironic).
It seems that this system would allow you to load cyclone/line~ in Pd Extended and Pd-L2ork, because in both of them, there is no internal overwritting going on. So latest version of extended (0.43) introduced this system with the alias. You can call [cyclone/uzi] and [cyclone/line~] for example, but the latter won't overwritte the internal vanilla's line~
By the "Uzi" is another example like "Scope~", some Capital letter for some reason that is not relevant anymore... and yeah, Uzi comes with the aliases "uzi" e "cyclone/uzi".
But back to "Line~"
if I remove the alias "cyclone/line~" I can now call [Line~] or [cyclone/line~] in Pd without overwritting the internal, and being able to differentiate between [line~] (internal) and [cyclone/line~] external. This is the same case as with Append. I think we should keep the weird animal "Line~" as an alias and an option over [cyclone/line~].
But Uzi and Scope~ are in another category, they don't overwrite internals. In Pd-L2ork you have an old version of Scope~ without the alias, so you won't be able to load it as "scope~" or "cyclone/scope~", but [Uzi] is updated, so you can call it as [uzi] or [cyclone/uzi]. I can only test this in Mac Os, but with the version you provided today, I can do it. Can you do it in linux and windows?
Anyway, I assume that if they did it in Pd Extended, it was for the reason that the trick worked for every system, or they wouldn't introduce this madness or massive inconsistency. And my thought is, if you can do it one way to the other, you can also do it the other way around... if I can call "uzi" as an alias, then I can call "Uzi" as an alias as well.
So, getting Uzi as an example, if I switch everything to the opposite like this:
*void uzi_setup(void) { uzi_class = class_new(gensym("uzi") (...) class_addcreator((t_newmethod)uzi_new, gensym("Uzi"), A_DEFFLOAT, 0);class_addcreator((t_newmethod)uzi_new, gensym("cyclone/Uzi"), A_DEFFLOAT, 0) (...)*
*void Uzi_setup(void) { uzi_setup(); }* Plus the code to "uzi.c" and compiled the object as uzi.pd_darwin
Well, I can call it as [uzi], or as [Uzi] and [cyclone/Uzi]
If I don't have the "cyclone/Uzi" alias, then that doesn't work.
I'd actually be in favor of breaking that compatibility if there were a way
to get rid of all those capital letters from cyclone.
And I'd actually second you on that, and we don't need those capital letters for "uzi" or "scope~", so, at least in these two cases, there's a pretty simple way to get rid of it.
But, as I'm saying, I think there is a way to change this and keep the alias for backwards compatibility.
Cheers
On 04/08/2016 10:29 PM, Alexandre Torres Porres wrote:
Then, cyclone does not come as a library for a long time, and "Scope~" is not part of a "-lib"
but it is! it is part of a library named "Scope~.pd_linux" which contains a single object "Scope~".
mdsf IOhannes
On Fri, Apr 8, 2016 at 10:52 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 04/08/2016 10:29 PM, Alexandre Torres Porres wrote:
Then, cyclone does not come as a library for a long time, and "Scope~" is not part of a "-lib"
but it is! it is part of a library named "Scope~.pd_linux" which contains a single object "Scope~".
He's building 'scope~.pd_linux'. With a symlink 'Scope~.pd_linux' and the alias in the C code, wouldn't that be all right?
mdsf IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Fri, Apr 8, 2016 at 10:52 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 04/08/2016 10:29 PM, Alexandre Torres Porres wrote:
Then, cyclone does not come as a library for a long time, and "Scope~" is not part of a "-lib"
but it is! it is part of a library named "Scope~.pd_linux" which contains a single object "Scope~".
He's building 'scope~.pd_linux'. With a symlink 'Scope~.pd_linux' and the alias in the C code, wouldn't that be all right?
mdsf IOhannes
Hello,
I'll chime in here because I've been working on this cyclone update as well (Alexandre, hop in here if I'm wrong about any of this). To my knowledge, there isn't any symlinking going on in the build process. I'm using Ubuntu on my machine and I just built it myself and all I get out for scope is scope~.pd_linux. All references to Scope has been changed to scope in Makefile and the source (sickle/Scope.c) got changed to sickle/scope.c. There's no symlink to scope~.pd_linux at all. Do we want to change the Makefile to build a symlink to the built scope~ (and also, what are the reasons for doing so)? Also. is there a symlink equivalent for Windows machines? I'll be honest, I'm not really familiar with Makefile building beyond the very basic stuff (I didn't even know you could make symlinks in Makefiles for instance)...
Derek
===================== Derek Kwan www.derekxkwan.com
Hello Derek,
The symlinks aren't created at compile time but during the install process. It is done by target 'install-aliases'. Do 'make install objectsdir=./build' to get a local install. If you still get no symlinks let me know.
I think they are only needed on Linux because of how file access happens.
Katja
On Sat, Apr 9, 2016 at 12:01 PM, Derek Kwan derek.x.kwan@gmail.com wrote:
On Fri, Apr 8, 2016 at 10:52 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 04/08/2016 10:29 PM, Alexandre Torres Porres wrote:
Then, cyclone does not come as a library for a long time, and "Scope~" is not part of a "-lib"
but it is! it is part of a library named "Scope~.pd_linux" which contains a single object "Scope~".
He's building 'scope~.pd_linux'. With a symlink 'Scope~.pd_linux' and the alias in the C code, wouldn't that be all right?
mdsf IOhannes
Hello,
I'll chime in here because I've been working on this cyclone update as well (Alexandre, hop in here if I'm wrong about any of this). To my knowledge, there isn't any symlinking going on in the build process. I'm using Ubuntu on my machine and I just built it myself and all I get out for scope is scope~.pd_linux. All references to Scope has been changed to scope in Makefile and the source (sickle/Scope.c) got changed to sickle/scope.c. There's no symlink to scope~.pd_linux at all. Do we want to change the Makefile to build a symlink to the built scope~ (and also, what are the reasons for doing so)? Also. is there a symlink equivalent for Windows machines? I'll be honest, I'm not really familiar with Makefile building beyond the very basic stuff (I didn't even know you could make symlinks in Makefiles for instance)...
Derek
===================== Derek Kwan www.derekxkwan.com
The symlinks aren't created at compile time but during the install process. It is done by target 'install-aliases'. Do 'make install objectsdir=./build' to get a local install. If you still get no symlinks let me know.
I think they are only needed on Linux because of how file access happens.
Katja
Great! Thanks. Yeah, that works.
When I'm doing the local install, I'm getting this error:
Makefile.pdlibbuilder:1013: recipe for target 'install-datafiles' failed make: *** [install-datafiles] Error 2
I haven't checked too thoroughly but it looks like everything is building. I'm sudo-ing it if that makes a difference.
Derek Kwan www.derekxkwan.com
Hello Derek,
The problem is with the following help files added by Alexandre:
<~-help.pd <=~-help.pd
~-help.pd =~-help.pd
You could filter these out from the wildcard search in the makefile and instead list them explicitly, between quotes like:
"help/<~-help.pd"
Alternatively you could make a single help patch 'nettles-help.pd' and use function class_sethelpsymbol() in all nettles classes. This is probably a better solution, avoiding more file name problems in the future.
Katja
On Sun, Apr 10, 2016 at 1:29 AM, Derek Kwan derek.x.kwan@gmail.com wrote:
The symlinks aren't created at compile time but during the install process. It is done by target 'install-aliases'. Do 'make install objectsdir=./build' to get a local install. If you still get no symlinks let me know.
I think they are only needed on Linux because of how file access happens.
Katja
Great! Thanks. Yeah, that works.
When I'm doing the local install, I'm getting this error:
Makefile.pdlibbuilder:1013: recipe for target 'install-datafiles' failed make: *** [install-datafiles] Error 2
I haven't checked too thoroughly but it looks like everything is building. I'm sudo-ing it if that makes a difference.
Derek
Derek Kwan www.derekxkwan.com
I notice there used to be one help patch indeed for all nettles, as in Fred Jan's version. For a good reason as we now see. Alexandre has created individual help patches for each nettles class. These could better be encapsulated within nettles-help.pd, rather than live as separate files.
Katja
On Sun, Apr 10, 2016 at 12:34 PM, katja katjavetter@gmail.com wrote:
Hello Derek,
The problem is with the following help files added by Alexandre:
<~-help.pd <=~-help.pd
~-help.pd =~-help.pd
You could filter these out from the wildcard search in the makefile and instead list them explicitly, between quotes like:
"help/<~-help.pd"
Alternatively you could make a single help patch 'nettles-help.pd' and use function class_sethelpsymbol() in all nettles classes. This is probably a better solution, avoiding more file name problems in the future.
Katja
On Sun, Apr 10, 2016 at 1:29 AM, Derek Kwan derek.x.kwan@gmail.com wrote:
The symlinks aren't created at compile time but during the install process. It is done by target 'install-aliases'. Do 'make install objectsdir=./build' to get a local install. If you still get no symlinks let me know.
I think they are only needed on Linux because of how file access happens.
Katja
Great! Thanks. Yeah, that works.
When I'm doing the local install, I'm getting this error:
Makefile.pdlibbuilder:1013: recipe for target 'install-datafiles' failed make: *** [install-datafiles] Error 2
I haven't checked too thoroughly but it looks like everything is building. I'm sudo-ing it if that makes a difference.
Derek
Derek Kwan www.derekxkwan.com
I also created single object binary versions of all these objects with their alphanumeric version/alias, and they all have individual help files - perhaps I'll just keep them and delete the others
thanks
2016-04-10 9:29 GMT-03:00 katja katjavetter@gmail.com:
I notice there used to be one help patch indeed for all nettles, as in Fred Jan's version. For a good reason as we now see. Alexandre has created individual help patches for each nettles class. These could better be encapsulated within nettles-help.pd, rather than live as separate files.
Katja
On Sun, Apr 10, 2016 at 12:34 PM, katja katjavetter@gmail.com wrote:
Hello Derek,
The problem is with the following help files added by Alexandre:
<~-help.pd <=~-help.pd
~-help.pd =~-help.pd
You could filter these out from the wildcard search in the makefile and instead list them explicitly, between quotes like:
"help/<~-help.pd"
Alternatively you could make a single help patch 'nettles-help.pd' and use function class_sethelpsymbol() in all nettles classes. This is probably a better solution, avoiding more file name problems in the future.
Katja
On Sun, Apr 10, 2016 at 1:29 AM, Derek Kwan derek.x.kwan@gmail.com
wrote:
The symlinks aren't created at compile time but during the install process. It is done by target 'install-aliases'. Do 'make install objectsdir=./build' to get a local install. If you still get no symlinks let me know.
I think they are only needed on Linux because of how file access
happens.
Katja
Great! Thanks. Yeah, that works.
When I'm doing the local install, I'm getting this error:
Makefile.pdlibbuilder:1013: recipe for target 'install-datafiles' failed make: *** [install-datafiles] Error 2
I haven't checked too thoroughly but it looks like everything is building. I'm sudo-ing it if that makes a difference.
Derek
Derek Kwan www.derekxkwan.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
yeah, there are, and I had forgotten about them, it's a good thing katja pointed it out. Check at the very bottom; here's what it looks like now:
###################################################### cyclone extra targets ######################################################
install: install-aliases
# on Linux, add symbolic links for UPPER case aliases
install-aliases: all
ifeq ($(uname), Linux)
$(INSTALL_DIR) -v $(installpath)
cd $(installpath); \
ln -s -f Append.$(extension) append.$(extension); \
ln -s -f Append-help.pd append-help.pd; \
I haven't changed Append yet, but here's how scope is now:
ln -s -f scope~.$(extension) Scope~.$(extension);
ln -s -f scope~-help.pd Scope~-help.pd; \
Please recompile and test putting [Scope~] or [cyclone/Scope~]
cheers
2016-04-09 7:01 GMT-03:00 Derek Kwan derek.x.kwan@gmail.com:
On Fri, Apr 8, 2016 at 10:52 PM, IOhannes m zmölnig zmoelnig@iem.at
wrote:
On 04/08/2016 10:29 PM, Alexandre Torres Porres wrote:
Then, cyclone does not come as a library for a long time, and
"Scope~" is
not part of a "-lib"
but it is! it is part of a library named "Scope~.pd_linux" which contains a single object "Scope~".
He's building 'scope~.pd_linux'. With a symlink 'Scope~.pd_linux' and the alias in the C code, wouldn't that be all right?
mdsf IOhannes
Hello,
I'll chime in here because I've been working on this cyclone update as well (Alexandre, hop in here if I'm wrong about any of this). To my knowledge, there isn't any symlinking going on in the build process. I'm using Ubuntu on my machine and I just built it myself and all I get out for scope is scope~.pd_linux. All references to Scope has been changed to scope in Makefile and the source (sickle/Scope.c) got changed to sickle/scope.c. There's no symlink to scope~.pd_linux at all. Do we want to change the Makefile to build a symlink to the built scope~ (and also, what are the reasons for doing so)? Also. is there a symlink equivalent for Windows machines? I'll be honest, I'm not really familiar with Makefile building beyond the very basic stuff (I didn't even know you could make symlinks in Makefiles for instance)...
Derek
===================== Derek Kwan www.derekxkwan.com
Try testing without loading any libraries at startup. I think there's a startup flag for this-- perhaps "-nolibs"? Also, assume that instead of [Scope~] we're talking about [seereadmescope~], and document all this ugliness accordingly. -Jonathan
On Saturday, April 9, 2016 10:04 AM, Alexandre Torres Porres <porres@gmail.com> wrote:
yeah, there are, and I had forgotten about them, it's a good thing katja pointed it out. Check at the very bottom; here's what it looks like now:
######################################################cyclone extra targets ######################################################install: install-aliases
# on Linux, add symbolic links for UPPER case aliases
install-aliases: all
ifeq ($(uname), Linux) $(INSTALL_DIR) -v $(installpath) cd $(installpath); \ ln -s -f Append.$(extension) append.$(extension);
ln -s -f Append-help.pd append-help.pd;
I haven't changed Append yet, but here's how scope is now: ln -s -f scope~.$(extension) Scope~.$(extension);
ln -s -f scope~-help.pd Scope~-help.pd;
Please recompile and test putting [Scope~] or [cyclone/Scope~]
cheers
2016-04-09 7:01 GMT-03:00 Derek Kwan derek.x.kwan@gmail.com:
On Fri, Apr 8, 2016 at 10:52 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 04/08/2016 10:29 PM, Alexandre Torres Porres wrote:
Then, cyclone does not come as a library for a long time, and "Scope~" is not part of a "-lib"
but it is! it is part of a library named "Scope~.pd_linux" which contains a single object "Scope~".
He's building 'scope~.pd_linux'. With a symlink 'Scope~.pd_linux' and the alias in the C code, wouldn't that be all right?
mdsf IOhannes
Hello,
I'll chime in here because I've been working on this cyclone update as well (Alexandre, hop in here if I'm wrong about any of this). To my knowledge, there isn't any symlinking going on in the build process. I'm using Ubuntu on my machine and I just built it myself and all I get out for scope is scope~.pd_linux. All references to Scope has been changed to scope in Makefile and the source (sickle/Scope.c) got changed to sickle/scope.c. There's no symlink to scope~.pd_linux at all. Do we want to change the Makefile to build a symlink to the built scope~ (and also, what are the reasons for doing so)? Also. is there a symlink equivalent for Windows machines? I'll be honest, I'm not really familiar with Makefile building beyond the very basic stuff (I didn't even know you could make symlinks in Makefiles for instance)...
Derek
===================== Derek Kwan www.derekxkwan.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
2016-04-09 11:47 GMT-03:00 Jonathan Wilkes jancsika@yahoo.com:
Try testing without loading any libraries at startup.
that's what I was doing in the first place, been using a clean vanilla with no libs installed, but I re checked and all
About documentation, this issues can be addressed in a changelog and inside the help files of particularly affected objects for sure.
cheers
Yeah, in the help patches you can just let the user know that "Scope~" is there for legacy reasons. They shouldn't need more detail than that.
But do add at least a few comments directly in the source. We're juggling too many variables to leave it to the reader to deduce:* discrepancy between case-sensitivity in the objectmaker method space and the external library loader* (related) when to symlink (Linux, OSX) and when not to symlink (Windows)* Pd community generally does not use capital letters in object names* why it's necessary to add a creator with a backslash in it Actually, I already forgot the reason for that last one. So a few words in a comment preceding that call would be very helpful (even if it's mainly to point the reader to the changelog). -Jonathan
On Saturday, April 9, 2016 11:04 AM, Alexandre Torres Porres <porres@gmail.com> wrote:
2016-04-09 11:47 GMT-03:00 Jonathan Wilkes jancsika@yahoo.com:
Try testing without loading any libraries at startup.
that's what I was doing in the first place, been using a clean vanilla with no libs installed, but I re checked and all About documentation, this issues can be addressed in a changelog and inside the help files of particularly affected objects for sure. cheers
2016-04-08 17:52 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 04/08/2016 10:29 PM, Alexandre Torres Porres wrote:
Then, cyclone does not come as a library for a long time, and "Scope~" is not part of a "-lib"
but it is! it is part of a library named "Scope~.pd_linux" which contains a single object "Scope~".
Sure, but not a library containing many objects, so I don't see why using [declare -lib], isn't that just for the case of libraries with many objects? Since it is just a single object binary, all I need is to have it in a path, so more like [declare -path "folder"].
What am I missing?
cheers
On 04/09/2016 12:06 AM, Alexandre Torres Porres wrote:
sure, but not a library containing many objects, so I don't see why using [declare -lib], isn't that just for the case of libraries with many objects? Since it is just a single object binary, all I need is to have it in a path, so more like [declare -path "folder"].
well the point is that you *can* load any library (regardless of the number of object it contains) with [declare -lib].
e.g. you can use it to load a library "cyclone/Scope~" which has an alias "scope~" - and in the patch you can juse use [scope~].
gmdsr IOhannes
ok, but let me be picky... first, [declare -lib] loads a library, relative to the patch, so there seems to be no reason to declare it if it is in the same folder as the patch and I could just call it by [./scope~], right?
But well, if you actually mean using [declare -stdlib], same thing goes... i can just call it [cyclone/scope~], instead of [declare -stdlib cyclone/scope~] and then using just [scope~]. So this is why I don't see a point in using declare, even though you can. Seems like it's useful if you're loading a library like zexy.
Moreover, it's nice just to have cyclone folder in your search path and don't bother to use declare -lib or -path
But anyway, I have my compiled single object library scope~.pd_darwin
I tried [declare -stdlib cyclone/Scope~] and I could load the object in the following manners:
[scope~] [Scope~] [cyclone/scope~] [cyclone/Scope~]
which are also the 4 ways I can load it if I just have it in my search path
So, did I find a good way to phase out the Upper Case Letter NonSense? :)
cheers
2016-04-08 19:11 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 04/09/2016 12:06 AM, Alexandre Torres Porres wrote:
sure, but not a library containing many objects, so I don't see why using [declare -lib], isn't that just for the case of libraries with many objects? Since it is just a single object binary, all I need is to have
it
in a path, so more like [declare -path "folder"].
well the point is that you *can* load any library (regardless of the number of object it contains) with [declare -lib].
e.g. you can use it to load a library "cyclone/Scope~" which has an alias "scope~" - and in the patch you can juse use [scope~].
gmdsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Alexandre, it seems you found a good approach to gradually phase out upper case (when not needed to avoid name clash). If you change class name and aliases the C code don't forget to swap upper / lower case in the symlinks too, which are created for Linux under 'cyclone extra targets' in the Makefile.
Katja
On Fri, Apr 8, 2016 at 10:29 PM, Alexandre Torres Porres porres@gmail.com wrote:
2016-04-08 16:11 GMT-03:00 Jonathan Wilkes jancsika@yahoo.com:
if the user isn't loading cyclone by default, and their patch does this: [declare -lib cyclone/Scope~]
Ok, but what would that do in the first place? I don't think I get [declare] yet, can you find a specific individual binary or object inside a library?
Then, cyclone does not come as a library for a long time, and "Scope~" is not part of a "-lib"
If by "traded" you mean you renamed the binary to scope~.pd_linux, this won't load anymore.
Nope, I changed stuff in the code as well
I might be wrong, but it seems possible to change it and maintain backwards compatibility and get rid of this annoying Capital letter, but I'm consulting you guys to be sure.
you still need "Append" to differentiate from the internal "append" class, so you can't change that one.
Things, to my surprise, things work in a new and weird way to me in Pd Vanilla. Any class you call that is not the internal one overwrites the internal library. I discussed this on a previous thread these days (Name conflicts "class overwritten; old one renamed 'x_aliased').
The way things are in cyclone nowadays, and I had given the example of "line~" is that it has the "Line~" official and legacy name version but also calls the objects as alias "line~" or "cyclone/line~"
Also-- why is there a class_addcreator to add "cyclone/*" for each class? That _should_ be superfluous...
It's not for every class, but these one with name clashing issues.
So, anyway. How things are now, if I call "Line~", internally it will find the alias "line~" and load it overwritting vanilla's line~. That sucks cause they're not compatible. And basically you had this Capital letter in the first place to avoid name clashing and it was clashing it anyway... (yeah, quite ironic).
It seems that this system would allow you to load cyclone/line~ in Pd Extended and Pd-L2ork, because in both of them, there is no internal overwritting going on. So latest version of extended (0.43) introduced this system with the alias. You can call [cyclone/uzi] and [cyclone/line~] for example, but the latter won't overwritte the internal vanilla's line~
By the "Uzi" is another example like "Scope~", some Capital letter for some reason that is not relevant anymore... and yeah, Uzi comes with the aliases "uzi" e "cyclone/uzi".
But back to "Line~"
if I remove the alias "cyclone/line~" I can now call [Line~] or [cyclone/line~] in Pd without overwritting the internal, and being able to differentiate between [line~] (internal) and [cyclone/line~] external. This is the same case as with Append. I think we should keep the weird animal "Line~" as an alias and an option over [cyclone/line~].
But Uzi and Scope~ are in another category, they don't overwrite internals. In Pd-L2ork you have an old version of Scope~ without the alias, so you won't be able to load it as "scope~" or "cyclone/scope~", but [Uzi] is updated, so you can call it as [uzi] or [cyclone/uzi]. I can only test this in Mac Os, but with the version you provided today, I can do it. Can you do it in linux and windows?
Anyway, I assume that if they did it in Pd Extended, it was for the reason that the trick worked for every system, or they wouldn't introduce this madness or massive inconsistency. And my thought is, if you can do it one way to the other, you can also do it the other way around... if I can call "uzi" as an alias, then I can call "Uzi" as an alias as well.
So, getting Uzi as an example, if I switch everything to the opposite like this:
void uzi_setup(void) { uzi_class = class_new(gensym("uzi") (...) class_addcreator((t_newmethod)uzi_new, gensym("Uzi"), A_DEFFLOAT, 0); class_addcreator((t_newmethod)uzi_new, gensym("cyclone/Uzi"), A_DEFFLOAT, 0) (...)
void Uzi_setup(void) { uzi_setup(); }
Plus the code to "uzi.c" and compiled the object as uzi.pd_darwin
Well, I can call it as [uzi], or as [Uzi] and [cyclone/Uzi]
If I don't have the "cyclone/Uzi" alias, then that doesn't work.
I'd actually be in favor of breaking that compatibility if there were a way to get rid of all those capital letters from cyclone.
And I'd actually second you on that, and we don't need those capital letters for "uzi" or "scope~", so, at least in these two cases, there's a pretty simple way to get rid of it.
But, as I'm saying, I think there is a way to change this and keep the alias for backwards compatibility.
Cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list