I have found that using these math functions doesn't always create on different systems using Pd-Extended. Therefore, it makes it difficult to write about them in the FLOSS Manual. How can I insure that they work on every Extended installation, or should I replace them with [expr] and [expr~] equivalents?
D.
Derek Holzer wrote:
I have found that using these math functions doesn't always create on different systems using Pd-Extended. Therefore, it makes it difficult to write about them in the FLOSS Manual. How can I insure that they work on every Extended installation, or should I replace them with [expr] and [expr~] equivalents?
Personally I wish those things would be renamed using the kind of simple alphabetic characters that work as file names on any OS ('a', 'b', 'c' etc...). For instance "greaterthan", "lessthan", "and", "or"; then some aliasing method could provide a means on those systems that can handle it to refer to them as '<' or whatever). There are still files in the svn repository that make it impossible for me to update the Pd svn on a Windows box, since tortoise svn at least abandons the update at the first error. (Files with * in the name.) A previous attempt to solve this was the "hexloader", I think it failed because not many people can recall the hex equivalent of characters like '<' in less time than it takes to do something else instead, like [expr].
Martin
On Sat, 4 Apr 2009, Martin Peach wrote:
etc...). For instance "greaterthan", "lessthan", "and", "or"; then some aliasing method could provide a means on those systems that can handle it to refer to them as '<' or whatever).
Perl uses gt,lt,ge,le,eq,ne as string comparisons whereas >,<,>=,<=,==,!= are used for numeric comparisons. Perl needs both by design. You could reuse the same names.
The shell's [] (/usr/bin/test) also has -gt,-lt,-ge,-le,-eq,-ne, which it uses for numeric comparisons, whereas it uses >,<,>=,<=,==,!= for string comparisons. It also needs both by design.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
On Sat, 4 Apr 2009, Martin Peach wrote:
etc...). For instance "greaterthan", "lessthan", "and", "or"; then some aliasing method could provide a means on those systems that can handle it to refer to them as '<' or whatever).
Perl uses gt,lt,ge,le,eq,ne as string comparisons whereas
,<,>=,<=,==,!= are used for numeric comparisons. Perl needs both by
design. You could reuse the same names.
The shell's [] (/usr/bin/test) also has -gt,-lt,-ge,-le,-eq,-ne, which it uses for numeric comparisons, whereas it uses >,<,>=,<=,==,!= for string comparisons. It also needs both by design.
Sure, but bash is written in c and it can call its functions whatever it likes because they are built into the program. (It will also try to interpret your file name if it isn't alphanumeric) Pd too has that freedom for its built-in functions but also has the ability to load a subset of all imaginable functions as externals. The limitation lies in the inability of the various operating systems to accept files named using arbitrary combinations of the available character set. All of the OSs that I know of can handle regular a-z type characters, so I suggest sticking to that range for the names of externals. That's all.
Martin
On Sun, 5 Apr 2009, Martin Peach wrote:
The shell's [] (/usr/bin/test) also has -gt,-lt,-ge,-le,-eq,-ne, which it uses for numeric comparisons, whereas it uses >,<,>=,<=,==,!= for string comparisons. It also needs both by design.
Sure, but bash is written in c and it can call its functions whatever it likes because they are built into the program. (It will also try to interpret your file name if it isn't alphanumeric)
The reason why I listed those examples is not to say that you could just use the special punctuation instead of letters. I'm just pointing you to what looks like a standard notation for writing those same concepts as letters, so that you write >= as "ge" instead of "greaterthanorequal" or "greaterequal" or "greq" or any other long and nonstandard combination.
That's all I mean. Do you understand?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
On Sun, 5 Apr 2009, Martin Peach wrote:
The shell's [] (/usr/bin/test) also has -gt,-lt,-ge,-le,-eq,-ne, which it uses for numeric comparisons, whereas it uses
,<,>=,<=,==,!= for string comparisons. It also needs both by design.
Sure, but bash is written in c and it can call its functions whatever it likes because they are built into the program. (It will also try to interpret your file name if it isn't alphanumeric)
The reason why I listed those examples is not to say that you could just use the special punctuation instead of letters. I'm just pointing you to what looks like a standard notation for writing those same concepts as letters, so that you write >= as "ge" instead of "greaterthanorequal" or "greaterequal" or "greq" or any other long and nonstandard combination.
That's all I mean. Do you understand?
Oh I see. But that notation is only standard in shell languages and is not going to help someone guess the name of the object or what it does, especially if they are not used to english. You could name [or] just [o] for example...a saving of one letter in exchange for an infinite increase in uncertainty. It would contribute to making Pd a secret language for initiates who bang until.
Martin
--- On Mon, 4/6/09, Martin Peach martin.peach@sympatico.ca wrote:
From: Martin Peach martin.peach@sympatico.ca Subject: Re: [PD] >, <, &&, || etc To: "Mathieu Bouchard" matju@artengine.ca Cc: "pd list" pd-list@iem.at Date: Monday, April 6, 2009, 5:50 AM Mathieu Bouchard wrote:
On Sun, 5 Apr 2009, Martin Peach wrote:
The shell's [] (/usr/bin/test) also has
-gt,-lt,-ge,-le,-eq,-ne, which it uses for numeric comparisons, whereas it uses >,<,>=,<=,==,!= for string comparisons. It also needs both by design.
Sure, but bash is written in c and it can call its
functions whatever it likes because they are built into the program. (It will also try to interpret your file name if it isn't alphanumeric)
The reason why I listed those examples is not to say
that you could just use the special punctuation instead of letters. I'm just pointing you to what looks like a standard notation for writing those same concepts as letters, so that you write >= as "ge" instead of "greaterthanorequal" or "greaterequal" or "greq" or any other long and nonstandard combination.
That's all I mean. Do you understand?
Oh I see. But that notation is only standard in shell languages and is not going to help someone guess the name of the object or what it does, especially if they are not used to english. You could name [or] just [o] for example...a saving of one letter in exchange for an infinite increase in uncertainty. It would contribute to making Pd a secret language for initiates who bang until.
Are you saying that initiates would know a secret way to bang until that does not cause Pd to freeze? Or, that an infinite increase in uncertainty would dull the users' senses so much that they could no longer tell the difference between an operational and frozen patch?
Pd is already a secret language for initiates. Even your hypothetical beginner is required to guess the name and functionality of what should be a standard object. But I imagine the work everyone is doing on organizing libraries by category will go a long way towards remedying that.
-Jonathan
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 5 Apr 2009, Jonathan Wilkes wrote:
--- On Mon, 4/6/09, Martin Peach martin.peach@sympatico.ca wrote:
Oh I see. But that notation is only standard in shell languages and is not going to help someone guess the name of the object or what it does, especially if they are not used to english. You could name [or] just [o] for example...a saving of one letter in exchange for an infinite increase in uncertainty. It would contribute to making Pd a secret language for initiates who bang until.
Are you saying that initiates would know a secret way to bang until that does not cause Pd to freeze?
It's all about users who don't want to read helpfiles and refuse to learn anything and whose opinion is still important, I don't know why.
Or, that an infinite increase in uncertainty would dull the users' senses so much that they could no longer tell the difference between an operational and frozen patch?
You have to question the infinite increase in uncertainty. Why was this said? is Martin assuming [o] to be an abbreviation for every possible current or future word that may start by [o] ? And somehow at once the user can't possibly be bothered to open the help file to figure what "o" means.
Pd is already a secret language for initiates. Even your hypothetical beginner is required to guess the name and functionality of what should be a standard object. But I imagine the work everyone is doing on organizing libraries by category will go a long way towards remedying that.
A system of mutually-exclusive categories is not very hyperlinked... multiple tags per class is a way that is a lot more helpful in getting people to find what they need, as there is usually more than one useful tag to put on a class, and a system of mutually-exclusive categories only allows one such word at the expense of others.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Martin Peach wrote:
Mathieu Bouchard wrote:
On Sun, 5 Apr 2009, Martin Peach wrote:
The shell's [] (/usr/bin/test) also has -gt,-lt,-ge,-le,-eq,-ne, which it uses for numeric comparisons, whereas it uses
,<,>=,<=,==,!= for string comparisons. It also needs both by design.
[snip]
Oh I see. But that notation is only standard in shell languages
also at least one assembly language:
http://en.wikibooks.org/wiki/68000_Assembly#Conditional_tests
Claude
Claude Heiland-Allen wrote:
Martin Peach wrote:
Mathieu Bouchard wrote:
On Sun, 5 Apr 2009, Martin Peach wrote:
The shell's [] (/usr/bin/test) also has -gt,-lt,-ge,-le,-eq,-ne, which it uses for numeric comparisons, whereas it uses
,<,>=,<=,==,!= for string comparisons. It also needs both by design.
[snip]
Oh I see. But that notation is only standard in shell languages
also at least one assembly language:
http://en.wikibooks.org/wiki/68000_Assembly#Conditional_tests
While it's true 68000 was one of the easiest to learn, assembly language is notoriously obscure. (like anl, orl, jc from 8051) And proprietary concerns meant that every processor had a different mnemonic set, so standardization was out the window from the beginning. Pd is a higher level language that trades off efficiency for a more human interface. Naming things for ease of typing is not usually consistent with naming things according to what they do.
Martin
On Mon, 6 Apr 2009, Martin Peach wrote:
Pd is a higher level language that trades off efficiency for a more human interface.
Yes, it's definitely more human to take a simple formula that fits in a small space and explode it into a network of little components with long names for the sake of reassuring themselves on the basis that it's more visual (so it must be easier, isn't it?) and more verbose (so it must be easier isn't it?) and then use all the placebo effect necessary to make spiderwebs of long names _become_ easier than the simple formula.
This is for the benefit of those users who define themselves as more human than the others because they say so.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Mon, 6 Apr 2009, Claude Heiland-Allen wrote:
also at least one assembly language: http://en.wikibooks.org/wiki/68000_Assembly#Conditional_tests
Yeah, but if Martin thinks that shells and Perl both don't matter, then anything lower-level won't matter (if you don't think of Pd as being lower-level than Perl, which imho would also be questionable...)
Basically it's a matter of first coming up with a long-worded solution as a way to teach english to non-english speakers who want patches to read like english, and then coming up with an appropriately-elaborated problem to fit that solution.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Claude Heiland-Allen wrote:
Martin Peach wrote:
Mathieu Bouchard wrote:
On Sun, 5 Apr 2009, Martin Peach wrote:
The shell's [] (/usr/bin/test) also has -gt,-lt,-ge,-le,-eq,-ne, which it uses for numeric comparisons, whereas it uses
,<,>=,<=,==,!= for string comparisons. It also needs both by design.
[snip]
Oh I see. But that notation is only standard in shell languages
also at least one assembly language:
http://en.wikibooks.org/wiki/68000_Assembly#Conditional_tests
Claude
and in the PHP template engine PHPTAL: http://phptal.motion-twin.com/manual/en/#tal-condition
Thomas
"Spielen Sie Strip Schnipp-Schnapp?" (Adam Weishaupt to Johann Wolfgang von Goethe in: Robert Shea & Robert A. Wilson, The Golden Apple) http://www.residuum.org/
On Sun, 5 Apr 2009, Martin Peach wrote:
Oh I see. But that notation is only standard in shell languages and is not going to help someone guess the name of the object or what it does, especially if they are not used to english.
If they are so much not used to English, then how do you justify names like [hip~] and [dac~] ?
So you want something guessable by someone in most any language, then do your best to support [>] [<] [>=] etc, because that's exactly what you need.
So if I understand you correctly, you need something written in English for people who can't read English, and is guessable by them because they can't use help files and they don't read manuals, and at the same time it can't be the symbols that they already know because the filesystems might not support the characters that could already be substituted by hexloader which might be not loaded, on a system that deprecated non-libdir -lib for ideological reasons about how much code should be put per file.
Maybe I should've just say, just figure out how to support special characters so that we don't have to hear about elongated names designed for people who can't read them.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
I have found that using these math functions doesn't always create on
different systems using Pd-Extended.
Is this really true? Because these objects for messages are builtins and if builtins don't work in Pd extended that would be a severe issue.
Of course it's different with their signal counterparts where they are externals.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Sorry not to be specific. I meant the signal ones. I have replaced all with [expr~].
D.
Frank Barknecht wrote:
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
I have found that using these math functions doesn't always create on
different systems using Pd-Extended.Is this really true? Because these objects for messages are builtins and if builtins don't work in Pd extended that would be a severe issue.
Of course it's different with their signal counterparts where they are externals.
Ciao
I think there a workable solution for the problem of object names that
use characters that don't work on all filesystems. For binaries, like
~, they can be linked into a .pd_linux that is loaded as part of the
libdir. One part of the libdir plan is to have a shared library that
is loaded when the libdir is loaded. That mechanism could also be
used to load a file that includes these classes.
So a library like 'audiomath' would then have audiomath/
libaudiomath.pd_linux. Normally, audiomath/libaudiomath.pd_linux
would only include shared code, but for this case, it would also
include the >~ class, etc.
.hc
On Apr 5, 2009, at 3:44 PM, Derek Holzer wrote:
Sorry not to be specific. I meant the signal ones. I have replaced
all with [expr~].D.
Frank Barknecht wrote:
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
I have found that using these math functions doesn't always create
on different systems using Pd-Extended.Is this really true? Because these objects for messages are builtins and if builtins don't work in Pd extended that would be a severe issue. Of course it's different with their signal counterparts where they
are externals. Ciao-- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 168: "Use fewer notes"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
Hans-Christoph Steiner wrote:
So a library like 'audiomath' would then have audiomath/libaudiomath.pd_linux. Normally, audiomath/libaudiomath.pd_linux would only include shared code, but for this case, it would also include the >~ class, etc.
i guess you meant to name it either "audiomath/libaudiomath.so" (or .dll or .dylib) or "audiomath/audiomath.pd_linux".
the latter is btw, similar to what zexy and/or Gem suggest "upstream" (that is: from my side; not to be confused with any packagers' versions):: zexy/zexy.pd_linux holds shared code (e.g. [>~]) and signle-file-object live side-by-side to it, e.g. rad2deg.pd;
i admit that currently all C-code is considered "shared" (that is: there is no "list2symbol.pd_linux"), but once you start blurring the two worlds it get's blurry anyhow (and "l2s" and "list2symbol" share about 100% of their code anyhow)
having said all that, i think it is a good idea: i would like to be able (e.g. in Pd-extended) to "load" Gem (without modifying the path!) and it should find Gem/Gem.pd_linux and add Gem/ to it's search paths (for abstractions and single-file externals) i would also like to have Pd's loading mechanism modified so that it _temporarily_ adds Gem/ to the dylib-searchpath, so one could ship a library with external dependencies (without having to link them statically)
fmgadsr IOhannes
On Apr 6, 2009, at 5:26 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
So a library like 'audiomath' would then have audiomath/ libaudiomath.pd_linux. Normally, audiomath/libaudiomath.pd_linux
would only include shared code, but for this case, it would also
include the >~ class, etc.i guess you meant to name it either "audiomath/ libaudiomath.so" (or .dll or .dylib) or "audiomath/ audiomath.pd_linux".
Perhaps audiomath/libaudiomath.so makes the most sense so that it
can't be loaded by Pd as an objectclass. But I am guessing.
the latter is btw, similar to what zexy and/or Gem suggest
"upstream" (that is: from my side; not to be confused with any
packagers' versions):: zexy/zexy.pd_linux holds shared code (e.g.
[>~]) and signle-file-object live side-by-side to it, e.g. rad2deg.pd;i admit that currently all C-code is considered "shared" (that is:
there is no "list2symbol.pd_linux"), but once you start blurring the
two worlds it get's blurry anyhow (and "l2s" and "list2symbol" share
about 100% of their code anyhow)
I like having each objectclass as its own file. Then only the code
that is in use will be loaded into memory. linking everything
together into one zexy.pd_linux means the whole thing is loaded into
memory, no?
having said all that, i think it is a good idea: i would like to be
able (e.g. in Pd-extended) to "load" Gem (without modifying the
path!) and it should find Gem/Gem.pd_linux and add Gem/ to it's
search paths (for abstractions and single-file externals) i would also like to have Pd's loading mechanism modified so that it
_temporarily_ adds Gem/ to the dylib-searchpath, so one could ship a
library with external dependencies (without having to link them
statically)
I am sure you don't mean to do this on GNU/Linux, right?
I take it you mean like including a .dylib in the Gem folder? Kind of
like what I do with Pd-extended and the Fink dylibs? That is not a
great system. I think due to the limitations of the Mac OS X shared
lib loading, it would be painful. Basically, AFAIK, a .dylib in Mac
OS X must have its path hard-coded in the file. Otherwise, you have
to load it manually with a direct call to dlopen. I don't remember
the details in Windows, I think that it already checks "." for .dlls
by default.
.hc
I spent 33 years and four months in active military service and during
that period I spent most of my time as a high class muscle man for Big
Business, for Wall Street and the bankers. - General Smedley Butler
Hans-Christoph Steiner wrote:
On Apr 6, 2009, at 5:26 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
So a library like 'audiomath' would then have audiomath/libaudiomath.pd_linux. Normally, audiomath/libaudiomath.pd_linux would only include shared code, but for this case, it would also include the >~ class, etc.
i guess you meant to name it either "audiomath/libaudiomath.so" (or .dll or .dylib) or "audiomath/audiomath.pd_linux".
Perhaps audiomath/libaudiomath.so makes the most sense so that it can't be loaded by Pd as an objectclass. But I am guessing.
the question is why you would want to enforce Pd not being able to load this library. at the worst this would allow to mix abstractions, single-object-binaries, multi-object-binaries and shared-code dylibs into a single "bundle" (libdir-like directory defining a library)
the only reason i see to create an explicit mechanism to prevent Pd from loadinga file as an object-class is a notorious aversion against multiboject-binaries.
it's ok for me if someone doesn't like these. it's not ok for me declaring war on them.
i admit that currently all C-code is considered "shared" (that is: there is no "list2symbol.pd_linux"), but once you start blurring the two worlds it get's blurry anyhow (and "l2s" and "list2symbol" share about 100% of their code anyhow)
I like having each objectclass as its own file.
i know
Then only the code that is in use will be loaded into memory. linking everything together into one zexy.pd_linux means the whole thing is loaded into memory, no?
obviously. but you are surely aware that you cannot avoid people doing this with shared libs (that cannot be loaded directly by Pd) as well.
so again, the only reason to make this explicit is because to throw feeble hurdles on the path of freedom of a developer.
<trying to turn pathos mode off>
i would also like to have Pd's loading mechanism modified so that it _temporarily_ adds Gem/ to the dylib-searchpath, so one could ship a library with external dependencies (without having to link them statically)
I am sure you don't mean to do this on GNU/Linux, right?
yes i want to do this on all platforms.
I take it you mean like including a .dylib in the Gem folder?
but i am not talking about including libGL.so with Gem.
it is really something along the lines of your proposal on "audiomath/libaudiomath.so".
Kind of like what I do with Pd-extended and the Fink dylibs? That is not a great system. I think due to the limitations of the Mac OS X shared lib loading, it would be painful. Basically, AFAIK, a .dylib in Mac OS X must have its path hard-coded in the file. Otherwise, you have to load it manually with a direct call to dlopen.
but the path can be relative, no?
I don't remember the details in Windows, I think that it already checks "." for .dlls by default.
this is how i remember it as well.
fgmasdr IOhannes
On Apr 8, 2009, at 7:19 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Apr 6, 2009, at 5:26 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
So a library like 'audiomath' would then have audiomath/ libaudiomath.pd_linux. Normally, audiomath/libaudiomath.pd_linux
would only include shared code, but for this case, it would also
include the >~ class, etc.i guess you meant to name it either "audiomath/ libaudiomath.so" (or .dll or .dylib) or "audiomath/ audiomath.pd_linux".
Perhaps audiomath/libaudiomath.so makes the most sense so that it
can't be loaded by Pd as an objectclass. But I am guessing.the question is why you would want to enforce Pd not being able to
load this library. at the worst this would allow to mix abstractions, single-object- binaries, multi-object-binaries and shared-code dylibs into a single
"bundle" (libdir-like directory defining a library)the only reason i see to create an explicit mechanism to prevent Pd
from loadinga file as an object-class is a notorious aversion
against multiboject-binaries.it's ok for me if someone doesn't like these. it's not ok for me
declaring war on them.
I have traditionally had an aversion to multiobject-binaries because
of the pain they caused many people, me included. It seems that they
could be fine as long as we have the right mechanisms to be able to
put the objectclasses in that binary into a fully functioning
namespace, and be able to address them using namespace prefixes. From
the Pd interface point of view, all objectclasses should behave the
same, regardless of how they are implemented.
The idea for the audiomath/libaudiomath.so chunk is for shared code
that would be loaded when the library is loaded, whether or not any
object class has been loaded. I suppose it might just be simpler to
make it a .pd_linux. I just have a feeling that it will cause
problems down the line, I don't have an example off hand to back up
that feeling.
i admit that currently all C-code is considered "shared" (that is:
there is no "list2symbol.pd_linux"), but once you start blurring
the two worlds it get's blurry anyhow (and "l2s" and "list2symbol"
share about 100% of their code anyhow)I like having each objectclass as its own file.
i know
Then only the code that is in use will be loaded into memory.
linking everything together into one zexy.pd_linux means the whole
thing is loaded into memory, no?obviously. but you are surely aware that you cannot avoid people doing this
with shared libs (that cannot be loaded directly by Pd) as well.so again, the only reason to make this explicit is because to throw
feeble hurdles on the path of freedom of a developer.<trying to turn pathos mode off>
I think the archives have some long discussions about the problems
with multi-object binaries. I am not opposed to using them if someone
wants to do the work to make them behave like abstractions in a libdir
currently do. (i.e. [import mylib] then [myobj]; [mylib/myobj],
etc.) Then we would have a relatively straightforward solution for
the problems with >~, etc.
i would also like to have Pd's loading mechanism modified so that
it _temporarily_ adds Gem/ to the dylib-searchpath, so one could
ship a library with external dependencies (without having to link
them statically)I am sure you don't mean to do this on GNU/Linux, right?
yes i want to do this on all platforms.
What lib would you include with Gem on GNU/Linux? Shouldn't Gem use
the Debian/Ubuntu/Fedora packages? Or am I missing something?
I take it you mean like including a .dylib in the Gem folder?
but i am not talking about including libGL.so with Gem.
it is really something along the lines of your proposal on
"audiomath/libaudiomath.so".Kind of like what I do with Pd-extended and the Fink dylibs? That
is not a great system. I think due to the limitations of the Mac
OS X shared lib loading, it would be painful. Basically, AFAIK,
a .dylib in Mac OS X must have its path hard-coded in the file.
Otherwise, you have to load it manually with a direct call to dlopen.but the path can be relative, no?
Not really, IIRC. It has to be an absolute path, but then there is
this @executable_path@ variable which is replaced by the path to the
executable that is loading the lib. Its all a bit hazy in my brain,
it would be worth checking the docs and maybe trying a relative path.
I remember trying a lot of things, then giving up and thinking that Pd
would have to open audiomath/libaudiomath.so directly using dlopen().
.hc
I don't remember the details in Windows, I think that it already
checks "." for .dlls by default.this is how i remember it as well.
fgmasdr IOhannes
¡El pueblo unido jamás será vencido!
-
Claude Heiland-Allen -
Derek Holzer -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
Martin Peach -
Mathieu Bouchard -
Thomas Mayer