I just experimented a bit... In principle PD handles the lots of symbols quite well (i generated about 3000000 different ones), but naturally symbol retrieval becomes slow then. In one occasion PD crashed but this seems to be attributable to Win2K (which was non-responsive afterwards). The size of the symbol hashtable is only 1024 by default, it should be increased in cases with many symbols.
Btw. (as i now understand how gensym works...) it seems to be fairly easy to include a function into pd that frees a symbol. The only difficulty is what to do with the s_thing pointer attached to a symbol? Free its memory as well or not?
greetings, Thomas
And, on the other hand, is it possible to free symbol
definitions from the
symbol space?
gensym("") +?
could you explain? "" is already there, in the first slot of the hashtable. It is generated in mess_init(), and used as a
null' symbol referenced bys_' (otherwise you seem to be right) --have not looked at pd very. may be.
as recall pd. max. etc experience problems when too many symbols are generated. true +?
hi Thomas,
Thomas Grill wrote:
In principle PD handles the lots of symbols quite well (i generated about 3000000 different ones), but naturally symbol retrieval becomes slow then. In one occasion PD crashed but this seems to be attributable to Win2K (which
I am afraid Pd looses any possibility to do audio much sooner than
3e+06 figure might suggest. On an 866Mhz linux, a simple patch using
[+ 1]<->[int]->$1-nn' driven by [bang~]->3'->[until] hits the
barrier at around 500000-nn symbol, both at first pass, and also
during retrieval.
Btw. (as i now understand how gensym works...) it seems to be fairly easy to include a function into pd that frees a symbol. The only difficulty is what to do with the s_thing pointer attached to a symbol? Free its memory as well or not?
This is usually a pointer to an object, and I do not think one is supposed to simply ``free memory'' of an object...
Besides, I would generally be afraid of getting rid of a symbol, which is bound to something, because this might indicate the symbol is shared. If symbol was to be freed, I would prefer s_thing field to be null in the first place. But your case may be special (and I may be totally wrong here...)
Krzysztof
Hi all,
You can never safely delete symbols in Max or Pd since there's no guaranteed way of tracking down everything that might contain a pointer to it. So it's probably not a good idea to rely on generating millions of symbols in a Pd patch, if you can help it...
cheers Miller
On Sat, Apr 27, 2002 at 08:13:27PM +0200, Krzysztof Czaja wrote:
hi Thomas,
Thomas Grill wrote:
In principle PD handles the lots of symbols quite well (i generated about 3000000 different ones), but naturally symbol retrieval becomes slow then. In one occasion PD crashed but this seems to be attributable to Win2K (which
I am afraid Pd looses any possibility to do audio much sooner than 3e+06 figure might suggest. On an 866Mhz linux, a simple patch using [+ 1]<->[int]->
$1-nn' driven by [bang~]->3'->[until] hits the barrier at around 500000-nn symbol, both at first pass, and also during retrieval.Btw. (as i now understand how gensym works...) it seems to be fairly easy to include a function into pd that frees a symbol. The only difficulty is what to do with the s_thing pointer attached to a symbol? Free its memory as well or not?
This is usually a pointer to an object, and I do not think one is supposed to simply ``free memory'' of an object...
Besides, I would generally be afraid of getting rid of a symbol, which is bound to something, because this might indicate the symbol is shared. If symbol was to be freed, I would prefer s_thing field to be null in the first place. But your case may be special (and I may be totally wrong here...)
Krzysztof
Hi,
So it's probably not a good idea to rely on generating millions of symbols in a Pd patch, if you can help it...
That's for sure, but i regularly encounter situations where i want to process textual data from some external or internal source... in all those cases i miss some kind of raw string handling without symbol generation. Today, i just wanted to see where the limits are....
greetings, Thomas
Hi Thomas,
if you need to do string processing a lot, it is probably advisable not to do it in pd, but rather rely on externals like Larry Troxlers "scheme" external, as scheme is specifically designed for symbolic computation and list processing. This'll save you a lot of hassle.
Another way (in linux) could be to pipe to a perl or gawk script.
Orm
Am Samstag, den 27. April 2002 um 22:44:23 Uhr (+0200) schrieb Thomas Grill:
Hi,
So it's probably not a good idea to rely on generating millions of symbols in a Pd patch, if you can help it...
That's for sure, but i regularly encounter situations where i want to process textual data from some external or internal source... in all those cases i miss some kind of raw string handling without symbol generation. Today, i just wanted to see where the limits are....
greetings, Thomas
Hi all,
I've written MIDI support into the latest Mac OSX test version (21 I think) but it doesn't work yet, just spews out debugging messages instead of actually sending and receiving MIDI. I have to do some more debugging
In the meantime, you can suppress the garbage printout if you care by running "pd -nomidi"...
cheers MIller
Hi all,
I've written MIDI support into the latest Mac OSX test version (21 I think) but it doesn't work yet, just spews out debugging messages instead of actually sending and receiving MIDI. I have to do some more debugging
In the meantime, you can suppress the garbage printout if you care by running "pd -nomidi"...
cheers MIller
weird,
I'm using a midisportUSB 1x1, and I see midi incoming messages, plus I can use the pd test program to send midi out to the keyboard...but didn't test it beyond that...though it did crash on quit, something like:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000038
Thread 0 Crashed: #0 0x00061fb4 in Pm_Close #1 0xbffff4a0 in 0xbffff4a0 #2 0x0005da54 in sys_close_midi #3 0x00039edc in sys_bail #4 0x00039f44 in glob_quit #5 0x00031b44 in pd_typedmess #6 0x00034c14 in binbuf_eval #7 0x000393d4 in socketreceiver_read #8 0x00038f20 in sys_domicrosleep #9 0x00039e68 in sys_pollgui #10 0x00037c4c in m_scheduler #11 0x000381c8 in sys_main #12 0x000020d0 in _start #13 0x00001f00 in start
Thread 1: #0 0x70000978 in mach_msg_overwrite_trap #1 0x70005a04 in mach_msg #2 0x7017bf98 in __CFRunLoopRun #3 0x701b7100 in CFRunLoopRunSpecific #4 0x7017b8e0 in CFRunLoopRunInMode #5 0x715a164c in MIDIInPortThread::Run(void) #6 0x715a5434 in XThread::RunHelper(void *) #7 0x7002054c in _pthread_body
...of course, I didn't include the full thread report from console...
...so maybe it's further along than ya think!
tanx, jamie
-
Krzysztof Czaja -
Miller Puckette -
Orm Finnendahl -
Thomas Grill -
tigital