hej list,
two questions.
1.) since pd is based on tcl/tk, would it be possible (easy?) to impliment the tcl scripting language inside of PD?
2.) when externals and/or libraries are included in the pd path (say in the .pdrc file) are they loaded into entirely into memory or just registered somehow? I have the feeling that librarys are loaded, but externals are not.
rolling along - august.
hi august,
I read:
1.) since pd is based on tcl/tk, would it be possible (easy?) to impliment the tcl scripting language inside of PD?
I guess tcl is reasonably easy to embed in an external, but I doubt that it would be any easier because of the gui using it already, anyway http://phaseit.net/claird/comp.lang.tcl/HowToC.html might be of interest.
2.) when externals and/or libraries are included in the pd path (say in the .pdrc file) are they loaded into entirely into memory or just registered somehow? I have the feeling that librarys are loaded, but externals are not.
IIUC everything you put after -lib will be searched for and the setup function will be called (no matter if it's a lib or a single extern) if you use -path the libs are loaded as needed (i.e. when you create a [zexy] or [mysingleextern~] object).
regards,
x
Hi August.
1.) since pd is based on tcl/tk, would it be possible (easy?) to impliment the tcl scripting language inside of PD?
it's possible for sure - it's a task comparable to my py/pyext-externals. You may have a look at them at http://www.parasitaere-kapazitaeten.net/ext
2.) when externals and/or libraries are included in the pd path (say in the .pdrc file) are they loaded into entirely into memory or just registered somehow? I have the feeling that librarys are loaded, but externals are not.
This is right. The setup functions (which registers the classes along with their methods) of these external files are loaded either at pd startup (with the -lib command) or at instantiation of an object (the external is then searched via -path). Once loaded the information stays in the system. It's not precise to say that they are "loaded entirely into memory" because memory consumption will in most cases take place when an object is created, not upon loading (which is "registering") a library or single external. So, (both for libraries or single externals) you can choose to "-lib" them at startup or load them on demand by creating an object (a library can also be loaded by creating an object with the library name).
best greetings, Thomas
Thomas Grill wrote:
This is right. The setup functions (which registers the classes along with their methods) of these external files are loaded either at pd startup (with the -lib command) or at instantiation of an object (the external is then searched via -path). Once loaded the information stays in the system. It's not precise to say that they are "loaded entirely into memory" because memory consumption will in most cases take place when an object is created, not upon loading (which is "registering") a library or single external. So, (both for libraries or single externals) you can choose to "-lib" them at startup or load them on demand by creating an object (a library can also be loaded by creating an object with the library name).
best greetings, Thomas
i didnt realise this... are there any problems with dropouts and the like with using -path for large externals? so far i always use -lib for all my externals, but if there isnt any problem with dynamically loading up the .dll's as i use them i'll probably switch to that if only to speed up my pd startup time.
-josh
independent u.s. drum'n'bass -- http://vitriolix.com
So, (both for libraries or single externals) you can choose to "-lib" them at startup or load them on demand by creating an object (a library can also be loaded by creating an object with the library name).
i didnt realise this... are there any problems with dropouts and the like with using -path for large externals? so far i always use -lib for all my externals, but if there isnt any problem with dynamically loading up the .dll's as i use them i'll probably switch to that if only to speed up my pd startup time.
Yes, dropouts can occur if loading and instantiating an object takes a longer time. This is internally treated just like message processing - no separate threads or other magic.
greetings, Thomas
On Sun, 9 Mar 2003, Josh Steiner wrote:
Thomas Grill wrote: i didnt realise this... are there any problems with dropouts and the like with using -path for large externals? so far i always use -lib for all my externals, but if there isnt any problem with dynamically loading up the .dll's as i use them i'll probably switch to that if only to speed up my pd startup time.
Using single externals is a lot more flexible than using libraries. The dropout problem might exist as it exists when loading abstractions. For live purposes it might be better to have the patch already finished to avoid this. Another possibility is to preload the externals you want to use.
Guenter
-
august -
CK -
guenter geiger -
Josh Steiner -
smoerk -
Thomas Grill