PureData detects tcl8.0, but does not run properly with it, due to its usage of the [string map] function.
PureData detects tcl8.3, but may attempt to run it with tk8.0, and tk8.0 refuses to run with tcl8.3.
How do I add a new type of Atom? If not, what may I use to pass void* around? You see, I used to use integers to pass around pointers, because my methods always knew beforehand what were function pointers and what were int pointers and what were just integers. However there is no integer type in PureData. What should I do?
Mathieu Bouchard http://artengine.ca/matju
Hi folks i am fooling with an XP laptop and wanted to know how to set the VST_PATH correctly
i go to computer-->properties==>advanced-->environment variables-->
should i put set VST_PATH= or just Put VST_PATH
i am trying to use plugin~ on XP any tips would be appreciated cheers~
Pat Pagano, Director South East Just Intonation Society http://www.screwmusicforever.com/SHREESWIFT/
Hi..
how would i format a message to send an equivalent value of hex FFFF via netsend? And how can i handle spaces in netsend messages? (i seem to remember that making symbols e.t.c. got tricky)
thanks
Tom
hi,
what is being netsended is just text. Any data, be it a symbol or a float, is converted into text. How this text would be parsed is up to a receiver -- if you are using a netreceive object, then you would get the standard Pd's way of parsing into atoms (symbols and floats), with spaces treated as separators.
If by sending FFFF you mean packing up four 0xF bytes into a text string, then [sprintf] could do this. Otherwise, you probably mean sending 65535 (or -1 if your receiver expects signed shorts)?
Krzysztof
nullpointer wrote:
how would i format a message to send an equivalent value of hex FFFF via netsend? And how can i handle spaces in netsend messages? (i seem to remember that making symbols e.t.c. got tricky)
hi,
using an atom type unknown to the outside world is possible, but without any way of plugging a specialized method handling this type. One would need to use a generic typedmess() interface -- declare A_GIMME method on a receiving side, and pass it ordinary messages with a symbol selector prefix.
I am not sure, if relying on every foreign class ignoring unknown atom type is a good idea. If not, one could filter foreign receivers, i.e. directly use outlet traversal routines, bypassing the standard outlet_anything() mechanism.
Of course, there are also simple but dirty hacks for passing C-pointers around, like converting their hex representation into either symbols (this could result in a Pd's symbol table lookup slowdown), or lists of ascii codes (floats). The other hack could be passing indices to a ``dispatch table'', or, more generally, establishing a well-known base address, and passing the offsets (small floats).
Krzysztof
Mathieu Bouchard wrote: ...
How do I add a new type of Atom? If not, what may I use to pass void* around? You see, I used to use integers to pass around pointers, because my methods always knew beforehand what were function pointers and what were int pointers and what were just integers. However there is no integer type in PureData. What should I do?
... or you could divide a long integer into two short (16-Bit) ones which are exactly representable by two floats.... also a bad hack.
Thomas
----- Original Message ----- From: "Krzysztof Czaja" czaja@chopin.edu.pl To: "Mathieu Bouchard" matju@sympatico.ca Cc: "pd-list" pd-list@iem.kug.ac.at Sent: Monday, September 02, 2002 4:03 PM Subject: Re: [PD] bugs and question
hi,
using an atom type unknown to the outside world is possible, but without any way of plugging a specialized method handling this type. One would need to use a generic typedmess() interface -- declare A_GIMME method on a receiving side, and pass it ordinary messages with a symbol selector prefix.
I am not sure, if relying on every foreign class ignoring unknown atom type is a good idea. If not, one could filter foreign receivers, i.e. directly use outlet traversal routines, bypassing the standard outlet_anything() mechanism.
Of course, there are also simple but dirty hacks for passing C-pointers around, like converting their hex representation into either symbols (this could result in a Pd's symbol table lookup slowdown), or lists of ascii codes (floats). The other hack could be passing indices to a ``dispatch table'', or, more generally, establishing a well-known base address, and passing the offsets (small floats).
Krzysztof
Mathieu Bouchard wrote: ...
How do I add a new type of Atom? If not, what may I use to pass void* around? You see, I used to use integers to pass around pointers,
because
my methods always knew beforehand what were function pointers and what were int pointers and what were just integers. However there is no
integer
type in PureData. What should I do?
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Mathieu Bouchard wrote:
How do I add a new type of Atom? If not, what may I use to pass void* around? You see, I used to use integers to pass around pointers, because my methods always knew beforehand what were function pointers and what were int pointers and what were just integers. However there is no integer type in PureData. What should I do?
using an atom type unknown to the outside world is possible, but without any way of plugging a specialized method handling this type.
From the jMax 2.5 source:
FTS_API void fts_atom_type_register(fts_symbol_t name, fts_class_t *cl); FTS_API int fts_atom_type_lookup(fts_symbol_t name, fts_class_t **cl);
I don't know why PureData does not get added something like this. (Miller -- this is a feature request.)
I am not sure, if relying on every foreign class ignoring unknown atom type is a good idea. If not, one could filter foreign receivers, i.e. directly use outlet traversal routines, bypassing the standard outlet_anything() mechanism.
Well, foreign classes either won't get the message, or else they most probably are message-routing operations (eg: route, select, demux) in which case the message's content is plainly put none of their business (and so they have no business ignoring messages depending on their contents either)
C-pointers around, like converting their hex representation into either symbols (this could result in a Pd's symbol table lookup slowdown),
if you mean converting full 8-byte hex codes into symbols, i call this symbol table _flooding_. This is usually a not-nice thing to do, as it is for all practical purposes a memory leak (symbols are forever). However if that slows down PD's symbol table lookup, then that lookup function is _badly_ _implemented_ and should be rewritten.
On Mon, 2 Sep 2002, Thomas Grill wrote:
... or you could divide a long integer into two short (16-Bit) ones which are exactly representable by two floats.... also a bad hack.
Thank you. This is the bad hack I have coded, right before you sent me this mail. Unfortunately for your taste, it works very well and there's no other solution I know of. So much for calling things bad hacks.
Mathieu Bouchard http://artengine.ca/matju
hi Mathieu,
Mathieu Bouchard wrote: ...
From the jMax 2.5 source:
FTS_API void fts_atom_type_register(fts_symbol_t name, fts_class_t *cl); FTS_API int fts_atom_type_lookup(fts_symbol_t name, fts_class_t **cl);
I don't know why PureData does not get added something like this.
perhaps this 'minimalistic' attitude is one of the reasons, why Pd is (still!) a reliable performance tool...
...
Well, foreign classes either won't get the message, or else they most
if they happen to use the same selector, they would get it...
...
symbol table _flooding_. This is usually a not-nice thing to do, as it is for all practical purposes a memory leak (symbols are forever). However if that slows down PD's symbol table lookup, then that lookup function is _badly_ _implemented_ and should be rewritten.
do you mean, that one can write a lookup function having a constant execution time, regardless of a symbol table size? Could you give me a pointer?
Krzysztof
do you mean, that one can write a lookup function having a constant execution time, regardless of a symbol table size? Could you give me a pointer?
"Constant time" may not be true, but possibly there are better storages (although they may not be that lightweight). Have a look at: http://www.sourcejudy.com (the "Judy scalable hashing" configuration should be especially interesting).
greetings, Thomas
hi Thomas,
thanks. From a quick look at it, I gather, that the solution is to use JLI() call for insertion. However, there is a
``Note: JLI() and JLD() reorganize the JudyL array. Therefore, pointers returned from previous JudyL calls become invalid and must be reacquired.''
This complicates the task. But I will look further into that...
Krzysztof
Thomas Grill wrote: ...
"Constant time" may not be true, but possibly there are better storages (although they may not be that lightweight). Have a look at: http://www.sourcejudy.com (the "Judy scalable hashing" configuration should be especially interesting).
On Fri, 6 Sep 2002, Krzysztof Czaja wrote:
symbol table _flooding_. This is usually a not-nice thing to do, as it is for all practical purposes a memory leak (symbols are forever). However if that slows down PD's symbol table lookup, then that lookup function is _badly_ _implemented_ and should be rewritten.
do you mean, that one can write a lookup function having a constant execution time, regardless of a symbol table size? Could you give me a pointer?
Most any language implementation having some kind of symboltable and/or dictionaries/maps implements it as a auto-resizing hashtable such that:
- fetch is maximum O(1)
- store of existing key is maximum O(1)
- store of new key is maximum O(n) (on resizing)
- resizing occurs on every O(b^n) key-count boundary (b is constant)
- and therefore store of new key is _average_ O(1)
to my knowledge, that includes at least Ruby, Perl, and jMax3, but I would guess all those conditions are also met by Python, Java, PHP, C++/STL, and such.
and that excludes PureData and jMax2.
I don't know much about Judy, and sure it's fast, but you don't need Judy at all to meet the above conditions. It might be worth it if it has more realtime features, eg a low maximum-time-order on store-new-key.
Mathieu Bouchard wrote:
From the jMax 2.5 source:
FTS_API void fts_atom_type_register(fts_symbol_t name, fts_class_t *cl); FTS_API int fts_atom_type_lookup(fts_symbol_t name, fts_class_t **cl); I don't know why PureData does not get added something like this.
perhaps this 'minimalistic' attitude is one of the reasons, why Pd is (still!) a reliable performance tool...
To be nice with you I will call that an 'opinion'.
Mathieu Bouchard http://artengine.ca/matju
In general, it's a bad idea in Pd to write externs which create indeter- minate numbers of symbols at run time. The original intent was that the only time anyone would call gensym was on text typed by the user. In this situation the existing realization is quite adequate.
But even if you've written C code that generates millions of symbols on the fly as it runs, the (linear-time-worst-case) existing algo is no worse than the (linear-time-worst-case) "smart" algo. In real time it's always the worst case that counts, and the less variation in execution time your objects can have the less likely someone will get a bad surprise someday. So the existing routine, which is _always_ slow, is better than any algorithm that is only _occasionally_ slow.
Someday I should write more about this... as it is, I have barely got enough time to keep Pd running given all the platform changes coming down...
cheers Miller
On Fri, Sep 06, 2002 at 05:08:17PM -0400, Mathieu Bouchard wrote:
On Fri, 6 Sep 2002, Krzysztof Czaja wrote:
symbol table _flooding_. This is usually a not-nice thing to do, as it is for all practical purposes a memory leak (symbols are forever). However if that slows down PD's symbol table lookup, then that lookup function is _badly_ _implemented_ and should be rewritten.
do you mean, that one can write a lookup function having a constant execution time, regardless of a symbol table size? Could you give me a pointer?
Most any language implementation having some kind of symboltable and/or dictionaries/maps implements it as a auto-resizing hashtable such that:
- fetch is maximum O(1)
- store of existing key is maximum O(1)
- store of new key is maximum O(n) (on resizing)
- resizing occurs on every O(b^n) key-count boundary (b is constant)
- and therefore store of new key is _average_ O(1)
to my knowledge, that includes at least Ruby, Perl, and jMax3, but I would guess all those conditions are also met by Python, Java, PHP, C++/STL, and such.
and that excludes PureData and jMax2.
I don't know much about Judy, and sure it's fast, but you don't need Judy at all to meet the above conditions. It might be worth it if it has more realtime features, eg a low maximum-time-order on store-new-key.
Mathieu Bouchard wrote:
From the jMax 2.5 source:
FTS_API void fts_atom_type_register(fts_symbol_t name, fts_class_t *cl); FTS_API int fts_atom_type_lookup(fts_symbol_t name, fts_class_t **cl); I don't know why PureData does not get added something like this.
perhaps this 'minimalistic' attitude is one of the reasons, why Pd is (still!) a reliable performance tool...
To be nice with you I will call that an 'opinion'.
Mathieu Bouchard http://artengine.ca/matju
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
hi Miller, Mathieu, Thomas...
how about explicit rehashing requests, to be issued only in well-defined circumstances -- say, via a ``rehash if threshold exceeded'' message to 'pd', and/or, from within canvas_start/stop_dsp()?
It seems to me, that otherwise (without rehashing) there will remain a hidden trap, threatening in particular certain types of applications (e.g. installations), because one cannot avoid producing new symbols, even if in a very slow pace.
Krzysztof
Miller Puckette wrote:
In general, it's a bad idea in Pd to write externs which create indeter- minate numbers of symbols at run time. The original intent was that the only time anyone would call gensym was on text typed by the user. In this situation the existing realization is quite adequate.
But even if you've written C code that generates millions of symbols on the fly as it runs, the (linear-time-worst-case) existing algo is no worse than the (linear-time-worst-case) "smart" algo. In real time it's always the worst case that counts, and the less variation in execution time your objects can have the less likely someone will get a bad surprise someday. So the existing routine, which is _always_ slow, is better than any algorithm that is only _occasionally_ slow.
Mathieu,
do not hesitate to be harsh! I really do appreciate your expertise, so please, come straight to the point -- do you mean that
Pd is not reliable? (What is then?)
Simple (or is it simplistic?) design is not relevant to
reliability of, in effect, a single-man's project?
- The feature of being able to define new atom types does not
complicate the design (this is quite possible, hence my 'perhaps')?
Krzysztof
Mathieu Bouchard wrote: ... perhaps this 'minimalistic' attitude is one of the reasons, why Pd
is (still!) a reliable performance tool...
...
To be nice with you I will call that an 'opinion'.
On Sat, 7 Sep 2002, Krzysztof Czaja wrote:
do not hesitate to be harsh! I really do appreciate your expertise, so please, come straight to the point -- do you mean that
- Pd is not reliable? (What is then?)
- Simple (or is it simplistic?) design is not relevant to
reliability of, in effect, a single-man's project? 3. The feature of being able to define new atom types does not complicate the design (this is quite possible, hence my 'perhaps')?
PD seems reliable, however the absence of that feature is a problem that prevents some kinds of externals to be written cleanly.
matju
-
Krzysztof Czaja -
Mathieu Bouchard -
Miller Puckette -
nullpointer -
shreeswifty -
Thomas Grill